How to read rows in binary matrix file using FREAD/FSEEK

[Ray]

Hello there everyone, first post here, I'll get right to the point:

I have a 801 * 8 matrix (all elements are doubles) stored in binary file. What I want to do is to read specific rows (one row at a time) from this file. I have tried this using FREAD, but I can't get it to work. I know it is made to read columns normally, but even that fails most of the time. I often get strange results like 10^-231 type of numbers.

So I need to read just one row, but at a specific index, say 402, how do I do that?
Could anyone please help me with this?

Thanks a lot!

Ray

This is the code I used to make a binary file from a matrix stored in a mat file
load matrixW.mat;
M=W;
fid = fopen('matrixW.dat','w')
fwrite(fid,size(M),'uint16','n')
fwrite(fid,M,'double')
fclose(fid)

PS.
I know there is a 'read matrix' command but I don't have Matlab 2011 yet.

PS2.
I could transpose the matrix first, but I really want to know how to get it to just read rows first please (instead of just columns).

[Ray]

Okay, using the examples in the help I found out how to use the skip commands for integer matrices. If I want the 5th row to be printed, I need to seek to the 5th row of the first column and then skip all values in the first and second column until I get to the value that has the same row index as the first one, using the skip thing.
Like this:

fid = fopen('nine.bin', 'w')
alldata = reshape([1:90],9,10)
fwrite(fid, alldata)
fclose(fid)

fid = fopen('nine.bin')
frewind(fid)
disp(alldata)
fseek(fid, 4, 'bof');
row_5 = fread(fid, [1, 10], '1*uint8', 8)

HOWever, if I make a matrix filled with doubles, this doesn't work at all. If I leave everything pretty much the same, the row will come back, but all doubles are converted to integers (in this case 0 and 1).

fid = fopen('nine.bin', 'w')
alldata=rand(9,10)
fwrite(fid, alldata)
fclose(fid)

fid = fopen('nine.bin')
frewind(fid)
disp(alldata)
fseek(fid, 4, 'bof');
row_5 = fread(fid, [1, 10], '1*uint32', 8)

So, I changed uint32 to double, but this gave the same garbage as before:
row_5 = 1.3907e-309 5.4323e-312 1.3907e-309 7.7468e-304 1.3907e-309

I am close, but still missing something, could anyone please explain this?

[Ray]

[dpb]

On 1/2/2012 7:10 AM, Ray wrote:
...

> I have a 801 * 8 matrix (all elements are doubles) stored in binary
> file. What I want to do is to read specific rows (one row at a time)
> from this file. I have tried this using FREAD, but I can't get it to
> work. I know it is made to read columns normally, but even that fails
> most of the time. I often get strange results like 10^-231 type of numbers.
>
> So I need to read just one row, but at a specific index, say 402, how do
> I do that?
> Could anyone please help me with this?

...

> I could transpose the matrix first, but I really want to know how to get
> it to just read rows first please (instead of just columns).

That's the only rational way to write the file if you intend/must read
it the way you're wanting to.

Matlab storage order is column-major and the data are sequential in the
file in that order. The only way to read it and return what was an
original row is to read one element (of the proper word size) at the
proper location in the file and then skip the proper number of elements
(in bytes via fseek) depending on the size of the array written and then
read the single element at that location. This will, needless to say,
be both error prone in writing the code and slow in performance.

That you're getting bad values by futzing around this way is not too
surprising; undoubtedly you've missed an offset somewhere or are trying
to read a differing type/size element at the location than was written
there.

All in all, it's one of those things you'd be far better off not doing.

Can you explain the rationale behind this--what problem, specifically,
are you trying to solve that ordering the matrix as needed on retrieval
wouldn't solve much more simply?

--

[ImageAnalyst]

On Jan 2, 10:54 am, dpb <n...@non.net> wrote:
[snip]

>
> All in all, it's one of those things you'd be far better off not doing.
>
> Can you explain the rationale behind this--what problem, specifically,
> are you trying to solve that ordering the matrix as needed on retrieval
> wouldn't solve much more simply?
>

