Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: parfor: fopen Issues
Date: Wed, 24 Jun 2009 14:53:02 +0000 (UTC)
Organization: RMIT
Lines: 64
Message-ID: <h1teke$q6c$1@fred.mathworks.com>
References: <h1t155$jbg$1@fred.mathworks.com> <ytw1vp9omj1.fsf@uk-eellis-deb4-64.mathworks.co.uk>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1245855182 26828 172.30.248.37 (24 Jun 2009 14:53:02 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 24 Jun 2009 14:53:02 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1372013
Xref: news.mathworks.com comp.soft-sys.matlab:550295


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 &#8216;n&#8217; 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?