Mismatch between specified total charge and occupations

[by-student-2017]

Describe the bug

!!! [common] AtomParameters/ra: Mismatch between specified total charge and occupations (0.00000000 vs. 2.00000000)

To Reproduce

Ra { AtomConfig { AtomicNumber = 88 Mass = 226 Occupations { $OCCUPATIONS_Rn 6D = 0.0 0.0 7S = 1.0 1.0 7P = 0.0 0.0 }

skdef.hsd_Ra.txt

or

Ra { AtomConfig { AtomicNumber = 88 Mass = 226 Occupations { $OCCUPATIONS_Xe 4F = 7.0 7.0 5D = 5.0 5.0 6S = 1.0 1.0 6P = 3.0 3.0 6D = 0.0 0.0 7S = 1.0 1.0 7P = 0.0 0.0 }

An error that may be related. [skgen.compression] Processing compression for shell(s) 6d 7s 7d [skgen.compression] Calculating compressed atom (build/th/comp.gkk28jl) "!!! [common] Missing wave function file build/th/comp.gkk28jl/wave_07s_up.dat"

Th { AtomConfig { AtomicNumber = 90 Mass = 232.04 Occupations { $OCCUPATIONS_Rn 6D = 2.0 2.0 7S = 0.0 0.0 7P = 0.0 0.0 }

skdef.hsd_Th.txt

I looked at "sktools/src/sktools/common.py" and "sktools/src/sktools/skdef.py" but I don't know where the problem is. I feel that the electrons in the orbit where the principal quantum number is 7 cannot be counted accurately.

Expected behaviour

I want to be able to calculate up to Pu.

Additional context

[vanderhe]

Hi @by-student-2017,

having had a brief look at the problem both errors (Ra and Th) are symptoms of a common cause: As far as I can see your conclusion that the $7S$ occupations are not parsed correctly is absolutely true, in fact

https://github.com/dftbplus/skprogs/blob/097a928d96418d69a8136e8be4f17c7dc6f39dc7/sktools/src/sktools/skdef.py#L308

will prevent any orbital $n \geq 7$ to be parsed correctly and instead tupels of $(0.0, 0.0)$ are appended. I have to check if this limitation has been implemented on purpose (although in any case a helpful error message should be added) or if it is safe to include the upper bound of $n = 7$.

Best regards Tammo

[vanderhe]

@by-student-2017 The fix is now available in the main branch, however, I noticed that you probably have to choose a smaller STO basis, i.e. smaller max. power and/or smaller number of exponents. Otherwise you will end up with near linear-dependence and the code halts.

[by-student-2017]

Thank you for the quick fix. After introducing the fix, I am currently testing the behavior on various systems, but we believe there will be no problems.

Thank you for your comments regarding STO basis, etc. I am currently exploring parameters with various elements. Even if you look at the papers, there are few guidelines for parameters, so a lot of effort is put into it.

[vanderhe]

Thank you for your comments regarding STO basis, etc. I am currently exploring parameters with various elements. Even if you look at the papers, there are few guidelines for parameters, so a lot of effort is put into it.

Finding a suitable STO basis is "straight-forward" in the sense that it just needs to be converged, i.e. the results of the pseudo-atom calculations or the content of the final Slater-Koster files should not change anymore. You can compare SK-files via the skdiff tool, but be aware that the onsite energies of unoccupied orbitals in your valence shells are ill-defined and might erratically change even though you have a converged basis. The STO exponents are usually chosen so that they are the same for all shells (in your case s, p, d, f) and generated according to a geometric series. You can use the skexp tool to generate the exponents for a given element, see skexp -h for its usage.

[by-student-2017]

Thank you for the valuable information. skexp.py is now available. Until now, I have been looking for Bayesian optimization, but this tool has made it more accessible. All left is power, and radius for density s,p,d and f ! For power, if two don't work, I set it to 4, but there are times when seven is better, so it's a problem. It is stated in part 2 of QUASINANO's paper that mio has perfect accuracy, so I would like to create parameters comparable to mio using the example mio as a reference.