[Pw_forum] Electron-phonon calculations in Examples 02 and 07.

[Axel Kohlmeyer]

On Mon, 4 Aug 2008, Amos Leffler wrote:

AL> Dear Stefano,

amos,

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.

cheers,
   axel.

-- 
=======================================================================
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.