AtomType Refactoring 1

[trisyoungs]

One of the most fundamental objects within Dissolve is AtomType - in itself it is just a storage object for potential interaction information for a specific type of atom, but is used as a means to index a vast array of other quantities. For example, when calculating g(r) (or S(Q)) one requires a set of partials between atom types, leading to the commonplace use of Array2Ds whose elements are keyed by the indices of AtomTypes.

But where do the indices come from? It was historically assumed that there would be a master vector of AtomTypes living in CoreData which would not change order and could reliably be used as a source of "index truth". While to-date this has proven successful, it does represent a rather fragile assumption, easily broken with poor code or innocent user action.

A further issue comes when considering serialisation. The old non-TOML serialisation in Dissolve allows ready access to CoreData and hence to current AtomType information, but moving to the node graphs of Dissolve2 this is not the case. As such, (de)serialisation of PartialSet (which depends on AtomTypeMix, which depends on AtomTypeData, which contains an AtomType pointer to store & retrieve) is not possible.

Solution

Assuming that AtomType data becomes delocalised in Dissolve2, but that an Atom in a Configuration still knows which AtomType is relevant for it (via it's knowledge of it's related SpeciesAtom) we can consider storing only atom type names rather than their pointers. This will drive us away from indexed Array2D structures for e.g. PartialSet and towards a "double-keyed" std::map where the key is the combination of two atom type names.

Tasks

• Introduce templated TypeMap to provide a double-keyed, optionally "half-matrix"-style alternative to the use of Array2D in e.g. PartialSet.
• Refactor storage in AtomTypeMix to use a std::map keyed by AtomType name.
• Atom still contains masterTypeIndex_, and it is still this which is used in energy routines.

Follow-On

• Atom class contains localTypeIndex_ as well as masterTypeIndex_ - in the absence of a global list of atom types these no longer work. We can solve this by creating when required, locally within a Configuration, any necessary AtomTypeMix (giving us a local order - this is the case already) as well as PairPotential map based on this mix (since no global pair potential storage will be available). For standard potential generation this is not an issue, but how do bring in PairPotentialOverrides? Similarly, g(r) calculation requires temporary 2D lookup based on the local indices, which again we can construct from the AtomTypeMix.

Related Issues

• Don't use indexing of AtomTypes for data access #508