[Feature Request] Add a new namespace "elements" for functions related to chemical elements

[akohlmey]

Summary

Add new namespace "elements" with tables/maps and functions accessing them for a variety of mappings related to chemical elements and their properties like atomic number, atomic mass, covalent radius.

Detailed Description

There are several places where chemical elements are referred to or where it would be desirable to have some way to access information related to chemical elements or perform conversions/replacements. This new namespace would consolidate these functions and provide a common interface. Possible applications:

• mapping of atom types to elements (using a fuzzy matching of the atomic mass) for output (dump, reaxff/species)
• mapping of atom types/elements to (covalent) radii (dump image/movie, create_atoms overlap, create_bonds)
• mapping of element names to atomic numbers (ZBL potentials, MDI QM/MM coupling)

Suitable data and similar function exists already in VMD's TopoTools and molfile plugins for similar purposes and can be adapted for LAMMPS.

[alphataubio]

@akohlmey has anybody done anything on this issue yet ? id be willing to pitch in next if you give me some initial guidance on what path to follow. we can keep it in a draft pull request as i will struggle along for a learning experience about contributing code to lammps.

i looked at topotools inside VMD.app, all i saw is a few tcl scripts no data. i also read the topotools tutorial on your website, all i saw there were a few pdb files for ethane, hexane, and cyclohexane. i dont see anything in src/MOLFILE, or example/plugins.

i was thinking something like https://webbook.nist.gov/chemistry/ or https://pubchem.ncbi.nlm.nih.gov/docs/elements ...

[akohlmey]

This is not a good topic for the purpose. I have some very specific ideas in my mind already. I mostly put up the issue to indicate that I will be working on this (it is assigned to me after all) and to get some feedback. The key part is going to be to have some data structure that provides the mapping and then take advantage of that. A major challenge is going to be to prioritize the different kind of (more or less optional) data to be used for deriving elements and how to handle conflicts. Also, this needs to be make compatible with the various unit style choices.

The reference to molfile plugins does not refer to the MOLFILE package, but the actual source code in the vmd plugins sources. https://github.com/thatchristoph/vmd-cvs-github/blob/master/plugins/molfile_plugin/src/periodic_table.h
I have adapted this in a minimal fashion for LAMMPS-GUI https://github.com/lammps/lammps/blob/develop/tools/lammps-gui/imageviewer.cpp#L120

Once the basics are done, the added functionality needs to be enabled in a variety of places. That would be something, where help from you could be useful.

If you want to do useful work and get to know the LAMMPS internals better, you could have a look at the projects proposed here: https://www.lammps.org/workshops/Aug22/
Most of what was proposed there is still incomplete.

[alphataubio]

Ok I'll reverse commit and close PR 4035

[akohlmey]

@sjplimp Here is an outline of the features that would be added and modifications done.

• The elements namespace would implement a number of A-to-B functions, e.g. atomic mass to element index in the periodic table of elements, string to element index in the PTE, element index to atomic mass, element index to covalent radius, element index to VDW radius and so on.
• The Force class would have to have a "mass2amu" constant to convert the element masses to a consistent unit (all "elements" functions would be internally using AMU for masses).
• The LAMMPS class would contain a new class ElementMap that would internally have a std::vector<std::string> where there is one "elment string" per atom types. Unlike with type labels, where types and labels have to be unique, this can assign the same element to multiple types. So there cannot be a reverse mapping element to type. That is what the typelables are for.
• The ElementMap class would also be interfaced to LAMMPS inputs through a new "element" command that would function similar to the "mass" command.
• The element list could also be initialized from pair_coeff statements (like from manybody potentials or ReaxFF)
• A last fallback for trying to derive element strings could be using the atomic mass to element function in the element namespace
• The collected element information can then be used for a variety of applications:
  • there could be a dump_modify <id> elements auto that would use the element map instead of having to specify entries for all types (which can be a lot for some inputs)
  • there could be a mass * auto command that assigns masses from element names (masses for which no element name could be derived, will remain unset)
  • A ZBL pair styles could accept element names in addition to their PTE element indexes for simpler input
  • this would generalize some functionality (and possibly enable future functionality) in the MDI package
  • the fix reaxff/species command could use the information from the element list for more accurate output. This would generalize and supersede what is suggesting in PR Fix reaxff/species fixes #3824
  • the dump image (and thus also dump movie) command can use the element list and the per-element VDW info to set color and size of atoms. This generalizes and expands partially existing functionality.
  • the create_bonds command and fix bond/create and fix bond/break could use the element and covalent radius info (plus a fudge factor) to auto-create distances for pairs of atoms and bonds to be created or broken.

[jrgissing]

I like this idea, but I don't think it would generalize or supersede #3824. Note that #3824 simply allows reaxff/species to determine elements from the pair_coeff command, no matter how that element list was determined (e.g., perhaps by using this new "elements" namespace). Also, note that half of that PR is a bugfix related to deduplicating the reported chemical species