Vahid,
i the v1.10 series, the default MPI-IO component was ROMIO based, and
in the v3 series, it is now ompio.
You can force the latest Open MPI to use the ROMIO based component with
mpirun --mca io romio314 ...
That being said, your description (e.g. a hand edited file) suggests
that I/O is not
I will try to reproduce this problem with 3.0.x, but it might take me a
couple of days to get to it.
Since it seemed to have worked with 2.0.x (except for the running out file
handles problem), there is the suspicion that one of the fixes that we
introduced since then is the problem.
What file
On Jan 18, 2018, at 5:53 PM, Vahid Askarpour wrote:
>
> My openmpi3.0.x run (called nscf run) was reading data from a routine Quantum
> Espresso input file edited by hand. The preliminary run (called scf run) was
> done with openmpi3.0.x on a similar input file also edited by hand.
Gotcha.
W
My openmpi3.0.x run (called nscf run) was reading data from a routine Quantum
Espresso input file edited by hand. The preliminary run (called scf run) was
done with openmpi3.0.x on a similar input file also edited by hand.
Vahid
> On Jan 18, 2018, at 6:39 PM, Jeff Squyres (jsquyres)
> wrot
FWIW: If your Open MPI 3.0.x runs are reading data that was written by MPI IO
via Open MPI 1.10.x or 1.8.x runs, that data formats may not be compatible (and
could lead to errors like you're seeing -- premature end of file, etc.).
> On Jan 18, 2018, at 5:34 PM, Vahid Askarpour wrote:
>
> Hi J
Hi Jeff,
I compiled Quantum Espresso/EPW with openmpi-3.0.x. The openmpi was compiled
with intel14.
A preliminary run for EPW using Quantum Espresso crashed with the following
message:
end of file while reading crystal k points
There are 1728 k points in the input file and Quantum Espresso, b
