[Pw_forum] Electron-phonon calculations in Examples 02 and 07.
akohlmey at cmm.chem.upenn.edu
Mon Aug 4 22:52:52 CEST 2008
On Mon, 4 Aug 2008, Amos Leffler wrote:
AL> Dear Stefano,
AL> In Example02 I compared the reference file to the results file outputs as below:
AL> reference results
AL> si.phX.out 23065 16206
AL> si.phXsingle.out 25830 22505
what is this? the size of the files? this still doesn't say anything
about _what_ went wrong. wouldn't it make much more sense to show
_where_ they are different?
you say you are running a serial compile using g95 on
an x86_64 platform, right?
so i ran a check on my machine (x86_64, intel xeon 5150 dual core,
fedora core 6). using the QE-4.0.1 source from www.pwscf.org and the
last g95 release version (0.91!, Feb 27 2008).
compiled using the defaults as found by FC=g95 F90=g95 ./configure
which picks up intel MKL (10.0.1.014 on my machine), and the result
is that i can _not_ reproduce your crash report.
example02 runs just fine and so does example07.
do you by any chance use a g95 compiler with 64bit integers?
or a non-release version? the next option would be a problem
in BLAS/LAPACK from MKL (since you have a different version than
i have, but that is rather unlikely).
can you run all the checks in the "tests" subdirectory successfully?
please also try to disable all native language support or locale
settings via exporting LC_ALL=C
beyond that, you have to provide more details about the platform
you are running on and the components that you are using and what
else _exactly_ you are doing. right now, it looks as if something
you use or how you use it is broken but not the QE code itself
(at least not for those specific examples).
AL> At the end of the results file in each case was the message "from
AL> broyden file factorization error". Using grep in the PH directory I
AL> found matches for broyden noted in the dynmat.x, matdyn.x, ph.x, and
AL> q2r.x binary files.
this is not the problem, but the code leading up to it may give a hint.
AL> All of the remaining listed files were either exactly or
AL> close to the same length. This agrees with the error
AL> message. The problem is that I don't know where the problem
AL> is in the PH directory. Is there any way to debug the
the only way to find this is to run under a debugger and single step
through the code from the last know to work location. as long as nobody
else can reproduce your problem, you are on your own with that...
AL> directory? Nothing is said in the user_guide. I did note in
AL> the phq_readin.f90 file line 154 it is possible to reset
AL> lnscf to true but I am not sure what this will tell me. Your
AL> comments would be appreciated.
please explain what that is supposed to achieve?
how would this specific flag be relate to your problem?
there are a large number of defaults that you can set
differently, but that cannot be the problem.
Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu
Center for Molecular Modeling -- University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
If you make something idiot-proof, the universe creates a better idiot.
More information about the users