--------------------------------------------------------------------------------------
I agree. Ray, why not just save your data in a .mat file and make
your life simple?

[Ray]

> > All in all, it's one of those things you'd be far better off not doing.
> >
> > Can you explain the rationale behind this--what problem, specifically,
> > are you trying to solve that ordering the matrix as needed on retrieval
> > wouldn't solve much more simply?

> --------------------------------------------------------------------------------------

> I agree. Ray, why not just save your data in a .mat file and make
> your life simple?

> --------------------------------------------------------------------------------------

Ah, okay, the point is, I am working on an assignment to calculate everything inside a reactor. Now, I am working with a program called 'COMSOL' and I need COMSOL to communicate with Matlab through functions. Every timestep and for every element, COMSOL is going to call the function that looks up a vector in the mentioned file. I did this before with .mat files but is is relatively slow. The amount of calls can exceed 13000 times, so every millisecond is important. And the point is, this is just a simple matrix, but I also need the same to work with a 61x61x161 3D array. Since am told that directly accessing binary files is the fastest way of retrieving data, I am trying to get this to work.

I hope this clarifies the setting :)

So, I am still left with the problem that I seem to be unable to retrieve doubles. Any thoughts? :)

[ImageAnalyst]

Your arrays aren't that big, not even the 61x61x161 array. Just suck
up the whole thing and extract the row:

fid = fopen('nine.bin', 'wb');
alldata=rand(9,10)
[rows columns] = size(alldata)
fwrite(fid, alldata, 'double');
fclose(fid);

fid = fopen('nine.bin', 'rb');
allDataRecovered = fread(fid, [rows, columns], '*double')
fclose(fid);
row_5 = allDataRecovered(5, :)

[dpb]

On 1/2/2012 10:30 AM, Ray wrote:
...

> Ah, okay, the point is, I am working on an assignment to calculate
> everything inside a reactor. Now, I am working with a program called
> 'COMSOL' and I need COMSOL to communicate with Matlab through functions.
> Every timestep and for every element, COMSOL is going to call the
> function that looks up a vector in the mentioned file. I did this before
> with .mat files but is is relatively slow. The amount of calls can
> exceed 13000 times, so every millisecond is important. And the point is,
> this is just a simple matrix, but I also need the same to work with a
> 61x61x161 3D array. Since am told that directly accessing binary files
> is the fastest way of retrieving data, I am trying to get this to work.
>
> I hope this clarifies the setting :)

...

Well, "binary" files (really, stream files) are the fastest throughput,
yes, but only when used in fairly sizable chunks that matches both the
structure of the data in the file and the runtime i/o library caching,
etc., etc., etc., ... You will definitely _not_ get any decent
performance by trying to select individual sections out of the file as
discussed before; if anything you'll have far poorer performance.

Where did this "mentioned file" come from? Is it externally generated?
If so, and you're adamant about returning it by row record, write it
that way in the first place--it's the only sane way to attack the
problem. In languages that support it, a direct-access record structure
would be _a_good_thing_ (tm) to use; afaik, Matlab doesn't yet implement
same so you're forced to do the record calculations externally. This is
fraught w/ troubles as you're discovering.

But, even if that individual record is returned that way, it will have
poor overall performance because you'll be returning tiny little more or
less random sections of the file and running the disk heads all over
creation on every access, wiping cache and just killing any chance of
decent throughput.

As IA says, read the file and do the retrieval in memory instead.

--

[dpb]

On 1/2/2012 9:54 AM, Ray wrote:
...

> HOWever, if I make a matrix filled with doubles, this doesn't work at
> all. If I leave everything pretty much the same, the row will come back,
> but all doubles are converted to integers (in this case 0 and 1).
>
> fid = fopen('nine.bin', 'w')
> alldata=rand(9,10)
> fwrite(fid, alldata)

...

> disp(alldata)
> fseek(fid, 4, 'bof');

...

