[h5md-user] topology

[Konrad Hinsen]

Hi everyone,


 > Topology was deliberately left out of H5MD 1.0. The intent was that feedback 
 > on
 > this point was needed, as well as some experience with relevant simulations.
...

Before discussing the technicalities, please define the scope of what
you call "topology". Which kinds of molecular models do you wish to
cover? Which categories of systems do you want to handle? And what are
the use cases for the information you plan to store?

 > Depending on the direction of the discussion this could become either a 
 > module
 > or a part of the specification itself.

Unless we can come up with something good enough for all kinds of particle-based
simulations (which I doubt), it's better to make it a module in order to allow
for alternatives. One of the nice aspects of H5MD is its generality.

 > 2. Within the groups, H5MD elements store bonds as [N_bonds][bond_order] 
 > data.
 > For pairs, bond_order=2, for instance. This allows to store angles and

Please note that the term "bond order" is already used in chemistry
for something different: the number of electrons implied in a covalent
bond. A chemist would take bond_order=2 for a double bond.


I have spent a lot of time thinking about these issues for MOSAIC, and
a part of the background behind the decisions that lead to MOSAIC 1.0
is described in the paper (free download at
http://pubs.acs.org/articlesonrequest/AOR-dADBta6jVTVtVb6bbGmJ, but
you need to create an ACS account for that). Note that the scope
of MOSAIC is different from H5MD, so the considerations to apply
are not the same, but there are many common points nevertheless.


One of the most important lessons from MOSAIC design, which I think
carries over to H5MD, is the need for both generic data structures and
precisely defined data items. For example of chemical bonds, that
would mean a generic data structure for storing pairs (or even
N-tuples) of particle indices, with some way of attaching semantic
information such as a text label. A bond list would then be stored as
a list of pairs with the "bonds" label.

If you provide only the generic data structure for pairs, then
everyone will come up with a different label for bonds, creating chaos
without any real gain in flexibility. If you provide only a bond list
but not a generic pair list, people will abuse the bond list for other
pair-related applications. The history of the PDB format provides
lots of examples of such abuses due to a lack of flexibility.

H5MD actually applies this principle very well until now, so let's
keep that spirit for defining additional data items.

Konrad.