[CP2K:135] Re: dangling pointer on FORCE
Teodoro Laino
teodor... at gmail.com
Thu Jun 21 13:03:05 UTC 2007
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)
>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20070621/684f2b0b/attachment.htm>
More information about the CP2K-user
mailing list