Settled offline. Just to record the solution.
The compilation is fine but there is a pre-installed pw.x from the package
manager.
When running, this user is pulling /usr/bin/pw.x instead of the newly built
one.
Then the solution is just remove the pre-installed QE in the package
manager.
Maybe take this offline?
Will DeBenedetti
Cornell University
Sent from my iPhone
On Aug 7, 2018, at 22:11, Aziz Fall mailto:af...@umich.edu>>
wrote:
yeah both my mpiifort and mpif90 are from intel. where do I find the
psxevars.sh file
On Tue, Aug 7, 2018 at 9:57 PM, Ye Luo
yeah both my mpiifort and mpif90 are from intel. where do I find the
psxevars.sh file
On Tue, Aug 7, 2018 at 9:57 PM, Ye Luo wrote:
> /usr/lib/libblacsCinit-openmpi.so.1 seems belong to libblacs-openmpi1
> package in ubuntu.
> This indicates you have openmpi and blacs installed from the package
/usr/lib/libblacsCinit-openmpi.so.1 seems belong to libblacs-openmpi1
package in ubuntu.
This indicates you have openmpi and blacs installed from the package
manager.
Are you sure your parallel studio is the cluster edition and you have intel
mpi?
Did you source psxevars.sh form parallel studio?
yeah unfortunately I get the same error again, sorry if this is taking up
your time
On Tue, Aug 7, 2018 at 9:40 PM, Aziz Fall wrote:
> ok thanks I will try it and let you know, hopefully I dont run into any
> issues this time
>
> On Tue, Aug 7, 2018 at 9:37 PM, Ye Luo wrote:
>
>> There was a
ok thanks I will try it and let you know, hopefully I dont run into any
issues this time
On Tue, Aug 7, 2018 at 9:37 PM, Ye Luo wrote:
> There was a typo mpiifort instead of mpif90 in your case.
> ./configure MPIF90=mpiifort CC=icc --with-scalapack=intel
>
>
> ===
> Ye Luo,
yeah so the problem persist even after changing the MPIF90 flag
On Tue, Aug 7, 2018 at 8:55 PM, Aziz Fall wrote:
> I noticed that after I reconfigured and I looked at my make.inc file, my
> MPI_LIBS and LAPACK_LIPS paths that I specified beforehand were erased,
> will this affect the pw.x
There was a typo mpiifort instead of mpif90 in your case.
./configure MPIF90=mpiifort CC=icc --with-scalapack=intel
===
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory
2018-08-07 20:36 GMT-05:00 Ye Luo :
> Why don't you trust the configure? The configure
Why don't you trust the configure? The configure can cover most scenarios.
Most users should rely on the configure instead of modifying the make.inc
by hand.
Linux+OpenMP/IntelMPI+Intel compiler+MKL is very common and the configure
can handle it very well.
I can handle BG/Q or Cray machines
I noticed that after I reconfigured and I looked at my make.inc file, my
MPI_LIBS and LAPACK_LIPS paths that I specified beforehand were erased,
will this affect the pw.x program from running parallely after it finishes
compiling, I am asking now because it will take a while to finish compiling.
ok I'll try that and let you know
On Tue, Aug 7, 2018 at 8:28 PM, Ye Luo wrote:
> Your mpi wrapper mpif90 is using gfortran underneath from the ldd pw.x
> output.
> Could you add MPIF90=mpiifort in your configure line?
> But I'm not sure if this is the real problem.
> Ye
>
>
>
Your mpi wrapper mpif90 is using gfortran underneath from the ldd pw.x
output.
Could you add MPIF90=mpiifort in your configure line?
But I'm not sure if this is the real problem.
Ye
===
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory
2018-08-07 19:24
no I am using the same machine for the build and run, its a workstation
with 32 cores
On Tue, Aug 7, 2018 at 8:22 PM, Ye Luo wrote:
> Did you build the code and run it on different machines? Ye
>
> ===
> Ye Luo, Ph.D.
> Leadership Computing Facility
> Argonne National Laboratory
Did you build the code and run it on different machines? Ye
===
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory
2018-08-07 19:18 GMT-05:00 Aziz Fall :
> ok so regardless of whether I run pw.x with mpirun or not I get the same
> error saying pw.x: symbol
ok so regardless of whether I run pw.x with mpirun or not I get the same
error saying pw.x: symbol lookup error:
/usr/lib/libblacsCinit-openmpi.so.1: undefined symbol: ompi_mpi_comm_world
when I do which mpirun I
get /opt/intel/compilers_and_libraries_2018.3.222/linux/mpi/intel64/bin/mpirun
so
Everything seems good. I'm wondering if it is the problem of your mpirun.
Could you run pw.x directly without mpirun?
If you type "which mpirun" on the machine your are running, is it from the
intel parallel studio folder since you said you are using Intel MPI.
Ye
===
Ye Luo,
yeah so when I type ldd pw.x I get the following
linux-vdso.so.1 => (0x7cb9e000)
libmkl_scalapack_lp64.so =>
/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_scalapack_lp64.so
(0x7ffed730)
libmkl_blacs_intelmpi_lp64.so =>
$ldd pw.x.
What prints out?
It seems that /usr/lib/libblacsCinit-openmpi.so.1 get into your binary at a
certain point. But it should not.
This is the blacs from your OS used by scalapack but it is supposed to be
the Intel one.
Ye
===
Ye Luo, Ph.D.
Leadership Computing Facility
so I changed the options in configure like you suggested with the
--with-scalapack=intel but I still get the same error after re-compiling.
Do you have any further suggestions?
On Tue, Aug 7, 2018 at 6:22 PM, Aziz Fall wrote:
> No, I did not add that configuration as part of configure but I did
No, I did not add that configuration as part of configure but I did change
the make.inc
to have SCALAPACK_LIBS = -L/opt/intel/mkl/lib/intel64 -lmkl_intel_lp64
-lmkl_tbb_thread -lmkl_core -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64
-lpthread -ltbb -lstdc++ -lm -ldl and
MPI_LIBS =
That seems for openmpi.
Did you put --with-scalapack=intel when you run configure?
Ye
===
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory
2018-08-07 16:42 GMT-05:00 Aziz Fall :
> Dear Quantum espresso team,
>
> So recently I have been trying to run the
Dear Quantum espresso team,
So recently I have been trying to run the executable pw.x on the bin
directory. I pass in my input and output file appropriately, and I am using
intel's Parallel studio compiler, with intel MPI. but when I run the
program I get the following error
pw.x: symbol lookup
I am not sure what is the output for that particular line, but the last
part of the output looks as given below.For different instances of the
run, the particular iteration changes, but the boxed error message returned
by phonon.f90 is always the same.We have seen the error in both 6.2.1
hello
what is the output of
addr2line -p -e ph.x 004BE229
and what version of ph are you using ?
On 07/08/2018 17:06, Holzwarth, Natalie wrote:
This segmentation fault issue has also appeared for us in another QE
code. Perhaps it is a totally unrelated problem which we find
Thanks Giuseppe,
I actually want to passivate the bottom of Si and Ge surfaces, as well
as one edge of a 2D nanoribbon (antimonene).
I believe fractional charge H atoms would not be useful for these
kinds of materials. Right?
I was not aware of this strong dopant effect, but I'd be
This segmentation fault issue has also appeared for us in another QE code.
Perhaps it is a totally unrelated problem which we find related to the
openmpi package compiled with intel-3.1.1-2018 and intel-3.1.0-2018. In
our case, compiling with openmpi package compiled with intel-2.1.0-2018
Dear Ben,
I'm afraid it's a problem with MKL-blas ZDOTC, which must
return a complex(dp) result. Very strange, because if you grep
the source code, we have declared it: complex(dp), external::zdtoc
Can you tell us your compiler and MKL version? can you add
DFLAGS+=-Dzdotc=zdotc_wrapper
to
Dear Moon: there is no point in using any smearing in an insulator (but for
plotting the DOS, possibly, but that would be for post-processing purposes
only). In order to compute the DOS, you may want to try the tetrahedron method,
which is implemented in QE, although I do not know exactly how …
Dear Matthieu
I don't know which surface you want to passivate, but remember that H
can also have a strong dopant effect on surfaces (e.g., a large upward
shift of both band edges, which has been measured on C-diamond).
Therefore, I used to passivate the unreconstructed end of III-V slabs
Dear Stefano,
Your advice has helped a lot.
If I can ask you one more question, can I calculate the fermi energy for
semiconductor material if I use DOS calculations using 'gaussian smearing'
instead of 'occupations = fixed'?
Thank you again.
Moon Taehwan, chung-ang university
Hi ???,
The energy zero in any infinite system is arbitrary. In the lack of a surface,
only energy differences matter.
The zero-temperature Fermi energy of an insulator is also arbitrary, though
usually assumed to lie at the middle of the gap.
Hope this helps.
Meanwhile, would you mind
Hello. I am a beginner to try DFT calculations using quantum espresso (GUI
BURAI) for the first time.
An attempt was made to calculate the SCF and pDOS using the CIF-file of the
organic-inorganic hybrid material (eg MAPbI3). I wanted to get the fermi
energy, but I could not find it in the
32 matches
Mail list logo