OPTIMADE icon indicating copy to clipboard operation
OPTIMADE copied to clipboard

Chemical symbols D and T

Open merkys opened this issue 3 years ago • 7 comments

OPTIMADE specification v1.0.0 contains quite vague guidelines about allowed values for chemical symbols. Implicitly it is understood that they are symbols from the periodic table. However, deuterium (D) and tritium (T), which are present in the COD, are two common symbols not appearing in the periodic table. Maybe the specification could have an explicit clause allowing D and T in element listings as well as formulae? Of course deuterium and tritium could be detected by different masses in species.mass, however, as query support for species is OPTIONAL, there is no other way to filter deuterium and tritium in or out.

merkys avatar Oct 28 '20 11:10 merkys

In the web meeting of 2020-10-28 the following points were raised:

  • isotopes can already be identified via atomic masses, therefore, there is no need to duplicate that information in chemical names;
  • searches for H atoms have to return structures with deuterium and tritium too.

AFAIR there was no clear consensus about the following:

  • usage of D and T in searches (should they match structures with deuterium and tritium, if a provider differentiates between hydrogen and them?);
  • usage of D and T in formulae.

I personally prefer homogeneity: if we decide that D and T are not allowed in species, then they should not appear in formulae and should not be supported in searches too.

merkys avatar Oct 29 '20 11:10 merkys

  • isotopes can already be identified via atomic masses, therefore, there is no need to duplicate that information in chemical names

Actually, the specification defines mass as an average mass on a site, thus it is not defined as mass-per-species-per-site, but as mass-per-site. This additionally complicates the task of identifying deuterium and tritium, but should still be doable for sites with no more than two species in them.

merkys avatar Nov 09 '20 14:11 merkys

Actually, the specification defines mass as an average mass on a site, thus it is not defined as mass-per-species-per-site, but as mass-per-site. This additionally complicates the task of identifying deuterium and tritium, but should still be doable for sites with no more than two species in them.

Would it make sense to change the value of mass to a list instead? If the average value of the mass on the site is needed it can easily be calculated by the user or we can propose an additional field?

CasperWA avatar Nov 09 '20 15:11 CasperWA

Would it make sense to change the value of mass to a list instead? If the average value of the mass on the site is needed it can easily be calculated by the user or we can propose an additional field?

I would go for redefining mass as a list of floats. From a list one can easily calculate the average mass. For the same reason I would not keep an additional field for a value so easily calculated.

merkys avatar Nov 09 '20 15:11 merkys

With #344 merged and staged for release in v1.0.1, deuterium and tritium can be removed from the species and probably formulae too. Nevertheless there is an advantage of retaining their chemical symbols: Apart from zip comparison, there is no other way to select structures having deuterium and tritium if they all are represented as H in species and formulae, and zip comparisons are quite difficult to implement.

merkys avatar Jun 03 '21 13:06 merkys

Would the kind of filters that you are interested in be covered by an extension of the structure_features enum to include "uncommon_isotope"/"isotopically_enriched" or somesuch? Or is querying specifically for H, D and/or T (and perhaps their "element" ratios) required?

ml-evs avatar Jun 03 '21 14:06 ml-evs

I am just thinking out loud about this scenario. Not sure how useful it is, though. But since by converting D and T to H in COD/TCOD we lose some bits of information, it has to be thought through.

Structure feature uncommon_isotope sounds valuable indeed. I would expect uncommon isotopes requiring different pseudopotentials in DFT calculations, right?

merkys avatar Jun 07 '21 05:06 merkys