Thread Subject: parfor: fopen Issues

I have a simulation which runs over ‘n’ successive iterations using the parfor command. At each iteration, a series of scripts are generated using the fopen command; these contain user-defined commands for an external program. MATLAB then runs the script file and saves the results. The files are named according to the index of the parfor command (e.g parfor ii = 1:20). I am using the MATLABPOOL with a local scheduler.

At each iteration the contents of the files are updated i.e. files are never deleted the naming index remains according to the state of the parfor command and the contents (user-defined script commands) are updated.

On most occasions the simulations run successfully with no issues. However, on some rare occasions an error is reported relating the failure of fopen as:

??? Error using ==> parallel_function at 587
Error in ==> Main_Flight at 70
Invalid file identifier. Use fopen to generate a valid file identifier.

Error in ==> Optz_v2 at 203
    matlabpool local 4

The code where MATLAB is pointing to is as:
script = [mesh_prefix, int2str(ii),'.bat'];
[fidd] = fopen(script, 'wt');
fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');
fclose all

I’m not sure why MATLAB won’t open the file in question as it is in the working directory. As I mentioned earlier, the simulations run successfully on most occasions however, there is an obvious scenario which results in this error. Any suggestions please?

"Mr. CFD" <s2108860@student.rmit.edu.au> writes:

> I have a simulation which runs over ‘n’ successive iterations
> using the parfor command. At each iteration, a series of scripts are generated
> using the fopen command; these contain user-defined commands for an external
> program. MATLAB then runs the script file and saves the results. The files are
> named according to the index of the parfor command (e.g parfor ii = 1:20). I
> am using the MATLABPOOL with a local scheduler.
>
> At each iteration the contents of the files are updated i.e. files are never
> deleted the naming index remains according to the state of the parfor command
> and the contents (user-defined script commands) are updated.
>
> On most occasions the simulations run successfully with no issues. However, on
> some rare occasions an error is reported relating the failure of fopen as:
>
> ??? Error using ==> parallel_function at 587
> Error in ==> Main_Flight at 70
> Invalid file identifier. Use fopen to generate a valid file identifier.
>
> Error in ==> Optz_v2 at 203
> matlabpool local 4
>
> The code where MATLAB is pointing to is as:
> script = [mesh_prefix, int2str(ii),'.bat'];
> [fidd] = fopen(script, 'wt');
> fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');
> fclose all

That seems to me as thought it should work. The main risk is that some other
process has the file open for writing - on Windows, you cannot have two
processes writing to the same file simultaneously, and any second call to fopen
will fail. A couple of suggestions:

1. Replace your fopen line with something like this:

[fidd, message] = fopen( script, 'wt' );
if fidd == -1
  error( 'Couldn''t write to %s: %s', script, message );
end

2. Replace your fclose line with something like this:

st = fclose( fidd );
if st ~= 0
  error( 'Error code from close: %d, file: %s', st, script );
end

Hopefully that will help pinpoint which files are failing to open or close, and
possibly even why.

Cheers,

Edric.

Edric M Ellis <eellis@mathworks.com> wrote in message <ytw1vp9omj1.fsf@uk-eellis-deb4-64.mathworks.co.uk>...
> "Mr. CFD" <s2108860@student.rmit.edu.au> writes:
>
> > I have a simulation which runs over ‘n’ successive iterations
> > using the parfor command. At each iteration, a series of scripts are generated
> > using the fopen command; these contain user-defined commands for an external
> > program. MATLAB then runs the script file and saves the results. The files are
> > named according to the index of the parfor command (e.g parfor ii = 1:20). I
> > am using the MATLABPOOL with a local scheduler.
> >
> > At each iteration the contents of the files are updated i.e. files are never
> > deleted the naming index remains according to the state of the parfor command
> > and the contents (user-defined script commands) are updated.
> >
> > On most occasions the simulations run successfully with no issues. However, on
> > some rare occasions an error is reported relating the failure of fopen as:
> >
> > ??? Error using ==> parallel_function at 587
> > Error in ==> Main_Flight at 70
> > Invalid file identifier. Use fopen to generate a valid file identifier.
> >
> > Error in ==> Optz_v2 at 203
> > matlabpool local 4
> >
> > The code where MATLAB is pointing to is as:
> > script = [mesh_prefix, int2str(ii),'.bat'];
> > [fidd] = fopen(script, 'wt');
> > fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');
> > fclose all
>
> That seems to me as thought it should work. The main risk is that some other
> process has the file open for writing - on Windows, you cannot have two
> processes writing to the same file simultaneously, and any second call to fopen
> will fail. A couple of suggestions:
>
> 1. Replace your fopen line with something like this:
>
> [fidd, message] = fopen( script, 'wt' );
> if fidd == -1
> error( 'Couldn''t write to %s: %s', script, message );
> end
>
> 2. Replace your fclose line with something like this:
>
> st = fclose( fidd );
> if st ~= 0
> error( 'Error code from close: %d, file: %s', st, script );
> end
>
> Hopefully that will help pinpoint which files are failing to open or close, and
> possibly even why.
>
> Cheers,
>
> Edric.

