Wrong number of electrons in DFTINT

[ajs1]

Occasionally I get this message in a DFT calculation. After a number of iterations in which the number of electrons from numerical integration is correct, the value is suddenly wildly incorrect (e.g. 106.555 instead of 14) and the calculation aborts. Similar calculations differing only in geometry converge successfully. Is this a bug, and is there anything I can do to avoid it? I attach the input and output files.

[taylor]

I have never seen this but I almost never do DFT calculations. However, some things to perhaps try to narrow down whether there is a problem, and in which part of the code it might be.

Have you tried running (integral-direct, so just changing the computational model, not the methodology) SCF? Does it behave OK? Your calculation seems to be some sort of superposition/counterpoise estimate --- do you have the same problem when you treat the full system? Do you have the same problems when you do the "other" counterpoise calculation, with a ghost CO and a "real" ClF?

Also some comments about your build and runtime strategy. You appear to be building with 64-bit integers. While I do not claim this could be the source of your problem, we recommend that people do not use int64 unless they have a specific need for it (which means accessing more than 16GB of memory per MPI task, or doing Cholesky decomposition CC calculations). You have a linear system but you turn off symmetry? And you specify the basis sets inline rather than using the library sets? I repeat, I do not think any of these issues are the cause of problems (although I admit to some concern about 64-bit integers). But I am intrigued that you operate in such a very hands-on fashion rather than letting the program do the work, including exploiting the symmetry of the system.

Best regards
Pete

[bast]

Just to narrow it down I can reproduce the problem with a default 32-bit integer sequential build. In other words I think this is a bug.

[olav]

I could also reproduce it with intel2016, but for gnu the calculation completed. Most definitely a bug, most likely in Dalton but you never know for sure.

[bast]

Interesting, for me it failed with GNU 6.1.1.

[ajs1]

Thanks for the comments. To clarify a few things:

I haven't had this happen to this case or any other when using SCF instead of DFT.

I wasn't aware of the recommendations regarding the 64-bit option, but I have rebuilt Dalton without it and the result is the same.

This is one of a series of SAPT-DFT calculations using our CamCASP program, and the whole calculation is set up by a script from a simple data file, so the data preparation is not as hands-on as it might seem. Also most systems in most geometries have no symmetry, so there's not much advantage in using it even when it's present. But I have re-done this calculation with symmetry and it still fails in the same way.

Also sometimes it's the ClF ghost calculation that fails and sometimes the CO ghost calculation. Most of the time both calculations are successful. I haven't tried the calculation with CO and ClF both "real" rather than ghosts, as that calculation isn't needed for SAPT-DFT.

[ajs1]

I have rerun the calculations using NWChem for the 6 geometries that failed under Dalton-2016. All ran successfully. This suggests to me that there really is a bug in Dalton-2016. (Earlier versions occasionally showed the same problem, but this seems to be a particularly troublesome case.) I could run all the calculations using NWChem, but I would prefer to use Dalton as its asymptotic correction procedure is probably more satisfactory.

[olav]

Interesting, for me it failed with GNU 6.1.1.

Now I see that it crashes also for GNU in sequential but completes in parallel. Sequentail/parallel diverge after the first iteration.

[olav]

Made an entry in the issue-tracking system (#107)

[xiongyan21]

Interesting, for me it failed with GNU 6.1.1.

Now I see that it crashes also for GNU in sequential but completes in parallel. Sequentail/parallel diverge after the first iteration.

On MAC with DALTON2016.2 installed, a parallel run finished, accompanied by the following information
...
@ *** DIIS converged in 15 iterations !
@ Converged SCF energy, gradient: -113.227075454239 2.87D-07
- total time used in SIRFCK : 0.00 seconds
...,
but a sequential one failed and was terminated by

4 Screening settings (-IFTHRS, JTDIIS, DIFDEN, times) -9 4 F 1.17D+01 1.17D+01

Number of electrons from numerical integration: 172.028221
Number of electrons from orbital occupations: 14.000000
Error in the number of electrons: 158.028221
Error larger than DFTELS (set input): 0.010000
Calculation aborted.

--- SEVERE ERROR, PROGRAM WILL BE ABORTED ---
Date and time (Darwin) : Tue Nov 22 20:09:27 2016
Host name : 

@ MPI MASTER, node no.: 0
@ Reason: Wrong number of electrons in DFTINT. Calculation aborted.

Total CPU time used in DALTON: 1 minute 6 seconds
Total wall time used in DALTON: 1 minute 4 seconds


QTRACE dump of internal trace stack

========================
level module
========================
9 DFTINT
8 DFTKSMb
7 DFT_ADD_KS
6 DIIS_CTL
5 SRDIIS
4 SIRCTL
3 SIRIUS
2 DALTON
1 DALTON main
========================

[hjaaj]

This issue has finally been fixed in the release/2020 branch.