>
> So, I changed uint32 to double, but this gave the same garbage as before:
> row_5 = 1.3907e-309 5.4323e-312 1.3907e-309 7.7468e-304 1.3907e-309
>
> I am close, but still missing something, could anyone please explain this?

Several problems here...

Firstly, fwrite() documentation indicates the default 'precision'
argument value is 'uint8' and you're trying to write doubles. I haven't
tested; I believe Matlab will coerce the argument list to the type
_before_ the write so the 0|1 return seems reasonable result.

Also, if it _were_ doubles, the offset is 8 bytes/element, not 4.

But, as noted elsewhere, this is absolutely the worst possible way to
solve your underlying need possible; forget it, it is _NOT_ a fruitful
direction in which to proceed (other than eventually, you _will_
understand stream files). Once you do get it working (and by
perseverance you will eventually be able to do it although it's so
wrongheaded I'm not providing any further impetus in that direction)
you'll find the actual throughput in practice will be terrible.

--

[Ray]

ImageAnalyst <imagea...@mailinator.com> wrote in message <2e83c16c-0ddc-4d42...@u32g2000yqe.googlegroups.com>...

> Your arrays aren't that big, not even the 61x61x161 array. Just suck
> up the whole thing and extract the row:

Well,..it depend how you look at it, 61*61*161 cells with a vector of 8 doubles in each means almost 4.8 million values which I need to be able to reach every timestep (of a numerical calculation). This means I either have to preload the entire array into memory, which is still significant and slow, or retrieve the values directly from the disk.
Thanks for the code! :)

[Ray]

dpb <no...@non.net> wrote in message <jdstj9$jqp$1...@speranza.aioe.org>...

> Where did this "mentioned file" come from? Is it externally generated?

First of all, thanks for the very useful help and input ;)
It is a matrix (and the other one is an array) filled with molefractions, energy values and molar weights, all put in vectors of 8 elements. These were calculated using a chemical equilibrium (and more) program called 'Cantera', which can be used with Matlab (it is actually a Python program). At first I had COMSOL connected to Cantera through Matlab in real time to do chemical calculations, but this proved extremely slow and memory consuming (to the point of crashing), so I thought it would be better to precalculate all possible output values for all possible input values so that the answers would only have to be retrieved from a matlab datafile (an array, a mat file, a binary file, whatever is the fastest).

> If so, and you're adamant about returning it by row record, write it
> that way in the first place--it's the only sane way to attack the
> problem.

Sorry, but what exactly do you mean by 'writing something in a row record'? I thought making it a matrix was the most 'rowy' it can get? Or are you referring to the array?

> But, even if that individual record is returned that way, it will have
> poor overall performance because you'll be returning tiny little more or
> less random sections of the file and running the disk heads all over
> creation on every access, wiping cache and just killing any chance of
> decent throughput.

Okay, I see your point.

> As IA says, read the file and do the retrieval in memory instead.

Actually, I have tried this already but failed..
The point is, COMSOL calls the matlab function and the first time the function is called, the array (the 61*61*161 one) is not yet loaded into the memory. It takes time to load a mat file of 40MB into the memory but if it is just once at the beginning, further data retrieval from the memory will be fast, of course. But, the problem is, I can't get a function to put something into the memory the first time so that it is still available the next time the same function is called.
The function puts the thing into the memory, does its thing and then forgets everything when the function ends. I have used 'global' and 'persistent' commands, but nothing works. I really do not know of a way to make something stick into the base memory from within a called function (whithout ever using the command line or something).

If you do know a way I would be VERY grateful.


This is what I mean:


function loadC

if exist('C','var') == 0,
disp('C not loaded into base memory yet!');
global C;

load arrayC.mat % just a file with data
end

% do something funky with the data
C{1,3}+2

end

The variable C never shows up in the workspace.

[dpb]

That's still not terribly huge w/ today's memory.

And, altho it's still not clear for certain, if the array is static,
then reading it once into memory at the beginning of the computation
certainly is putting the i/o overhead where it won't hurt during the
actual simulation.

