0

I am an MPI and Fortran 77 noob. I have a fortran 77 code FKRPRO.f which I wanted to parallelize using OpenMPI. The code requires a lot of parameters which are fed into it during run time from a separate file. Compilation and running is something like this

gfortran -o FKRPRO FKRPRO.f
./FKRPRO < Modelfile.txt

the equivalent lines in the code (not my code) are

      PARAMETER(LIN=5)
      INTEGER ERROR
      LOGICAL PRNTA
      PRNTA=.FALSE.
      READ(LIN,'(L3)') PRNTA
      READ(LIN,21) M1,M2
   21 FORMAT(11I5)

and so on. Can someone please explain to me what READ(LIN,'(L3)') PRNTA means. The input in the input file Modelfile.txt is something like this 

.F.                                                                             
    0   64  
and so on..

I put the necessary MPI statements in the code. 

      INCLUDE 'MPIF.H'
...
      CALL MPI_INIT(ERROR)
      CALL MPI_COMM_SIZE(MPI_COMM_WORLD,NPROCS,ERROR)
      CALL MPI_COMM_RANK(MPI_COMM_WORLD,PRANK,ERROR)
...
      CALL MPI_TYPE_FREE(NEWMATRIX,ERROR)
      CALL MPI_FINALIZE(ERROR)

All processes are not being able to read the input file. I have compiled and run the code like this

mpif77 -o bc3 FKRPROG5.f
mpirun -np 4 bc3 < Modelfile.txt

This is not working. I get the following errors. Only the first process or rank 0 can read the file.

At line 50 of file FKRPROG5.f (unit = 5, file = 'stdin')
Fortran runtime error: End of file
At line 50 of file FKRPROG5.f (unit = 5, file = 'stdin')
Fortran runtime error: End of file
At line 50 of file FKRPROG5.f (unit = 5, file = 'stdin')
Fortran runtime error: End of file
mpirun has exited due to process rank 3 with PID 866 on
node Avinash-rMBP.local exiting improperly. There are two reasons this could occur:

1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.

2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"

This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).

50th line is READ(LIN,'(L3)') PRNTA.Someone kindly point out where I am going wrong :( So, how can I make all processes read from this input file < Modelfile.txt ?? Thanks.

Alexander Vogt
  • 17,879
  • 13
  • 52
  • 68
Guddu
  • 2,325
  • 2
  • 18
  • 23

1 Answers1

5

The statement

READ(LIN,'(L3)') PRNTA

causes the program to read, from the unit attached to the channel with id LIN, a 3-character sequence which represents a logical value and assigns the value read to the variable PRNTA. From the fragments you've shown us the program will read .F. and set PRNTA to .false..

LIN is set to the constant value 5, which usually means stdin. This use of 5 to denote stdin is not a de jure standard, it is more of a de facto standard.

The straightforward way to read a parameter file into an MPI program is to ensure that only one process reads the file and then sends out the values to the other processes which need them.

You seem to have written a program in which all processes try to read the same input file but, at run-time, the redirection you've used to pass Modelfile.txt is only working for one process (presumably the process with rank 0). The other processes are not getting an input file at all and are complaining, then bringing the program crashing down. The error message you show is typical of a Fortran program which doesn't find an input file at all when it tries to read.

Far better to write code along the lines:

call mpi_init ...
...
if (myrank==0) then
    open(...) inputfile
    read(...) parameters
    close(...)
end if
...
call mpi_bcast(parameters from 0 to all)
...

In general, don't expect the run-time environment for MPI processes to be identical copies of the run-time environment for a sequential program. I think that you are seeing evidence that your run-time directs the input only to the first process created when your program runs. Since mpirun is not standardised (though mpiexec is) I don't think you can rely on this run-time behaviour being the same for all MPI implementations. For portability and compatibility you're better off handling I/O explicitly within your program than using o/s features such as redirection.

You could, rather than have process 0 read the parameters and distribute them to other processes, write your code such that each process reads the same file. If you do write your code this way take care to ensure that the processes aren't fighting over access to the I/O channels; having multiple processes trying to (nearly-)simultaneously read across a single input channel is a sure way to slow things down.

High Performance Mark
  • 77,191
  • 7
  • 105
  • 161
  • @HighPermonaceMark: Dear Mark! Just out of curiosity, what is your experience? Is concurrent reading really slowing things done? Is it always the case or only for large files? Is it file system dependent? I know many codes (including ours) for which the (admittedly only few kB small) input file is read by all threads concurrently, and it does not seem to be any kind of bottleneck. (On the other hand, having written to the same file concurrently by mistake had a real huge impact). – Bálint Aradi Oct 03 '13 at 09:45
  • @BálintAradi: Match these statements to yours: Extensive, including machines with 0000s of processors and parallel i/o. Concurrent access to small files by small numbers of process, probably not causing enough slow-down to fret about. Test and measure, don't take my word on this. Yes, o/s and file system dependent, and h/w dependent. YMMV, or, to be more accurate, your experience does vary. (Not surprised). Finally, advice offered in this answer is aimed at the neophyte OP, your footprint on SO suggests you are mature enough to figure most of this out for yourself. – High Performance Mark Oct 03 '13 at 10:00
  • Thanks! Sorry for my formulation above, I realized that it reads maybe somewhat offending, which it was definitely not meant to be. I did not question your experience. On the contrary, I askedfor advice in that matter, as we are at the beginning of our parallelization project, and I'd like to avoid making bad design decisions stamming from lack of experience on my side. Unfortunately, I do not have access to that large scale machines as you do, so my testing possibilities are rather limited. – Bálint Aradi Oct 03 '13 at 10:46
  • I/O redirection is not even mentioned in the standard so one cannot have portability in that respect. Still most implementations take the sane approach and redirect `mpiexec`'s standard I/O to rank 0. – Hristo Iliev Oct 03 '13 at 10:46
  • 1
    @BálintAradi: I wasn't in the least offended, I read your comment as (I think) you intended. If you're starting an extensive code parallelisation then I recommend you investigate i/o on your own systems and quantify the various effects that I have touched on. Typically we use serial i/o on process 0 for small files (such as job parameters) then an MPI_BCAST. For large files, sometimes parallel i/o, sometimes let the processes read their own chunks sequentially. And sometimes we just let the processes fight over a single drive head and accept the consequences. – High Performance Mark Oct 03 '13 at 10:55
  • I have just marked this question as favorite due to these comments. – Kyle Kanos Oct 03 '13 at 13:10
  • I'm thinking if you want to have all process concurrently read from the file they each need to seperately Open() the file, and likely each with a unique unit number. – agentp Oct 03 '13 at 13:49
  • 1
    @BálintAradi: MPI provides a very extensive API for parallel I/O with data views, stream access and so on. ROMIO, which is an implementation of MPI I/O used by most universal MPI libraries like MPICH, Open MPI, and so on, knows how to explicitly handle certain file systems in such way as to achieve maximum **and portable** performance. Even when it comes to accessing small files, MPI I/O could be faster than the Fortran or C run-time library functions. – Hristo Iliev Oct 04 '13 at 10:24