|
| From: | Hart, David Blaine |
| Subject: | Re: [h5md-user] [EXTERNAL] Re: H5MD box group |
| Date: | Tue, 29 Apr 2014 19:40:14 +0000 |
|
Hi Olaf, thanks for your reply. The main reason I’m interested in an offset element is because of the way LAMMPS does its boundaries. LAMMPS stores its triclinic bounding box as [xlo, xhi],
[ylo, yhi], [zlo, zhi], [xy, xz, yz]. Now this is nice, because it is easily put into an
H = (a b c) = ( (xx, 0, 0)’ (xy, yy, 0)’ (xz, yz, zz)’ ) matrix, which the ‘edges’ element seems to already expect for triclinic boxes. But LAMMPS does certain things, like NPT calculations, where it changes both the –lo and –hi
elements simultaneously to increase/decrease the volume. And I know lots of the LAMMPS coders do their simulations in space where a particular dimension is bounded from (–X/2, X/2] rather than from (0, X]. So while the H-matrix, or box->edges element, provides
complete information for the shape and orientation of the bounding box, assuming that the
a, b, and c box vectors start at the origin can result in a box that is offset from the atom positions.
This is particularly vivid when using the LAMMPS XTC plugin, which outputs a gromacs-formatted trajectory; if such an output is visualized in VMD, or any other
viewer, the box can wind up offset from the atoms by a huge amount, making visualization really look bad. While it is possible to TCL script a solution for this, using pbc wrap to put the atoms into the box, it can take a long time to do. Another issue is
that for NPT simulations, the VMD box will expand and contract from the box origin (0,0,0) while the atoms are expanding and contracting from the box center. If the box origin is stored, the box can just be shifted to the right position for the frame, and
there is no extra post-processing needed. The VMD-lammpstrj plugin does this for LAMMPS text dump files, but, of course, they are text files and huge which is why I want to move to h5md anyway
J I’ve re-written this email several times, as I’ve sorted out what I want to do in my head. It would seem that I’m looking at two things. The first, converting
my current dump files to the H5MD format, I can do a little bit looser and store things in a separate root group if necessary. The second, writing a LAMMPS plugin that would output H5MD files directly, I probably want to be a bit more formal, specifying what
extra fields are output as particle information in an h5md module, so that the LAMMPS code can point to a module definition defining the elements within a particles group (like the thermodynamics module does with observables) that can be linked to each other
with the semantic versioning number. Is that the approach you would suggest? Or would you still suggest putting the non-standardized particle data in a different root group? [You convinced me that adding particles/…/box/offset would be a bad idea, but I still
think that particles/…/offset would be useful with lammps outputs.] Thanks, David From: address@hidden [mailto:address@hidden
On Behalf Of Olaf Lenz Hi! In general, the H5MD-Format only specifies how to interpret certain groups/datasets if they exist. However, there is nothing that prevents a user to add arbitrary further groups/datasets to any other group - only they are not standardized.
So there is no problem, you can easily supply an offset in the box vector. However, I would suggest to put data that is not standardized in h5md into an own, application-specific group. As for the "offset", the discussion was that we (i.e. at least Konrad and me) did not see any use for it, and (as far as I remember) nobody was able to provide us with an actual use case. The only application that we saw was that the offset
plus the edges would provide a bounding box of the particles in the system. However, the use of that would be limited, as a h5md reader should still not rely that all particles are in that box. Can you provide another use case? Why would you need to store an offset, and what exactly would it mean? Olaf 2014-04-28 20:19 GMT+02:00 Hart, David Blaine <address@hidden>: I am interested in using H5MD to store converted trajectories from LAMMPS text dumps, but eventually also writing an H5MD dump plugin to LAMMPS to avoid the conversion step. As
I’ve read through the mailing list archive, it seems that the particles->…->box->offset group has come and gone as part of the specification. Does the spec. require that only ‘edges’ be present in ‘box’, or can offset also be present? I realize that if I’m only using my own tools, that I can do as I see fit, but I’d like to conform to the specification as much as possible, especially as I move towards direct
HDF5 output from LAMMPS. Is the definition of extra groups, like offset within box, the purpose of the modules? Thanks, and I am excited that the specification has been published! David Hart
-- Dr. rer. nat. Olaf Lenz Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart Phone: +49-711-685-63607 |
| [Prev in Thread] | Current Thread | [Next in Thread] |