Closed GoogleCodeExporter closed 8 years ago
I just added a dlpoly trajectory reader, which reads/sets the box from the
current frames, so using the dlpoly topology reader together with this
trajectory reader should work for now, but the box should still be set in the
topology reader, too.
Original comment by christop...@gmail.com
on 7 Nov 2013 at 10:26
I just reiterate here my last comment from the closed issue #139:
<<<
- I would check the CONFIG, first of all, for the second number in the second
line (i.e. after the title), the possible values are:
0 - no PBC, 1 - cubic PBC, 2 - orthorhombic PBC, 3 - parallelepiped PBC etc
(see DL_POLY manual).
- One has to take care about the first number there too, it defines the level
of CONFIG data:
0 - coords only, 1 - plus velocities, 2 - plus both velocities and forces
included.
>>>
By now (after reading Christoph's description) I realise that for some reason
it is expected that top.setBox is called from
DLPOLYTopologyReader::ReadTopology. Is it needed there? The fact is FIELD (as
well as Gromacs .top file) does not contain any info/data about the box or PBC.
These data, box sizes/matrix and the PBC switch must be read from CONFIG or
HISTORY (just like in Gromacs, .gro, or .trr, or .xtc files).
Anyhow, I will be waiting for other issues to appear (I suppose some should pop
up), and then look at the entire bunch.
Original comment by abruk...@googlemail.com
on 7 Nov 2013 at 10:27
Adding here what was originally contained in my small test code (a bit of
documentation on the structures used):
<<<
// AB: the parameter meanings in the data structures are self-evident, below only the least evident ones are described
// AB: FrameSiteT.id - index of site in the entire system (following the order of appearance in a frame)
// AB: FrameSiteT.im - index of site in a molecule (same as FieldSiteT.idmol)
// AB: FrameSiteT.ig - index of site in a neutral/charged group (same as FieldSiteT.idgrp)
// AB: FieldSiteT.ifrzn = 0/1 - determines if the site must be "frozen" (must not move at all)
// AB: FieldSiteT.nrept - number of subsequent repetitions of the site in a molecule
// AB: FieldSpecsT.ineut = 0/1 - determines if neutral/charged groups are present (0 => molecule=1group)
// AB: FrameSpecT.keytrj - determines the level of trajectory data:
// AB: FrameSpecT.keytrj = 0 => only coordinates are present
// AB: FrameSpecT.keytrj = 1 => only coordinates & velocities are present
// AB: FrameSpecT.keytrj = 2 => coordinates, velocities & forces are present
// AB: FrameSpecT.imcon - determines the type of PBC image convention:
// AB: FrameSpecT.imcon = 0 => no PBC (no boundaries)
// AB: FrameSpecT.imcon = 1 => cubic
// AB: FrameSpecT.imcon = 2 => orthorhombic
// AB: FrameSpecT.imcon = .. => etc. (see DL_POLY manual)
>>>
In general, the names of structures reveal their source, whereas the variable
names reveal their meaning and usage. "Frame" stands for both CONFIG and/or
HISTORY, as there data are essentially the same - the entire system specs that
can be found in those files. "Field" stands for the data from FIELD file, and
can be expanded into the force-field specs for the entire system, by looping
over <Name>.nrept - number of repetitions of the corresponding entity (molecule
or site).
Please, tell me (or comment here) if anything is not clear yet.
Original comment by abruk...@googlemail.com
on 7 Nov 2013 at 11:08
About the cell:
FullCellT is only there for completeness (sort of "for future use")...
Use FrameSpecsT->cell[..] - which is a 9-vector representing the 3x3 matrix
describing the cell/box geometry, stored row after row) for the cell dimensions
read either from CONFIG or HISTORY (for more detail on the cell matrix see
DL_POLY manual).
Original comment by abruk...@googlemail.com
on 7 Nov 2013 at 11:15
On gromacs: we actually read the tpr files, which is a combination of a .top
and a conf.gro files for the initial conditions. So we have the initial
coordinates there. The time dependent trajectory is then in the .trr and read
separately.
I don't know too much about dlpoly, where does it store the initial conditions?
Can we get this separately from the rest of the trajectory (HISTORY?). I think
in general this might not be so clear.
I'm not sure if the topology reader should be enforced to provide the box
settings (or does the initial configuration belong to the topology)? Even
though this might not be convenient in all cases it could be the most
consistent choice not to give this information here.
In any case, the topology reader should not (!!) read the trajectory/history
(unless this file is available before you run the simuation), so would the
initial conditions be available elsewhere?
Original comment by victor.r...@gmail.com
on 7 Nov 2013 at 11:24
Consider: FIELD = topol.top, CONFIG = config.gro and HISTORY = traj.trr
There is no equivalent to traj.xtc, as the latter may not contain some species;
i.e. HISTORY always appears after a simulation done, and contains frames of the
entire system.
Original comment by abruk...@googlemail.com
on 7 Nov 2013 at 11:44
Thanks for the clarification, that sounds clear to me then. So I think we
should read the CONFIG file in the topology reader, if that is on the fortran
or c++ side doesn't matter - whatever is easier.
One point here which comes to my mind: the distance function for triclinic
boxes in votca curretly relies that the box matrix is defined as in gromacs (I
think upper or lower triangular, I don't remember). We might have added a
warning at some point if it's not. But we should keep that in mind that an
issue might pop up here and maybe convert in the reader...
Original comment by victor.r...@gmail.com
on 8 Nov 2013 at 12:03
This issue was closed by revision 089965f6486e.
Original comment by jungh...@votca.org
on 8 Nov 2013 at 12:10
Original issue reported on code.google.com by
christop...@gmail.com
on 7 Nov 2013 at 10:13