Parallel_Function error 598 and fprintf

I am running the parallel version of Genetic Algorithm and am running into some parallel issues. When I try to run on Parallel I recieve the error:

Error using ==> parallel_function at 598 Error in ==> filename at 63 Invalid format.

The line it refers to has a simple fprintf line where the file it is writing to is a simple text file:

           fid=fopen('textfile_lab.txt','w');
           i=1;
           while i<=length(text)
Line 63        fprintf(fid,text{i});
               i=i+1;
           end

I have different text files for the four different labs that should be running simultaneously. Does any one have any ideas why this is coming up or how to fix it? Thank you.

[Thomas Ibbotson]

Hi Jason,

That error message occurs when the second argument to the fprintf function is not a string. What determines the value of the 'text' variable in your code?

[Jason]

The code I use to build the 'text'

variable is.

fid=fopen('filename_lab.txt','r');

i = 1;

while feof(fid) ~= 1

text{i,1}=fgetl(fid);

i = i+1;

end

fclose(fid);

where filename_1.txt is a simple text file

[Thomas Ibbotson]

If any of the filename_lab.txt files are empty then fgetl(fid) will return -1, which will cause the error you are seeing.

[Jason]

They are all filled text files with very similar text. Changing to 'fgets' would only add in the end line character and would do nothing to effect the results I believe too.

[Jason]

To differentiate between workers, I am using: if labindex==1 to differentiate which text file to read and write from. Any chance this is being violated and ignored and therefore constantly this first text file is being manipulated wrong? When I am running it it seems that when re-writing to the text file, something is tripping up since the data isn't being written and modified correctly.

[Thomas Ibbotson]

Are you able to reduce your code to a minimal example that reproduces the problem you are seeing? Does the code work without using the parallel features?

[Jason]

The code works fine without parallel. It just happens that when I introduce parallel that something gets messed up in the editing of these text files.

I have rewritten to use:

file0run= ['MCrun0_' num2str(labindex) '.txt'];

as my indicators to which file to read and write to. This snippet is what reads the files and puts them into an array.

fid=fopen(file0run,'rt');

i = 1;

while i<=25

text0_1{i,1}=fgetl(fid);

i = i+1;

end

fclose(fid);

I then modify some parts of the array and rewrite them to a text file using:

fid=fopen(file0run,'wt');

i=1;

while i<=length(text0_1)

if i==16 || i==18

fprintf(fid,'%g',alpha);

fprintf(fid,'\n');

i=i+1;

elseif i==10 fprintf(fid,'%g',Mach(k)); fprintf(fid,'\n');

i=i+1;

elseif i==8

Re=Mach(k)*Us/.00185; fprintf(fid,'%g',Re); fprintf(fid,'\n'); i=i+1;

else

fprintf(fid,text0_1{i,1});

fprintf(fid,'\n');

i=i+1;

end

end

fclose(fid);

I know there are slicker ways to do this but I'm more concerned with the errors I am seeing. Somehow end of file characters get inserted within the text file causing everything to end prematurely and therefore the error is seen (from what I believe). I am not sure why this is happening. I have tested it not in parallel and everything works fine.

Answer 1

[Walter Roberson]

This was also asked in the newsgroup. My answer there was:

You are writing to a fixed filename in each of the parallel threads. Sometimes when you try to open the file, another thread will already have the file open. In such a case the fopen will fail and return a negative number. You do not test for that possibility, and you use the negative number in fprintf. fprintf recognizes that the negative number cannot be a valid file identifier and tries to make sense of it as a format instead.

To this I would add that 'filename_lab.txt' is taken literally. Try

sprintf('filename_%d.txt,lab)

to get a lab-dependent name.

[Jason]

Currently it is written to be lab dependent. Right now I am having some other issues with my text files written in windows format applying to a Unix format. Line carriages are not carried along and there seem to be some hidden characters which are also messing things up.

[Walter Roberson]

Cross reference for getting the lab-dependent file name: http://www.mathworks.com/matlabcentral/answers/184-parallel-computing-and-save-function

[Walter Roberson]

Text files should always be opened with 'wt' instead of 'w', and should be read with 'rt' instead of 'r'.

[Walter Roberson]

Can you say more about the hidden characters? Are you able to obtain their value, such as by reading the file as binary and double() the string to determine the character values?

[Jason]

What is happening is that somewhere in this process the text file which is constantly being updated somehow begins to be overwritten in white space and so the error occurs. What I am doing now is including the lab dependent writing and also I will use 'wt' and 'rt' and see what happens. If I still run into the problem where the text file is still not copying correctly, I will post again. Thanks for your help!

Answer 2

[Walter Roberson]

Your present code

i=1;
while i<=length(text)
  fprintf(fid,text{i});
  i=i+1;
end

can be replaced entirely by

fprintf(fid, '%s\n', text{:});

(Assuming, that is, that text is not actually a 2D cell array of strings.)

Answer 3

[Walter Roberson]

An answer from the newsgroup is that labindex is a constant for PARFOR and is only distinct for SMPD . A method to get the job id was shown in the newsgroup.