Hi Edric,

Thanks for the message.
This could explain why the job also fails on some occasions on a cluster. Will try your suggestions and see how it goes.

In the meantime, I did not know that a file could be operated on by two processes simulatenosuly. Just to avoid this scenario, seperate script files were created and named in accordance to the index of the parfor command; so that these files were analysed seperately by the proccesses depending on the distribution of 'n' in [parfor ii = 1:n]

Assuming this is the reason why we have the error (have not tried your suggestions as yet), how do you propose to solve this please?

"Mr. CFD" <s2108860@student.rmit.edu.au> writes:

> In the meantime, I did not know that a file could be operated on by two
> processes simulatenosuly. Just to avoid this scenario, seperate script files
> were created and named in accordance to the index of the parfor command; so
> that these files were analysed seperately by the proccesses depending on the
> distribution of 'n' in [parfor ii = 1:n]

Your original code looked to me as though it should work, and basing the
filename on the parfor loop variable is a good approach - so I was trying to
suggest how you might find out why you can't write to the file.

> Assuming this is the reason why we have the error (have not tried your
> suggestions as yet), how do you propose to solve this please?

You could use "tempname" to generate a unique filename for each iteration; but
it would probably be good to debug why you are getting the clashes with your
current approach.

Cheers,

Edric.

Edric M Ellis <eellis@mathworks.com> wrote in message <ytwws71mzoq.fsf@uk-eellis-deb4-64.mathworks.co.uk>...
> "Mr. CFD" <s2108860@student.rmit.edu.au> writes:
>
> > In the meantime, I did not know that a file could be operated on by two
> > processes simulatenosuly. Just to avoid this scenario, seperate script files
> > were created and named in accordance to the index of the parfor command; so
> > that these files were analysed seperately by the proccesses depending on the
> > distribution of 'n' in [parfor ii = 1:n]
>
> Your original code looked to me as though it should work, and basing the
> filename on the parfor loop variable is a good approach - so I was trying to
> suggest how you might find out why you can't write to the file.
>
> > Assuming this is the reason why we have the error (have not tried your
> > suggestions as yet), how do you propose to solve this please?
>
> You could use "tempname" to generate a unique filename for each iteration; but
> it would probably be good to debug why you are getting the clashes with your
> current approach.
>
> Cheers,
>
> Edric.

Hi Edric,
Added the things you suggested as:
script = [mesh_prefix, int2str(ii),'.bat'];
[fidd, message] = fopen(script, 'wt');
if fidd == -1
    error( 'Couldn''t write to %s: %s', script, message );
end
fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');

Had the following error appear about an hour into the simulation:
=============================================
??? Error using ==> parallel_function at 587
Error in ==> Main_Flight at 76
Couldn't write to Airfoil_3.bat: Invalid argument

Error in ==> Main_Optz_v2 at 203
    matlabpool local 4
==============================================
So does this mean that more then one processor was trying to access 'Airfoil_3.bat' in this case?
I really don't know how I can avoid this. The use of parfor is necessary to accelerate computation, but how do we avoid this file conflict?
Thanks

"Mr. CFD" <s2108860@student.rmit.edu.au> writes:

> Hi Edric,
> Added the things you suggested as:
> script = [mesh_prefix, int2str(ii),'.bat'];
> [fidd, message] = fopen(script, 'wt');
> if fidd == -1
> error( 'Couldn''t write to %s: %s', script, message );
> end
> fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');
>
> Had the following error appear about an hour into the simulation:
> =============================================
> ??? Error using ==> parallel_function at 587
> Error in ==> Main_Flight at 76
> Couldn't write to Airfoil_3.bat: Invalid argument
>
> Error in ==> Main_Optz_v2 at 203
> matlabpool local 4
> ==============================================
> So does this mean that more then one processor was trying to access 'Airfoil_3.bat' in this case?
> I really don't know how I can avoid this. The use of parfor is necessary to
> accelerate computation, but how do we avoid this file conflict? Thanks

