[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] topology
Re: [h5md-user] topology
Fri, 25 Apr 2014 14:12:52 +0200
Opera Mail/12.16 (Linux)
Am 24.04.2014, 14:35 Uhr, schrieb Pierre de Buyl
On Wed, Apr 23, 2014 at 10:00:17AM +0200, Felix Höfling wrote:
Am 22.04.2014, 13:59 Uhr, schrieb Pierre de Buyl
We better keep the topology separate from the /particles tree. The
information complements the information in /particles, but is quite
different in structure. In /particles, there is one entry per
particle while the topology is about subsets of pairs, triples, etc.
It is true that the information in /topology is structured quite
than in /particles. I don't see a hard reason to choose any of the
yet, though. An advantage of putting it in /particles could be that the
particles' positions and topologies could be copied more simply from a
Eventually, everything is somehow related to /particles. But following
this argument we end up in putting everything in this tree, which is
probably not intended. Let's stick to the (informal) definition that the
data in /particles scale as O(N), one entry per particle.
Second argument: as I will outline below, the topology is not a single
H5MD element, but a group of such elements. And I would like to avoid too
nested structures for clarity. It should be as simple as
/<top level>/<group>/<H5MD element>
I realize that I forgot also that topology information could be pairs of
particles combined with an equilibrium/constraint distance. I have no
how to add that yet.
What is missing is to specify interaction parameters for each bond (even
if the functional form of the interaction is the same). The problem is
similar to the 'species' field in /particles and we could implement it
similarly as an additional H5MD element parallel to the list of bonds,
indicating the bond parameters. (It would require an additional
intermediate group though.) The bond parameters themselves have to be
specified elsewhere, as per bond species. Alternatively, there is an H5MD
element 'bond_length' which gives the parameter for each bond in the list.
The analogy would be the "mass" field in /particles (which could also be
specified on a per-species basis).
Actually, the spec 1.0 does not contain the possibility of providing
per-species properties. An generic extension would be most welcome. Such
data, of course, would not be stored inside /particle (no O(N) scaling),
but in a different top-level group. As of 1.0, the user may store such
information in /parameters.