BTW, I'm an old (PWR) reactor engineer, too--but I don't know COMSOL.
What's its area of concern?

--

[Ray]

> And, altho it's still not clear for certain, if the array is static,
> then reading it once into memory at the beginning of the computation
> certainly is putting the i/o overhead where it won't hurt during the
> actual simulation.

It is static, so if there is a way to load it into the memory automatically, that would be fantastic.

> BTW, I'm an old (PWR) reactor engineer, too--but I don't know COMSOL.
> What's its area of concern?

COMSOL is a numerical calculation package that works with modules, so you can do mechanical calculations or chemical ones or heat transfer or flow, etc. And you can link these modules together to calculate what you want (steady, transient, 1D, 2D, 3D, etc).
And it has several different solvers and a geometry importer/builder as well. So it is a nice program, but I am having a lot of trouble with it unfortunately. I want to model the release of volatiles (from wood particles in a tubular reactor) by using equilibrium. I model the volatiles as molecules CxHyOz that are released into the gas stream and decompose there into H2, O2, H2O, CH4, CO, CO2. I use Gibbs Free Energy (with Cantera, the chemical program) to calculate what is formed. But I need to input this data into COMSOL since COMSOL can't do EQ calculations. It works with Matlab, so I am trying that now.

[dpb]

On 1/2/2012 1:21 PM, Ray wrote:
> dpb <no...@non.net> wrote in message <jdstj9$jqp$1...@speranza.aioe.org>...
>> Where did this "mentioned file" come from? Is it externally generated?
>
> First of all, thanks for the very useful help and input ;)
> It is a matrix (and the other one is an array) filled with
> molefractions, energy values and molar weights, all put in vectors of 8

> elements. ...

> thought it would be better to precalculate all possible output values
> for all possible input values so that the answers would only have to be
> retrieved from a matlab datafile (an array, a mat file, a binary file,
> whatever is the fastest).
>
>> If so, and you're adamant about returning it by row record, write it
>> that way in the first place--it's the only sane way to attack the
>> problem.
> Sorry, but what exactly do you mean by 'writing something in a row
> record'? I thought making it a matrix was the most 'rowy' it can get? Or
> are you referring to the array?

I'm talking about your original post wherein you wrote a matrix (which
is column major) then tried to read it in row-major order by
manipulating offsets within the file.

You noted you could have transposed the matrix on write to put it in
that order but for some reason didn't want to. The point is, if you're
adamant about retrieving it in that order in pieces, the only possible
solution w/ any chance of any performance at all is to output it in the
same order in which you will want to read it.

>
>> But, even if that individual record is returned that way, it will have
>> poor overall performance because you'll be returning tiny little more
>> or less random sections of the file and running the disk heads all
>> over creation on every access, wiping cache and just killing any
>> chance of decent throughput.
> Okay, I see your point.

OK, beginning to get over our "failure to communicate"... :)

>> As IA says, read the file and do the retrieval in memory instead.
> Actually, I have tried this already but failed..

...

> ... I can't get a

> function to put something into the memory the first time so that it is
> still available the next time the same function is called. The function
> puts the thing into the memory, does its thing and then forgets
> everything when the function ends. I have used 'global' and 'persistent'
> commands, but nothing works. I really do not know of a way to make
> something stick into the base memory from within a called function
> (whithout ever using the command line or something).

...

> function loadC
if exist('C','var') == 0,
disp('C not loaded into base memory yet!');
global C;
load arrayC.mat % just a file with data
end
>
> % do something funky with the data
> C{1,3}+2
>
> end
>
> The variable C never shows up in the workspace.

Of course not, Matlab (like most modern languages) has function scope
and lifetime.

You haven't created a global variable C in the workspace if this is all
you have done. That would be one solution altho and one place where
global data wouldn't be all bad but it's still not what I'd choose as
the first solution.

In the main routine when you start the Matlab program just do

load arrayC.mat;

