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.
