Re: [h5md-user] Species Data Type

[Nicolas Höft]

Am 05.08.2013, 12:18 Uhr, schrieb Pierre de Buyl
<address@hidden>:

> Hi Nicolas,
>
> Thanks for discussing your suggestion for H5MD :-)
>
> On Mon, Aug 05, 2013 at 11:43:11AM +0200, Nicolas Höft wrote:
> > I've started making a simulation involving 'real' atoms.
> > To distinguish the atom type, I use the particle species. From a
> > simulator point of view the number type of the species makes
> > perfectly sense. But  when one has a lot of different atom type the
> > H5MD species type (number) becomes very impractical from a users
> > point of view because it is hard to remember (and see) what species
> > was what Atom type.
> >
> > A more useful identification in my case would be the short name of
> > the Atom (e.g. H, Ar and so on). This would also be in line with the
> > often used descriptions in mixtures of the particle types ("A", "B",
> > .. ).
> >
> > One solution to allow this kind of species identification is to drop
> > the constraint ", and is of scalar integer data type".
>
> The constraint is there for several reasons:
> 1. If you want "string", that is H, Ar, etc. that have several lengths,  
> you need
> to know in advance the max length or use variable length datatype.  
> Neither of
> those solutions are practical.

Well, in the case of chemical elements, you'll never exceed 2 characters.

> 2. Possibly (this should be tested), using integers only would allow for  
> better
> data compression.
> 3. Using "A", "B", "C", etc. is not an interesting progress wrt 1,2,3,...
> 4. Numeric datatypes are, in general, easier to work with from a language
> point-of-view. Also, it is much more likely that a numeric datatype  
> matches the
> actual implementation of the data in memory.

Yes, I have noted that, too. I know that from a simulator point of view
numbers make sense. But if you have ~20 atom types, numbers are really
very abstract. Still, I think it should also be more important to read it
  from a users point of view, not necessarily from the program.

> Extensions of "species" could be discussed later on, however (after we  
> settle on
> a base format that will receive the version number 1.0).
>
> Regards,
>
> Pierre