Re: [h5md-user] topology

[Pierre de Buyl]

Hi Konrad,

On Tue, Apr 29, 2014 at 09:26:20AM +0200, Konrad Hinsen wrote:
>  > 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?

The scope is not defined yet. I would like to discuss the needs and experiences
before we can decide something. There might be no universal solution, a case in
which there could be different topology modules.

I described my use case: store list of indices that represent bonded interaction
in coarse-grained simulations. I don't expect my use case to be generic :-) 

>  > 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.

No problem.

>  > 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.

Noted. I have no specific name in mind for this, though.

> 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.

Keeping all of that in mind, it would be beneficial to have an agreed-upon
"storage scheme" (such as "[N_bonds][bond_order]" from my message) for
connectivity-related modules, to avoid duplicating the work.

Pierre