and you will have the data in the base workspace. Then, assuming the
above .mat file contains only an array 'C' that will be the name and
when you call whatever functions you need from the main script, simply
pass C to those functions which need it. Matlab is smart and will not
make needless copies so there's no additional memory or performance
issues to worry about.

The alternative is in the main routine to do sorta' as you did above and say

global C
load arrayC.mat;

then add global c into each function that needs access to it. You begin
to see already the problems global raises; you have to keep dragging the
definitions around to ensure you don't have a local variable C instead
of the global one and if you accidently do something to it in one of
these functions you've done it everywhere making debugging tough.

All in all, I'd recommend the non-global solution.

--

[dpb]

On 1/2/2012 1:42 PM, Ray wrote:
>> And, altho it's still not clear for certain, if the array is static,
>> then reading it once into memory at the beginning of the computation
>> certainly is putting the i/o overhead where it won't hurt during the
>> actual simulation.
> It is static, so if there is a way to load it into the memory
> automatically, that would be fantastic.

...

Of course there is... :)

See other response for details.

OK, I see you're doing different "reactor" than I presumed...was a ChE
minor (thought reprocessing was the wave of the future when in school so
was getting all set) but it's not my first thought when see the reference...

--

[Ray]

> > The variable C never shows up in the workspace.

> Of course not, Matlab (like most modern languages) has function scope
> and lifetime.
>
> You haven't created a global variable C in the workspace if this is all
> you have done. That would be one solution altho and one place where
> global data wouldn't be all bad but it's still not what I'd choose as
> the first solution.
>
> In the main routine when you start the Matlab program just do
>
> load arrayC.mat;
>
> and you will have the data in the base workspace. Then, assuming the
> above .mat file contains only an array 'C' that will be the name and
> when you call whatever functions you need from the main script, simply
> pass C to those functions which need it. Matlab is smart and will not
> make needless copies so there's no additional memory or performance
> issues to worry about.

I understand that, but as I pointed out, I have to deal with another program (COMSOL) and I already tried preloading data to the memory from the command line, but COMSOL does not see this, so I am forced to really let Matlab handle it itself. But since I have no control over matlab during calculation I really need this to happen inside a function. So, I can't load it on beforehand.

> The alternative is in the main routine to do sorta' as you did above and say
>
> global C
> load arrayC.mat;
>
> then add global c into each function that needs access to it. You begin
> to see already the problems global raises; you have to keep dragging the
> definitions around to ensure you don't have a local variable C instead
> of the global one and if you accidently do something to it in one of
> these functions you've done it everywhere making debugging tough.
>
> All in all, I'd recommend the non-global solution.

Maybe I am not following you entirely, but this still requires the function to load arrayC.mat every time it is called, does it not?

As long as it loads only once (ONLY the first time the function is called) and stays available for later (new) queries (after ending the last one) by the same function (without reloading the entire array into memory) it is ok.
I do, however, understand the problems that can arise from using global variables, but I am really running out of options, I need this to work somehow. :)

[dpb]

On 1/2/2012 3:23 PM, Ray wrote:
...

> I understand that, but as I pointed out, I have to deal with another
> program (COMSOL) and I already tried preloading data to the memory from
> the command line, but COMSOL does not see this, so I am forced to really
> let Matlab handle it itself. But since I have no control over matlab
> during calculation I really need this to happen inside a function. So, I
> can't load it on beforehand.

...

> Maybe I am not following you entirely, but this still requires the
> function to load arrayC.mat every time it is called, does it not?
> As long as it loads only once (ONLY the first time the function is
> called) and stays available for later (new) queries (after ending the
> last one) by the same function (without reloading the entire array into
> memory) it is ok.

...

Well, if it is only in a function and there isn't a global of the same
name in the base workspace then its lifetime is indeed going to be
limited to the time the function is invoked.

I don't follow how the link to Matlab is being done explicitly; I'm
guessing from the above description that actually it is the other
program that is the driver here as opposed to Matlab?