I don't think that looks like concurrent access. Are you writing the files onto
a network drive somewhere? If so, that could be one possible cause of that error
message. It might be worth trying to use a local disk for the .bat files. It
might just also be worth pausing and trying again on failure to fopen.

Cheers,

Edric.

Edric M Ellis <eellis@mathworks.com> wrote in message <ytwk530n3wc.fsf@uk-eellis-deb4-64.mathworks.co.uk>...
> "Mr. CFD" <s2108860@student.rmit.edu.au> writes:
>
> > Hi Edric,
> > Added the things you suggested as:
> > script = [mesh_prefix, int2str(ii),'.bat'];
> > [fidd, message] = fopen(script, 'wt');
> > if fidd == -1
> > error( 'Couldn''t write to %s: %s', script, message );
> > end
> > fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');
> >
> > Had the following error appear about an hour into the simulation:
> > =============================================
> > ??? Error using ==> parallel_function at 587
> > Error in ==> Main_Flight at 76
> > Couldn't write to Airfoil_3.bat: Invalid argument
> >
> > Error in ==> Main_Optz_v2 at 203
> > matlabpool local 4
> > ==============================================
> > So does this mean that more then one processor was trying to access 'Airfoil_3.bat' in this case?
> > I really don't know how I can avoid this. The use of parfor is necessary to
> > accelerate computation, but how do we avoid this file conflict? Thanks
>
> I don't think that looks like concurrent access. Are you writing the files onto
> a network drive somewhere? If so, that could be one possible cause of that error
> message. It might be worth trying to use a local disk for the .bat files. It
> might just also be worth pausing and trying again on failure to fopen.
>
> Cheers,
>
> Edric.

Hi Edric,
All files are created and saved in the working directory where the original code is launched from (c:\ drive). So is this suggesting that more then one processor is trying to access a single .bat file, which may already be open?
  

"Mr. CFD" <s2108860@student.rmit.edu.au> writes:

> Edric M Ellis <eellis@mathworks.com> wrote in message <ytwk530n3wc.fsf@uk-eellis-deb4-64.mathworks.co.uk>...
>> "Mr. CFD" <s2108860@student.rmit.edu.au> writes:
>>
>> > Hi Edric,
>> > Added the things you suggested as:
>> > script = [mesh_prefix, int2str(ii),'.bat'];
>> > [fidd, message] = fopen(script, 'wt');
>> > if fidd == -1
>> > error( 'Couldn''t write to %s: %s', script, message );
>> > end
>> > fprintf(fidd, '%s','Cscript.exe //NoLogo Airfoil_',num2str(ii),'.vbs | xfoil.exe');
>> >
>> > Had the following error appear about an hour into the simulation:
>> > =============================================
>> > ??? Error using ==> parallel_function at 587
>> > Error in ==> Main_Flight at 76
>> > Couldn't write to Airfoil_3.bat: Invalid argument
>> >
>> > Error in ==> Main_Optz_v2 at 203
>> > matlabpool local 4
>> > ==============================================
>> > So does this mean that more then one processor was trying to access 'Airfoil_3.bat' in this case?
>> > I really don't know how I can avoid this. The use of parfor is necessary to
>> > accelerate computation, but how do we avoid this file conflict? Thanks
>>
>> I don't think that looks like concurrent access. Are you writing the files onto
>> a network drive somewhere? If so, that could be one possible cause of that error
>> message. It might be worth trying to use a local disk for the .bat files. It
>> might just also be worth pausing and trying again on failure to fopen.
>>
>> Cheers,
>>
>> Edric.
>
> Hi Edric, All files are created and saved in the working directory where the
> original code is launched from (c:\ drive). So is this suggesting that more
> then one processor is trying to access a single .bat file, which may already
> be open?

To be honest, I'm not sure - although it doesn't look like concurrent access
(and the way your code is structured should preclude that in any case). I must
admit I don't know why you're getting that error message from a local disk -
it's just about conceivable that you could get that message with a failed
connection to a network drive, but it shouldn't really apply to C:\. Perhaps you
could try something like this:

fh = -1; numTries = 0;
while fh == -1 && numTries < 5
  [fh, message] = fopen( script, 'wt' );
  numTries = numTries + 1;
  if fh == -1
    % failure - print a warning, wait
    pause(1);
    warning( 'Failed to open %s (%s), will try again', script, message );
  end
end
if fh == -1
  error( 'Failed to open file even with retries' );
end

(which is, of course, ugly and should be unncessary...)

Cheers,

Edric.