[CP2K:138] Re: dangling pointer on FORCE

Teodoro Laino teodor... at gmail.com
Thu Jun 21 13:23:24 UTC 2007


If you have access to the intel mkl cluster libraries  I  would go  
for trying them (it's definitely worth a try).

teo
On 21 Jun 2007, at 15:16, Nichols A. Romero wrote:

> I was running in parallel. I will try to find out what optimization  
> were used with SCALAPACK and write back. When I compiled SCALAPACK  
> I usually use conservative optimization, the sysadmin may have used  
> optimizations galore. Will find out.
>
> On 6/21/07, Teodoro Laino <teodor... at gmail.com> wrote:
> Ciao Nichols,
>
> I cannot reproduce your bug.. I can run your original input file  
> (normal BASIS_SET file) until 1209 steps and more.. (I just stopped  
> because everything is normal)..
>
>
> ********************************************************************** 
> *********
> ENSEMBLE TYPE = nvt
> STEP NUMBER = 1209
> TIME [FS] = 1209.000000
> CONSERVED QNTY = -0.213580139537E+04
>
> INSTANTANEOUS AVERAGES
> CPU [S] = 32.28 35.71
> {E-E0}/{k_b*N_at} = 0.195657945547E+01 0.227114913953E+01
> POTENTIAL ENERGY[hartree] = - 0.213584840153E+04 -0.213585075326E+04
> KINETIC ENERGY[hartree] = 0.331089284264E+00 0.299157432586E+00
> TEMPERATURE[K] = 324.185 292.919
> PRESSURE[bar] = 0.331645507280E+06 0.329397226341E+06
> ********************************************************************** 
> *********
>
>
> I really start thinking that the problem is in thelibraries you're  
> using..
> Are you using the intel mkl cluster? or home compiled scalapack?
>
> Teo
> p.s.: in case you need I can send you the output file produced  
> sofar (compressed is still pretty large.. 25 MB)..
>
> On 20 Jun 2007, at 17:17, Nichols A. Romero wrote:
>
>> Teodoro,
>>
>> Sorry it took me so long to test.
>>
>> I tried the geometry from step number 459 and 457-458, but much  
>> too my surprise. I was not able to reproduce the error.
>>
>> As you suggested, I tried BASIS_MOLOPT. Unfortunately, the same  
>> identical error eventually occured. This time at step number 1155.  
>> Once again I tried the input geometry test, but the error could  
>> not be reproduced.
>>
>> Any other ideas? At the moment, it only seems like it can by doing  
>> MD from the starting geometry.
>>
>> On 6/4/07, Teodoro Laino < teodor... at gmail.com> wrote:
>> Thanks Nichols!
>> Can you reproduce the same error inputing the geometry  
>> corresponding to the step number 459?
>> In this case can you post the input file corresponding to this  
>> geometry?
>>
>> p.s.: very probably is a problem due to your basis set.. you may  
>> want to try the new one available in
>> cp2k/tests/QS/BASIS_MOLOPT
>>
>>
>>
>> On 4 Jun 2007, at 17:28, Nichols A. Romero wrote:
>>
>>> Teodoro,
>>>
>>> Ran a couple of tests. CP2K (date:5/31/07) when compiled with all  
>>> the checks is failing in exactly the same manner as in the  
>>> gzipped output file that I sent you earlier. (So I will not  
>>> bother resending the same output file.)
>>>
>>> The _unchecked_ version also failed in exactly the same manner as  
>>> in an earlier version of CP2K (5/8/07) which I reported in my  
>>> initial e-mail. Now, I had run this input file with even earlier  
>>> version of CP2K and it now longer seems to be clear what is  
>>> causing the crash. It frequently seemed that it occured at  
>>> different points with the same error message. This was a libgm  
>>> deregister memory error. I apologize for neglecting to mention  
>>> this in my initial e-mail.
>>>
>>> Between the unchecked 5/8/07 and 5/31/07 version, there is now  
>>> some consistency. It seems to have something to do with obtaining  
>>> the eigenvalues of the unoccupied subspace (and probably nothing  
>>> to do with memory or dangling pointers). For those two versions,  
>>> the errors occurs on NVT step number 459:
>>>
>>> Lowest Eigenvalues of the unoccupied subspace spin 1
>>> -----------------------------------------------------
>>>
>>> ===== Routine Calling Stack =====
>>>
>>> 9 cp_fm_cholesky_decompose
>>> 8 make_basis_sv
>>> 7 ot_eigensolver
>>> 6 scf_post_calculation
>>> 5 qs_energies
>>> 4 qs_forces
>>> 3 velocity_verlet
>>> 2 qs_mol_dyn2
>>> 1 CP2K
>>> ******************************************************************** 
>>> *********
>>> *** 03:06:26 ERRORL2 in cp_fm_cholesky:cp_fm_cholesky_decompose  
>>> err=-300 ***
>>> *** condition FAILED at line 116 ***
>>> ******************************************************************** 
>>> *********
>>>
>>> ===== Routine Calling Stack =====
>>>
>>> 9 cp_fm_cholesky_decompose
>>> 8 make_basis_sv
>>> 7 ot_eigensolver
>>> 6 scf_post_calculation
>>> 5 qs_energies
>>> 4 qs_forces
>>> 3 velocity_verlet
>>> 2 qs_mol_dyn2
>>> 1 CP2K
>>>
>>>
>>> ******************************************************************** 
>>> *****
>>> *** ERROR in cp_fm_cholesky:cp_fm_cholesky_decompose processor 0 ***
>>> ******************************************************************** 
>>> *****
>>>
>>> *** condition FAILED at line 116 ***
>>>
>>>
>>> ===== Routine Calling Stack =====
>>>
>>> 9 cp_fm_cholesky_decompose
>>> 8 make_basis_sv
>>> 7 ot_eigensolver
>>> 6 scf_post_calculation
>>> 5 qs_energies
>>> 4 qs_forces
>>> 3 velocity_verlet
>>> 2 qs_mol_dyn2
>>> 1 CP2K
>>>
>>> CP2K| Stopped by process number 0
>>> CP2K| Abnormal program termination
>>>
>>> [0] MPI Abort by user Aborting program !
>>> [0] Aborting program!
>>>
>>> CP2K| Stopped by process number 1
>>> CP2K| Abnormal program termination
>>>
>>> forrtl: error (76): IOT trap signal
>>>
>>> CP2K| Stopped by process number 13
>>> CP2K| Abnormal program termination
>>>
>>>
>>>
>>> On 5/30/07, Teodoro Laino < teodor... at gmail.com> wrote:
>>> The problem you're experiencing is very probably popping out  
>>> because of a bad instruction dirtying the memory somewhere..
>>> I was able to track a possible problem not connected with the  
>>> force pointer (though related with the warnings that ifort was
>>> printing out in your output file).. after this fix (committed now  
>>> in CVS) I can run your input file both with NAG and with g95:
>>>
>>>
>>> Number of electrons: 1080
>>> Number of occupied orbitals: 540
>>> Number of orbital functions: 2808
>>>
>>> Number of independent orbital functions: 2808
>>>
>>> Extrapolation method: initial_guess
>>>
>>>
>>> SCF WAVEFUNCTION OPTIMIZATION
>>>
>>> Step Update method Time Convergence Total energy
>>> -------------------------------------------------------------------- 
>>> ---------
>>> ----------------------------------- OT  
>>> --------------------------------------
>>> Allowing for rotations: F
>>> minimizer : DIIS : direct inversion
>>> in the iterative subspace
>>> using : - 7 diis vectors
>>> - safer DIIS on
>>> preconditioner : FULL_KINETIC : cholesky inversion of T + eS
>>> stepsize : 0.15000000
>>> energy_gap : 0.20000000
>>> eps_taylor : 0.10000E-15
>>> max_taylor : 4
>>> ----------------------------------- OT  
>>> --------------------------------------
>>> 1 OT DIIS 0.15E+00 906.31 0.0104124696 -2034.0437223707
>>> 2 OT DIIS 0.15E+00 753.14 0.0079131310 -2055.1464826211
>>> 3 OT DIIS 0.15E+00 746.54 0.0063728300 - 2076.3119871662
>>> 4 OT DIIS 0.15E+00 779.70 0.0050762793 -2086.0129069723
>>> ...
>>>
>>> Can you try to update cp2k and recompile it?
>>> In case it should fail again can you try with the latest intel  
>>> fortan compiler?
>>> Let us know
>>>
>>> Teo
>>>
>>> On 30 May 2007, at 18:40, Nichols A. Romero wrote:
>>>
>>>> Here it is. I am using
>>>> Intel(R) Fortran Compiler for Intel(R) EM64T-based applications,  
>>>> Version 9.1 Build 20070109 Package ID: l_fc_c_9.1.041
>>>>
>>>> with the unchecked version the crashes are random. With the  
>>>> checked version the CP2K will fail immediately. I attached a  
>>>> gzipped version of the output.
>>>>
>>>> Let me know if there is any additional information that you need.
>>>>
>>>>
>>>> On 5/30/07, Teodoro Laino < teodor... at gmail.com > wrote:
>>>> Please post your input file..
>>>>
>>>> teo
>>>> On 30 May 2007, at 17:48, Nichols A. Romero wrote:
>>>>
>>>>> which I can post upon request.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Nichols A. Romero, Ph.D.
>>>> 1613 Denise Dr. Apt. D
>>>> Forest Hill, MD 21050
>>>> 443-567-8328 (C)
>>>> 410-306-0709 (O)
>>>>
>>>>
>>>>
>>>> <cubicGauche.inp.300>
>>>> <cubicGauche.out.gz>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Nichols A. Romero, Ph.D.
>>> 1613 Denise Dr. Apt. D
>>> Forest Hill, MD 21050
>>> 443-567-8328 (C)
>>> 410-306-0709 (O)
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> -- 
>> Nichols A. Romero, Ph.D.
>> 1613 Denise Dr. Apt. D
>> Forest Hill, MD 21050
>> 443-567-8328 (C)
>> 410-306-0709 (O)
>>
>>
>>
>
>
>
>
>
>
> -- 
> Nichols A. Romero, Ph.D.
> 1613 Denise Dr. Apt. D
> Forest Hill, MD 21050
> 443-567-8328 (C)
> 410-306-0709 (O)
>
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20070621/8a1babb2/attachment.htm>


More information about the CP2K-user mailing list