If so, I guess it's calling the Matlab engine and executing commands
there and then returning. How do you control what Matlab does; is there
a link to any online documentation that describes that interface
succinctly could look at? I'd think there would have to be some way for
it to have some sort of initialization process that should be able to be
used; just w/o the details I'm at a loss to say precisely what that
would be.

The other thought that comes to mind is can you instead start the other
program _from_ Matlab via a system() command? If so, then the workspace
of the function which does that is in scope.

Think need more specifics to help more...

--

[dpb]

On 1/2/2012 3:36 PM, dpb wrote:
> On 1/2/2012 3:23 PM, Ray wrote:

> ....

>
>> I understand that, but as I pointed out, I have to deal with another
>> program (COMSOL) and I already tried preloading data to the memory from
>> the command line, but COMSOL does not see this, so I am forced to really
>> let Matlab handle it itself. But since I have no control over matlab
>> during calculation I really need this to happen inside a function. So, I
>> can't load it on beforehand.

> ....

>
>> Maybe I am not following you entirely, but this still requires the
>> function to load arrayC.mat every time it is called, does it not?
>> As long as it loads only once (ONLY the first time the function is
>> called) and stays available for later (new) queries (after ending the
>> last one) by the same function (without reloading the entire array into
>> memory) it is ok.
>

> ....

>
> Well, if it is only in a function and there isn't a global of the same
> name in the base workspace then its lifetime is indeed going to be
> limited to the time the function is invoked.

...

Whoa...I misspoke above; wasn't thinking through entirely.

If each and every function that needs the array declares it as global,
then as long as your program isn't starting a new instance of Matlab on
each invocation, it should be available in each of those functions.

It will, however, be invisible to the base workspace and any function(s)
which do not declare it as global.

That _should_ suffice if you use something like isglobal() to check for
existence.

doc global

for example of two functions sharing a global (tic/toc)

--

[Steven_Lord]

"Ray " <vomu...@sharklasers.com> wrote in message
news:jdt034$524$1...@newscl01ah.mathworks.com...

> dpb <no...@non.net> wrote in message <jdstj9$jqp$1...@speranza.aioe.org>...

*snip*

> function loadC
>
> if exist('C','var') == 0,
> disp('C not loaded into base memory yet!');
> global C;
> load arrayC.mat % just a file with data
> end

Don't do it like this.

function loadC
persistent C
if isempty(C )
C = load('arrayC.mat');
end
% now use C

This will only load the data once (unless the MAT-file contains no
variables, in which case the LOADing should be fast..

Alternately, depending on how you set up the problem for COMSOL, this
technique may do the trick:

http://www.mathworks.com/help/techdoc/math/bsgprpq-5.html

LOAD the data once, pass it into the function as an additional parameter to
a function handle.

--
Steve Lord
sl...@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

[dpb]

On 1/2/2012 9:03 PM, Steven_Lord wrote:
...

> function loadC
> persistent C
...

Ah; newer feature than in my version of Matlab--nice.

--

[Steven_Lord]

"dpb" <no...@non.net> wrote in message news:jdv11b$v92$1...@speranza.aioe.org...

I thought you were using release R12 (MATLAB 6.0) or R13 (version 6.5) -- I
believe persistent variables were introduced in MATLAB 5.2, which if we
count backwards would be R10.

[dpb]

On 1/3/2012 8:21 AM, Steven_Lord wrote:
...

> I thought you were using release R12 (MATLAB 6.0) or R13 (version 6.5)
> -- I believe persistent variables were introduced in MATLAB 5.2, which
> if we count backwards would be R10.

Well, I'll be...I had never stumbled across them (or if had, had
completely forgotten about them).

Maybe after about 12 yr or so I ought to reread the Release Notes... :)

--

[Ray]

> Whoa...I misspoke above; wasn't thinking through entirely.
>
> If each and every function that needs the array declares it as global,
> then as long as your program isn't starting a new instance of Matlab on
> each invocation, it should be available in each of those functions.
>
> It will, however, be invisible to the base workspace and any function(s)
> which do not declare it as global.
>
> That _should_ suffice if you use something like isglobal() to check for
> existence.
>
> doc global
>
> for example of two functions sharing a global (tic/toc)

