[OMPI users] Typo in mpi-fort-wrapper-data.txt?
Hello users,
I was installing a new OS this week (Xubuntu 17.10 to be exact) and
pulled down the latest OMPI from apt on the machine. While trying to
compile a MPI Fortran program I noticed the following:
josh@josh-UX490UA:/usr/share/openmpi$ mpifort --showme
gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread
-I/usr/lib/x86_64-linux-gnu/openmpi/lib *-L/usr//lib*
-L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_usempif08
-lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
Noticing the double //, I checked the file and saw it there also:
josh@josh-UX490UA:/usr/share/openmpi$ sudo vim mpifort-wrapper-data.txt
# There can be multiple blocks of configuration data, chosen by
# compiler flags (using the compiler_args key to chose which block
# should be activated. This can be useful for multilib builds. See the
# multilib page at:
#https://github.com/open-mpi/ompi/wiki/compilerwrapper3264
# for more information.
project=Open MPI
project_short=OMPI
version=2.1.1
language=Fortran
compiler_env=FC
compiler_flags_env=FCFLAGS
compiler=gfortran
preprocessor_flags=
compiler_flags=-pthread -I${libdir}
linker_flags=*-L/usr//lib*
# Note that per https://svn.open-mpi.org/trac/ompi/ticket/3422, we
# intentionally only link in the MPI libraries (ORTE, OPAL, etc. are
# pulled in implicitly) because we intend MPI applications to only use
# the MPI API.
libs=-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
libs_static=-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
-lopen-rte -lopen-pal -lhwloc -ldl -lutil -lm
dyn_lib_file=libmpi.so
static_lib_file=libmpi.a
required_file=
includedir=${includedir}
libdir=${libdir}
I'm guessing this is unintentional, but wanted to check since its in the
distro before I edit it on my end.
Thanks,
Josh
--
Joshua Wall
Doctoral Candidate
Department of Physics
Drexel University
3141 Chestnut Street
Philadelphia, PA 19104
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users
Re: [OMPI users] Typo in mpi-fort-wrapper-data.txt?
Joshua -
Can you describe how you installed Open MPI?
I think the exact command you used to configure Open MPI will be important.
Sent from my phone. No type good.
On Jan 30, 2018, at 10:30 AM, Joshua Wall
mailto:joshua.e.w...@gmail.com>> wrote:
Hello users,
I was installing a new OS this week (Xubuntu 17.10 to be exact) and pulled
down the latest OMPI from apt on the machine. While trying to compile a MPI
Fortran program I noticed the following:
josh@josh-UX490UA:/usr/share/openmpi$ mpifort --showme
gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread
-I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr//lib
-L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr
-lmpi_mpifh -lmpi
Noticing the double //, I checked the file and saw it there also:
josh@josh-UX490UA:/usr/share/openmpi$ sudo vim mpifort-wrapper-data.txt
# There can be multiple blocks of configuration data, chosen by
# compiler flags (using the compiler_args key to chose which block
# should be activated. This can be useful for multilib builds. See the
# multilib page at:
#https://github.com/open-mpi/ompi/wiki/compilerwrapper3264
# for more information.
project=Open MPI
project_short=OMPI
version=2.1.1
language=Fortran
compiler_env=FC
compiler_flags_env=FCFLAGS
compiler=gfortran
preprocessor_flags=
compiler_flags=-pthread -I${libdir}
linker_flags=-L/usr//lib
# Note that per https://svn.open-mpi.org/trac/ompi/ticket/3422, we
# intentionally only link in the MPI libraries (ORTE, OPAL, etc. are
# pulled in implicitly) because we intend MPI applications to only use
# the MPI API.
libs=-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
libs_static=-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
-lopen-rte -lopen-pal -lhwloc -ldl -lutil -lm
dyn_lib_file=libmpi.so
static_lib_file=libmpi.a
required_file=
includedir=${includedir}
libdir=${libdir}
I'm guessing this is unintentional, but wanted to check since its in the distro
before I edit it on my end.
Thanks,
Josh
--
Joshua Wall
Doctoral Candidate
Department of Physics
Drexel University
3141 Chestnut Street
Philadelphia, PA 19104
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users
Re: [OMPI users] Typo in mpi-fort-wrapper-data.txt?
Most Linux distros ignore repetition of forward slash. Sometimes used as excuse
for sloppiness.
Sent via the Samsung Galaxy S8 Active, an AT&T 4G LTE smartphone
Original message From: Joshua Wall
Date: 1/30/18 10:28 AM (GMT-05:00) To: users@lists.open-mpi.org Subject:
[OMPI users] Typo in mpi-fort-wrapper-data.txt?
Hello users,
I was installing a new OS this week (Xubuntu 17.10 to be exact) and pulled
down the latest OMPI from apt on the machine. While trying to compile a MPI
Fortran program I noticed the following:
josh@josh-UX490UA:/usr/share/openmpi$ mpifort --showme
gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread
-I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr//lib
-L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr
-lmpi_mpifh -lmpi
Noticing the double //, I checked the file and saw it there also:
josh@josh-UX490UA:/usr/share/openmpi$ sudo vim mpifort-wrapper-data.txt
# There can be multiple blocks of configuration data, chosen by
# compiler flags (using the compiler_args key to chose which block
# should be activated. This can be useful for multilib builds. See the
# multilib page at:
# https://github.com/open-mpi/ompi/wiki/compilerwrapper3264
# for more information.
project=Open MPI
project_short=OMPI
version=2.1.1
language=Fortran
compiler_env=FC
compiler_flags_env=FCFLAGS
compiler=gfortran
preprocessor_flags=
compiler_flags=-pthread -I${libdir}
linker_flags=-L/usr//lib
# Note that per https://svn.open-mpi.org/trac/ompi/ticket/3422, we
# intentionally only link in the MPI libraries (ORTE, OPAL, etc. are
# pulled in implicitly) because we intend MPI applications to only use
# the MPI API.
libs=-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
libs_static=-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
-lopen-rte -lopen-pal -lhwloc -ldl -lutil -lm
dyn_lib_file=libmpi.so
static_lib_file=libmpi.a
required_file=
includedir=${includedir}
libdir=${libdir}
I'm guessing this is unintentional, but wanted to check since its in the distro
before I edit it on my end.
Thanks,
Josh
--
Joshua Wall
Doctoral Candidate
Department of Physics
Drexel University
3141 Chestnut Street
Philadelphia, PA 19104
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users
Re: [OMPI users] OMPI users] OMPI users] Installation of openmpi-1.10.7 fails
This is just an update on how things turned out with openmpi-3.0.x. I compiled both EPW and openmpi with intel14. In the past, EPW crashed for both intel16 and 17. However, with intel14 and openmpi/1.8.8 , I have been getting results consistently. The nscf.in worked with the -i argument. However, when I ran EPW with intel14/openmpi-3.0.x, I get the following error: mca_base_component_repository_open: unable to open mca_io_romio314: libgpfs.so: cannot open shared object file: No such file or directory (ignored) What is interesting is that this error occurs in the middle of a long loop. Since the loop repeats over different coordinates, the error may not be coming from the gpfs library. Cheers, Vahid On Jan 23, 2018, at 9:52 AM, Gilles Gouaillardet mailto:gilles.gouaillar...@gmail.com>> wrote: Fair enough, To be on the safe side, I encourage you to use the latest Intel compilers Cheers, Gilles Vahid Askarpour mailto:vh261...@dal.ca>> wrote: Gilles, I have not tried compiling the latest openmpi with GCC. I am waiting to see how the intel version turns out before attempting GCC. Cheers, Vahid On Jan 23, 2018, at 9:33 AM, Gilles Gouaillardet mailto:gilles.gouaillar...@gmail.com>> wrote: Vahid, There used to be a bug in the IOF part, but I am pretty sure this has already been fixed. Does the issue also occur with GNU compilers ? There used to be an issue with Intel Fortran runtime (short read/write were silently ignored) and that was also fixed some time ago. Cheers, Gilles Vahid Askarpour mailto:vh261...@dal.ca>> wrote: This would work for Quantum Espresso input. I am waiting to see what happens to EPW. I don’t think EPW accepts the -i argument. I will report back once the EPW job is done. Cheers, Vahid On Jan 22, 2018, at 6:05 PM, Edgar Gabriel mailto:egabr...@central.uh.edu>> wrote: well, my final comment on this topic, as somebody suggested earlier in this email chain, if you provide the input with the -i argument instead of piping from standard input, things seem to work as far as I can see (disclaimer: I do not know what the final outcome should be. I just see that the application does not complain about the 'end of file while reading crystal k points'). So maybe that is the most simple solution. Thanks Edgar On 1/22/2018 1:17 PM, Edgar Gabriel wrote: after some further investigation, I am fairly confident that this is not an MPI I/O problem. The input file input_tmp.in is generated in this sequence of instructions (which is in Modules/open_close_input_file.f90) --- IF ( TRIM(input_file_) /= ' ' ) THEn ! ! copy file to be opened into input_file ! input_file = input_file_ ! ELSE ! ! if no file specified then copy from standard input ! input_file="input_tmp.in" OPEN(UNIT = stdtmp, FILE=trim(input_file), FORM='formatted', & STATUS='unknown', IOSTAT = ierr ) IF ( ierr > 0 ) GO TO 30 ! dummy=' ' WRITE(stdout, '(5x,a)') "Waiting for input..." DO WHILE ( TRIM(dummy) .NE. "MAGICALME" ) READ (stdin,fmt='(A512)',END=20) dummy WRITE (stdtmp,'(A)') trim(dummy) END DO ! 20 CLOSE ( UNIT=stdtmp, STATUS='keep' ) Basically, if no input file has been provided, the input file is generated by reading from standard input. Since the application is being launched e.g. with mpirun -np 64 ../bin/pw.x -npool 64 nscf.out the data comes from nscf.in. I simply do not know enough about IO forwarding do be able to tell why we do not see the entire file, but one interesting detail is that if I run it in the debugger, the input_tmp.in is created correctly. However, if I run it using mpirun as shown above, the file is cropped incorrectly, which leads to the error message mentioned in this email chain. Anyway, I would probably need some help here from somebody who knows the runtime better than me on what could go wrong at this point. Thanks Edgar On 1/19/2018 1:22 PM, Vahid Askarpour wrote: Concerning the following error from pw_readschemafile : error # 1 xml data file not found The nscf run uses files generated by the scf.in run. So I first run scf.in and when it finishes, I run nscf.in. If you have done this and still get the above error, then this could be another bug. It does not happen for me with intel14/openmpi-1.8.8. Thanks for the update, Vahid On Jan 19, 2018, at 3:08 PM, Edgar Gabriel mailto:egabr...@central.uh.edu>> wrote: ok, here is what found out so far, will have to stop for now however for today: 1. I can in fact reproduce your bug on my systems. 2. I can confirm that the problem occurs both with romio314 and ompio. I *think* the issue is that the input_tmp.in file is incomplete. In both cases (ompio and romio) the end of the file looks as follows (and its exactly the same for both libraries): gabriel@crill-002:/tmp/gabriel/qe-6.2.1/QE_input_files
Re: [OMPI users] Typo in mpi-fort-wrapper-data.txt?
On Jan 30, 2018, at 11:51 AM, n8tm via users wrote: > > Most Linux distros ignore repetition of forward slash. Sometimes used as > excuse for sloppiness. That path is generated during configure. Meaning: some CLI arg to configure was (probably) given as "--with-SOMETHING=/usr/". Open MPI's configure usually strips out "/usr" prefixes, because it's generally not a good idea to do -I/usr/include, -L/usr/lib or -L/usr/lib64 in the wrappers -- it creates confusion and/or ambiguity in conjunction with default compiler/linker search paths. However, Open MPI's configure script does not strip off any trailing "/" characters when processing directory names that are provided by the user. Hence, my *guess* is that --with-SOMETHING=/usr/ was provided (instead of --with-SOMETHING=/usr, or even --with-SOMETHING). And "/usr/" didn't compare exactly to "/usr", so configure let it through. So yes, perhaps we should catch that unusual case in the configure script, and a) strip all trailing /'s, and b) therefore detect that the path was /usr, and c) therefore filter it out. But I'd hardly call the present behavior "sloppy". -- Jeff Squyres jsquy...@cisco.com ___ users mailing list users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/users
Re: [OMPI users] OMPI users] OMPI users] Installation of openmpi-1.10.7 fails
Did you install one version of Open MPI over another version? https://www.open-mpi.org/faq/?category=building#install-overwrite > On Jan 30, 2018, at 2:09 PM, Vahid Askarpour wrote: > > This is just an update on how things turned out with openmpi-3.0.x. > > I compiled both EPW and openmpi with intel14. In the past, EPW crashed for > both intel16 and 17. However, with intel14 and openmpi/1.8.8 , I have been > getting results consistently. > > The nscf.in worked with the -i argument. However, when I ran EPW with > intel14/openmpi-3.0.x, I get the following error: > > mca_base_component_repository_open: unable to open mca_io_romio314: > libgpfs.so: cannot open shared object file: No such file or directory > (ignored) > > What is interesting is that this error occurs in the middle of a long loop. > Since the loop repeats over different coordinates, the error may not be > coming from the gpfs library. > > Cheers, > > Vahid > >> On Jan 23, 2018, at 9:52 AM, Gilles Gouaillardet >> wrote: >> >> Fair enough, >> >> To be on the safe side, I encourage you to use the latest Intel compilers >> >> Cheers, >> >> Gilles >> >> Vahid Askarpour wrote: >> Gilles, >> >> I have not tried compiling the latest openmpi with GCC. I am waiting to see >> how the intel version turns out before attempting GCC. >> >> Cheers, >> >> Vahid >> >>> On Jan 23, 2018, at 9:33 AM, Gilles Gouaillardet >>> wrote: >>> >>> Vahid, >>> >>> There used to be a bug in the IOF part, but I am pretty sure this has >>> already been fixed. >>> >>> Does the issue also occur with GNU compilers ? >>> There used to be an issue with Intel Fortran runtime (short read/write were >>> silently ignored) and that was also fixed some time ago. >>> >>> Cheers, >>> >>> Gilles >>> >>> Vahid Askarpour wrote: >>> This would work for Quantum Espresso input. I am waiting to see what >>> happens to EPW. I don’t think EPW accepts the -i argument. I will report >>> back once the EPW job is done. >>> >>> Cheers, >>> >>> Vahid >>> On Jan 22, 2018, at 6:05 PM, Edgar Gabriel wrote: well, my final comment on this topic, as somebody suggested earlier in this email chain, if you provide the input with the -i argument instead of piping from standard input, things seem to work as far as I can see (disclaimer: I do not know what the final outcome should be. I just see that the application does not complain about the 'end of file while reading crystal k points'). So maybe that is the most simple solution. Thanks Edgar On 1/22/2018 1:17 PM, Edgar Gabriel wrote: > after some further investigation, I am fairly confident that this is not > an MPI I/O problem. > The input file input_tmp.in is generated in this sequence of instructions > (which is in Modules/open_close_input_file.f90) > --- > IF ( TRIM(input_file_) /= ' ' ) THEn > ! > ! copy file to be opened into input_file > ! > input_file = input_file_ > ! > ELSE > ! > ! if no file specified then copy from standard input > ! > input_file="input_tmp.in" > OPEN(UNIT = stdtmp, FILE=trim(input_file), FORM='formatted', & > STATUS='unknown', IOSTAT = ierr ) > IF ( ierr > 0 ) GO TO 30 > ! > dummy=' ' > WRITE(stdout, '(5x,a)') "Waiting for input..." > DO WHILE ( TRIM(dummy) .NE. "MAGICALME" ) > READ (stdin,fmt='(A512)',END=20) dummy > WRITE (stdtmp,'(A)') trim(dummy) > END DO > ! > 20 CLOSE ( UNIT=stdtmp, STATUS='keep' ) > > > > Basically, if no input file has been provided, the input file is > generated by reading from standard input. Since the application is being > launched e.g. with > mpirun -np 64 ../bin/pw.x -npool 64 nscf.out > > the data comes from nscf.in. I simply do not know enough about IO > forwarding do be able to tell why we do not see the entire file, but one > interesting detail is that if I run it in the debugger, the input_tmp.in > is created correctly. However, if I run it using mpirun as shown above, > the file is cropped incorrectly, which leads to the error message > mentioned in this email chain. > Anyway, I would probably need some help here from somebody who knows the > runtime better than me on what could go wrong at this point. > Thanks > > Edgar > > > > On 1/19/2018 1:22 PM, Vahid Askarpour wrote: >> Concerning the following error >> >> from pw_readschemafile : error # 1 >> xml data file not found >> >> The nscf run uses files generated by the scf.in run. So I first run >> scf.in and when it finishes, I run nscf.in. If you have done this and >> still get the above error, then this could be another bug. It d
Re: [OMPI users] OMPI users] OMPI users] Installation of openmpi-1.10.7 fails
No, I installed this version of openmpi once and with intel14. Vahid > On Jan 30, 2018, at 4:41 PM, Jeff Squyres (jsquyres) > wrote: > > Did you install one version of Open MPI over another version? > >https://www.open-mpi.org/faq/?category=building#install-overwrite > > >> On Jan 30, 2018, at 2:09 PM, Vahid Askarpour wrote: >> >> This is just an update on how things turned out with openmpi-3.0.x. >> >> I compiled both EPW and openmpi with intel14. In the past, EPW crashed for >> both intel16 and 17. However, with intel14 and openmpi/1.8.8 , I have been >> getting results consistently. >> >> The nscf.in worked with the -i argument. However, when I ran EPW with >> intel14/openmpi-3.0.x, I get the following error: >> >> mca_base_component_repository_open: unable to open mca_io_romio314: >> libgpfs.so: cannot open shared object file: No such file or directory >> (ignored) >> >> What is interesting is that this error occurs in the middle of a long loop. >> Since the loop repeats over different coordinates, the error may not be >> coming from the gpfs library. >> >> Cheers, >> >> Vahid >> >>> On Jan 23, 2018, at 9:52 AM, Gilles Gouaillardet >>> wrote: >>> >>> Fair enough, >>> >>> To be on the safe side, I encourage you to use the latest Intel compilers >>> >>> Cheers, >>> >>> Gilles >>> >>> Vahid Askarpour wrote: >>> Gilles, >>> >>> I have not tried compiling the latest openmpi with GCC. I am waiting to see >>> how the intel version turns out before attempting GCC. >>> >>> Cheers, >>> >>> Vahid >>> On Jan 23, 2018, at 9:33 AM, Gilles Gouaillardet wrote: Vahid, There used to be a bug in the IOF part, but I am pretty sure this has already been fixed. Does the issue also occur with GNU compilers ? There used to be an issue with Intel Fortran runtime (short read/write were silently ignored) and that was also fixed some time ago. Cheers, Gilles Vahid Askarpour wrote: This would work for Quantum Espresso input. I am waiting to see what happens to EPW. I don’t think EPW accepts the -i argument. I will report back once the EPW job is done. Cheers, Vahid > On Jan 22, 2018, at 6:05 PM, Edgar Gabriel > wrote: > > well, my final comment on this topic, as somebody suggested earlier in > this email chain, if you provide the input with the -i argument instead > of piping from standard input, things seem to work as far as I can see > (disclaimer: I do not know what the final outcome should be. I just see > that the application does not complain about the 'end of file while > reading crystal k points'). So maybe that is the most simple solution. > > Thanks > Edgar > > On 1/22/2018 1:17 PM, Edgar Gabriel wrote: >> after some further investigation, I am fairly confident that this is not >> an MPI I/O problem. >> The input file input_tmp.in is generated in this sequence of >> instructions (which is in Modules/open_close_input_file.f90) >> --- >> IF ( TRIM(input_file_) /= ' ' ) THEn >> ! >> ! copy file to be opened into input_file >> ! >> input_file = input_file_ >> ! >> ELSE >> ! >> ! if no file specified then copy from standard input >> ! >> input_file="input_tmp.in" >> OPEN(UNIT = stdtmp, FILE=trim(input_file), FORM='formatted', & >> STATUS='unknown', IOSTAT = ierr ) >> IF ( ierr > 0 ) GO TO 30 >> ! >> dummy=' ' >> WRITE(stdout, '(5x,a)') "Waiting for input..." >> DO WHILE ( TRIM(dummy) .NE. "MAGICALME" ) >>READ (stdin,fmt='(A512)',END=20) dummy >>WRITE (stdtmp,'(A)') trim(dummy) >> END DO >> ! >> 20 CLOSE ( UNIT=stdtmp, STATUS='keep' ) >> >> >> >> Basically, if no input file has been provided, the input file is >> generated by reading from standard input. Since the application is being >> launched e.g. with >> mpirun -np 64 ../bin/pw.x -npool 64 nscf.out >> >> the data comes from nscf.in. I simply do not know enough about IO >> forwarding do be able to tell why we do not see the entire file, but one >> interesting detail is that if I run it in the debugger, the input_tmp.in >> is created correctly. However, if I run it using mpirun as shown above, >> the file is cropped incorrectly, which leads to the error message >> mentioned in this email chain. >> Anyway, I would probably need some help here from somebody who knows the >> runtime better than me on what could go wrong at this point. >> Thanks >> >> Edgar >> >> >> >> On 1/19/2018 1:22 PM, Vahid Askarpour wrote: >>> Concerning the following error >>> >>> from pw_readschemafile : error # 1
Re: [OMPI users] OMPI users] OMPI users] Installation of openmpi-1.10.7 fails
Ah, my mistake -- I read the warning message too quickly: > mca_base_component_repository_open: unable to open mca_io_romio314: > libgpfs.so: cannot open shared object file: No such file or directory > (ignored) This simply means that the mca_io_romio314 plugin failed to load because it was unable to find the libgpfs.so library. You might want to make sure that your shell startup files set LD_LIBRARY_PATH values properly, even for non-interactive logins. However, the whole point of this thread is to not use the ROMIO plugin, but rather use the OMPIO plugin. So the fact that the ROMIO plugin failed to load because it couldn't find a dependent library is probably not a tragedy -- Open MPI just ignores that plugin and moves on. The reason you get it a while after startup is because that is likely the first time the application tries to use MPI-IO (Open MPI lazily loads MPI-IO support the first time it is used). > On Jan 30, 2018, at 5:20 PM, Vahid Askarpour wrote: > > No, I installed this version of openmpi once and with intel14. > > Vahid > >> On Jan 30, 2018, at 4:41 PM, Jeff Squyres (jsquyres) >> wrote: >> >> Did you install one version of Open MPI over another version? >> >> https://www.open-mpi.org/faq/?category=building#install-overwrite >> >> >>> On Jan 30, 2018, at 2:09 PM, Vahid Askarpour wrote: >>> >>> This is just an update on how things turned out with openmpi-3.0.x. >>> >>> I compiled both EPW and openmpi with intel14. In the past, EPW crashed for >>> both intel16 and 17. However, with intel14 and openmpi/1.8.8 , I have been >>> getting results consistently. >>> >>> The nscf.in worked with the -i argument. However, when I ran EPW with >>> intel14/openmpi-3.0.x, I get the following error: >>> >>> mca_base_component_repository_open: unable to open mca_io_romio314: >>> libgpfs.so: cannot open shared object file: No such file or directory >>> (ignored) >>> >>> What is interesting is that this error occurs in the middle of a long loop. >>> Since the loop repeats over different coordinates, the error may not be >>> coming from the gpfs library. >>> >>> Cheers, >>> >>> Vahid >>> On Jan 23, 2018, at 9:52 AM, Gilles Gouaillardet wrote: Fair enough, To be on the safe side, I encourage you to use the latest Intel compilers Cheers, Gilles Vahid Askarpour wrote: Gilles, I have not tried compiling the latest openmpi with GCC. I am waiting to see how the intel version turns out before attempting GCC. Cheers, Vahid > On Jan 23, 2018, at 9:33 AM, Gilles Gouaillardet > wrote: > > Vahid, > > There used to be a bug in the IOF part, but I am pretty sure this has > already been fixed. > > Does the issue also occur with GNU compilers ? > There used to be an issue with Intel Fortran runtime (short read/write > were silently ignored) and that was also fixed some time ago. > > Cheers, > > Gilles > > Vahid Askarpour wrote: > This would work for Quantum Espresso input. I am waiting to see what > happens to EPW. I don’t think EPW accepts the -i argument. I will report > back once the EPW job is done. > > Cheers, > > Vahid > >> On Jan 22, 2018, at 6:05 PM, Edgar Gabriel >> wrote: >> >> well, my final comment on this topic, as somebody suggested earlier in >> this email chain, if you provide the input with the -i argument instead >> of piping from standard input, things seem to work as far as I can see >> (disclaimer: I do not know what the final outcome should be. I just see >> that the application does not complain about the 'end of file while >> reading crystal k points'). So maybe that is the most simple solution. >> >> Thanks >> Edgar >> >> On 1/22/2018 1:17 PM, Edgar Gabriel wrote: >>> after some further investigation, I am fairly confident that this is >>> not an MPI I/O problem. >>> The input file input_tmp.in is generated in this sequence of >>> instructions (which is in Modules/open_close_input_file.f90) >>> --- >>> IF ( TRIM(input_file_) /= ' ' ) THEn >>>! >>>! copy file to be opened into input_file >>>! >>>input_file = input_file_ >>>! >>> ELSE >>>! >>>! if no file specified then copy from standard input >>>! >>>input_file="input_tmp.in" >>>OPEN(UNIT = stdtmp, FILE=trim(input_file), FORM='formatted', & >>> STATUS='unknown', IOSTAT = ierr ) >>>IF ( ierr > 0 ) GO TO 30 >>>! >>>dummy=' ' >>>WRITE(stdout, '(5x,a)') "Waiting for input..." >>>DO WHILE ( TRIM(dummy) .NE. "MAGICALME" ) >>> READ (stdin,fmt='(A512)',END=20) dummy >>> WRITE (stdtmp,'(A)') trim(dummy) >>>END DO >>>! >>>
