Failure to handle some atoms in DFT

Find answers or ask questions regarding LSDalton calculations
Post Reply
taylor
Posts: 545
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Failure to handle some atoms in DFT

Post by taylor » 08 Jan 2014, 03:54

I was somewhat surprised when a calculation on TMS (tetramethylsilane), being run with LSDalton for purposes relating to calculating chemical shifts in much larger systems aborted with a (not unreasonable...) concern about numbers of electrons, specifically:
Number of electrons from numerical integration: 162.280500
Number of electrons from orbital occupations: 14.000000
Error in the number of electrons: 148.280500
Error larger than DFTELS (set input): 0.001000

This is while doing the step ' Level 1 atomic calculation on pcS-1 Charge 14'.

As can be seen from the attached .dal file the functional used is KT3, but replacing this with B3LYP resulted in a similar abort, although the result from numerical integration was different. Hartree-Fock runs, so naively there should not be an issue with something strange in the .mol file or anything. The basis set is pcS-1, replacing it with cc-pVDZ still gave an error, and running pcS-1 with .NOGCBASIS also gives an error (all these errors are integration errors).

Since the error message arises when the program is treating the Si atomic calculation, I replaced the Si with a C (thus effectively doing neopentane at the TMS geometry). This works. Reducing the TMS molecule to a simple SiH4 failed with an integration error. Just to have a comparison with another second-row system I ran H2S. This also failed with an integration error doing the atom calculation on the sulfur.

Is there some point or option I have missed with respect to second-row atoms? As I say, Hartree-Fock works. I have only attached the original calculation that failed but if anyone wants the other files I can easily make them available.

Best regards
Pete
Attachments
JOB.out
(22.11 KiB) Downloaded 396 times
kt3_nmr.dal
(86 Bytes) Downloaded 366 times
tms.mol
(1006 Bytes) Downloaded 367 times

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 08 Jan 2014, 15:30

This is a bug. You have not missed a point or some option with respect to second-row atoms. Your input should work. The bug will be fixed (hopefully soon, but I am currently attending a workshop) and included in the next patch. Thank you for reporting the problem.

Best Regards
Thomas Kjærgaard

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 22 Jan 2014, 13:43

I am back to work, but unfortunately I am unable to reproduce the error. I have tried several build versions (with MPI, without MPI, with debug options, without debug options) but no luck. Would you mind trying to deactivate OpenMP ? That is the only thing I can think of.

Best Regards
Thomas Kjærgaard

taylor
Posts: 545
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Failure to handle some atoms in DFT

Post by taylor » 28 Jan 2014, 00:55

Sorry to be slow in replying, but as people may know quantum chemistry is no longer my day job...

I rebuilt with EVERYTHING "turned off". That is, ifort rather than mpif90, etc., so no MPI at all (and indeed no MPI binary identified in the lsdalton run script), and with the only option to the build being mkl=sequential, to ensure no threading or OpenMP. I believe this is the most "bare" build of the program possible. It produces identical results to my earlier builds: exactly as I previously posted. With a second-row atom the electron count from the integration is idiotic (182.xxx instead of 14 for Si, as I posted before). I cannot see that Thomas and I can possibly be running the same versions of the code! Is there any patching that I might have missed that could have addressed this issue?

Best regards
Pete

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 28 Jan 2014, 11:28

According to your output file

Configuration:
==============
This is an OpenMP calculation using 4 threads.


you do use OpenMP

if this is done inconsistently (using -openmp without having the -DVAR_OMP preprocessor flag) it could give the error you are reporting.

I will see if I can add a sanity check to ensure that this is tested.

TK

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 28 Jan 2014, 11:33

but you say that the the basic built with EVERYTHING "turned off" does not use OpenMP?

TK

taylor
Posts: 545
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Failure to handle some atoms in DFT

Post by taylor » 28 Jan 2014, 15:21

Sorry, you have completely misunderstood. I do \emph{not} use OpenMP in the contribution I posted yesterday/today (depends on your timezone...)!