Okay, I will look into this, thanks :)

[Ray]

> I don't follow how the link to Matlab is being done explicitly; I'm
> guessing from the above description that actually it is the other
> program that is the driver here as opposed to Matlab?

Yes, as soon as COMSOL encounters a matlab function during solving, it establishes a link to matlab (which you don't have to open yourself) and a COMSOL/matlab commandline appears.

> If so, I guess it's calling the Matlab engine and executing commands
> there and then returning.

Indeed.

> How do you control what Matlab does; is there
> a link to any online documentation that describes that interface
> succinctly could look at?
> I'd think there would have to be some way for
> it to have some sort of initialization process that should be able to be
> used; just w/o the details I'm at a loss to say precisely what that
> would be.
> The other thought that comes to mind is can you instead start the other
> program _from_ Matlab via a system() command? If so, then the workspace
> of the function which does that is in scope.

There is not really a lot of documentation available unfortunately. There is a pfd enclosed in the package itself, but that only describes the Livelink mode, which means, as you kind of thought of already, that you can start COMSOL from Matlab. This IS possible, but I have been trying to avoid this, since it is slower and makes everything a LOT more complicated. But if there is no other way..

[Ray]

"Steven_Lord" <sl...@mathworks.com> wrote in message <jdtr6j$l52$1...@newscl01ah.mathworks.com>...

>
>
> "Ray " <vomu...@sharklasers.com> wrote in message
> news:jdt034$524$1...@newscl01ah.mathworks.com...
> > dpb <no...@non.net> wrote in message <jdstj9$jqp$1...@speranza.aioe.org>...
>
> *snip*
>
> > function loadC
> >
> > if exist('C','var') == 0,
> > disp('C not loaded into base memory yet!');
> > global C;
> > load arrayC.mat % just a file with data
> > end
>
> Don't do it like this.
>
> function loadC
> persistent C
> if isempty(C )
> C = load('arrayC.mat');
> end
> % now use C

By 'don't do it like this' you mean my code right? Not the one with the persistent command in it? :)

> This will only load the data once (unless the MAT-file contains no
> variables, in which case the LOADing should be fast..

Okay, thanks. It will stay in the memory then to be available for the next time the same function is called, after the current run of this function ends, right?

> Alternately, depending on how you set up the problem for COMSOL, this
> technique may do the trick:
>
> http://www.mathworks.com/help/techdoc/math/bsgprpq-5.html
>
> LOAD the data once, pass it into the function as an additional parameter to
> a function handle.

I have to look into this, but (I don't know if this is the same as you mean) I tried passing the entire array as a function input before (something like: function molfraction = arraycallfunction(input1, input2, arrayC)) but this didn't work because input1 and input2 were vectors and arrayC isn't but apparently Matlab expects all inputs to be the same, so I couldn't split this up. Again, I am not sure this is what you mean, but this at least didn't work (maybe I did something wrong of course..).
Thanks for the help. :)

[dpb]

On 1/3/2012 10:16 AM, Ray wrote:
...

>> LOAD the data once, pass it into the function as an additional
>> parameter to a function handle.
> I have to look into this, but (I don't know if this is the same as you
> mean) I tried passing the entire array as a function input before
> (something like: function molfraction = arraycallfunction(input1,
> input2, arrayC)) but this didn't work because input1 and input2 were
> vectors and arrayC isn't but apparently Matlab expects all inputs to be

> the same,...

No, that's not true; Matlab allows any combination of arguments.

Of course, the calling function and the function definition must agree,
but there's no requirement like that you presumed was the problem.

What does the arraycallfunction() definition look like? Is it something
you wrote or is it a COMSOL-supplied routine, perhaps? If that were the
case, then it is quite possible it does only expect two input vectors.

Again, lacking any information on how this interface actually functions,
it's difficult to say anything _too_ specific.

--