Atomic radii and other properties

[PaulWAyers]

We should make sure we have the atomic radii and other properties in
https://github.com/QC-Devs/gopt/blob/main/gopt/periodic/data/elements.csv

[gabrielasd]

Gather the properties in
https://github.com/theochem/AtomDB/blob/master/atomdb/data/elements.csv
and the default multiplicities and elements tuples in a common file.

AtomDB/atomdb/api.py

Line 80 in 184a693

MULTIPLICITIES = (

AtomDB/atomdb/api.py

Line 63 in 184a693

ELEMENTS = (

For instance we can have a similar periodic properties module as @marco-2023 made for Gopt:
https://github.com/theochem/AtomDB/blob/master/atomdb/periodic.py

Then update the function

AtomDB/atomdb/api.py

Line 466 in 184a693

def get_element_data(elem):

used to retrieve this information for an atomic species in the compilation scripts.

[gabrielasd]

We need to compare the MULTIPLICITIES table for the ground state multiplicities against another source to make sure it is correct. It was generated from Derrick's HDF5 file.

[PaulWAyers]

You can double-check against
https://en.wikipedia.org/wiki/Term_symbol#Atomic_term_symbols_of_the_chemical_elements

I know that there are some issues, at least for excited states, from the automatic parsing. For example, for Pd, the first triplet is only $6564.148 \text{ cm}^{-1}$ above the ground state, but I think we missed it because it is only labelled with $J$ quantum numbers. I think the data is pretty good up to Sr ($Z=38$).

[marco-2023]

Hello @gabrielasd and @PaulWAyers:
I made a version of the new periodic module for atomdb and checking the multiplicities I stumbled into a problem:
As it has been implemented so far, when the multiplicity is wanted for an atom of Z=atnum with a given charge, the module returns the multiplicity of the element with number of electrons = Z - charge. The problem is there are elements for which this is not correct.

For example:
For Cr its electron configuration is [Ar] $4s^{1}3d^{5}$ and according to this algorithm for Cr $^+$ its multiplicity is taken equal to the one for V with electronic configuration [Ar] $4s^{2}3d^{3}$ (multiplicity = 4) but the real electron configuration of Cr $^+$ is [Ar] $3d^{5}$ (multiplicity = 6).

This kind of deviation is also potentially expected for multi charged atoms. Do you have any sugestions on how to deal with it? I think making a database for each atom multiplicity may be excessive.

[gabrielasd]

@marco-2023 thanks for bringing this issue up. It is definitely a problem present in the numeric dataset, and something to check/test in the others.

There is one database that has the information like you suggest. It is the file database_beta_1.3.0.h5 which has all stable multiplicities for a given atomic number and charge. So I think for neutral and cations this is what we should be using to check against in the scripts. For example as is done for the NIST dataset:

AtomDB/atomdb/datasets/nist/__init__.py

Lines 79 to 86 in edd4604

	os.path.join(os.path.dirname(__file__), "raw/database_beta_1.3.0.h5"), "r"
	) as f:
	mults = np.array(list(f[z][ne]["Multi"][...]), dtype=int)
	energy = f[z][ne]["Energy"][...]
	# sort based on energy
	index_sorting = sorted(list(range(len(energy))), key=lambda k: energy[k])
	mults = list(mults[index_sorting])
	energy = list(energy[index_sorting])

However, for the anions, we are just taking the value from the isoelectronic specie, and we have the same problem you describe (the anion of V gets assigned the multiplicity from neutral Cr)

[gabrielasd]

This issue has been resolved with the changes introduced in PR #27.
The module periodic parses the information for an element from the table elements_data (originally, elements.csv) and makes it accessible by creating an instances of the Atom class.

This module is intended to be used by the compilation scripts of the different databases to fill periodic properties of neutral atomic species (mass, atomic and van der Waals radii, etc.).