Your response to my original posting was that you could not reproduce the error, and (as you said, pretty much as a last-ditch suggestion) you asked me to run with OpenMP disabled. I took this request at face value, and \emph{rebuilt} the code as I described: no MPI, no OpenMP, no CSR, no Scalapack, no int64, no nothing! (And with -mkl=sequential). If there is a more complete way to construct a single-core single-threaded scalar sequential version of the code, I would like to know how to do it. And with this "absolutely bare-bones" version of the code, I get \emph{exactly} the same error as I initially posted: the code calculates that an Si atom has 182.xxx electrons, and since the code "knows" Si has only 14 electrons, this fails the internal test on the numerical integration process during the atomic calculation. As I also said in my initial post, this is undoubtedly in the numerical integration (I do not say necessarily in LSDalton itself, by the way) because there is no problem whatever doing a Hartree-Fock calculation.

I stand by what I posted earlier today/yesterday: a completely sequential one-thread one-core instance of the code produces the same error for second-row atoms as any other build I have tried: whether that be threaded, OpenMP, MPI, Scalapack, i8, or any combination of the above! If you do not see this, my initial conclusion, given that you appear from another posting to have the same compiler/library setup, other than our using OpenMPI, which is irrelevant given my rebuilding without any parallelism as described above, is that your version of the code \emph{must} differ in some respect(s) from mine. And I ask again, what patches have been applied, and what do they correct for?

Best regards
Pete

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 28 Jan 2014, 15:45

Sorry.

Since I am an developer I use the git repo version - but this should be the same as the distributed version after running the update.py script.

The changes that the update script applied are not related to XC integration

they should be

- Fixed a bug in Jengine, related to screening for nonsymmetric density matrices.
This may affect CCSD and some response calculation.
- Modified the input section of the manual concerning
Casida-Salahub asymptotic correction CS00 (thanks to Raul Crespo).
- Changed defaults for Casida-Salahub asymptotic correction CS00 (thanks to Raul Crespo).
- Fixed errors in the MCD B terms output files (.dat files) now one file is generated
for each B term and each A term (thanks to Raul Crespo) .
- Modified the input section of the manual concerning MCD B terms. Added desciption of MCDEXSTATES.

I will try to get the exact version of the code the we distribute.

If this still do not work I am at a loss. The XC integration uses BLAS but no other external libs and therefore it must be an error in LSDALTON - but I do not see what it could be.

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 28 Jan 2014, 17:02

I got the distributed version.

git status displays:

commit a0d9b023afaafc66b80421f22d1db50b5e9b8e39
Author: Radovan Bast <lastname at kth.se>
Date: Thu Dec 19 18:39:56 2013 +0100

v2013.1

created from 653a3c9fdcde6b463c7e208ddf10abd66f7c54f6

commit ed4b8bd55663769d70ec36d559a44e367f0f5395
Author: Radovan Bast <lastname at kth.se>
Date: Mon Nov 4 13:19:49 2013 +0100

v2013.0

created from 575a5cf6d2c5c3776735f11fa026dbfca0382455

and I still cannot reproduce the error.

I have only run with cc-pVDZ since pcS-1 is not included, but you did mention that it was not basis set specific.

I have tried with and without the .FORCEGCBASIS

**GENERAL
.FORCEGCBASIS
**INTEGRAL
.LINSCAPRINT
2
**WAVE FUNCTION
.DFT
KT3
**RESPONSE
*SHIELD
*END OF INPUT
but I get the same normal behavior
Attachments
LSDALTON.INP
(111 Bytes) Downloaded 367 times
MOLECULE.INP
(1009 Bytes) Downloaded 356 times
LSDALTON.OUT
(76.94 KiB) Downloaded 377 times

tkjaer
Posts: 300
Joined: 27 Aug 2013, 20:35
First name(s): Thomas
Last name(s): Kjaergaard

Re: Failure to handle some atoms in DFT

Post by tkjaer » 07 Jul 2014, 12:59

I have finally been able to reproduce the problem and fixed it.

It will be fixed in the 2014 release and the next patch to the 2013 release

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest