dlpoly topology reader (c++ part) does not set boundary conditions

[GoogleCodeExporter]

See issue #139, comment 8.

Basically DLPOLYTopologyReader::ReadTopology doesn't call top.setBox.

I saw that FrameSpecsT.cell is most likely the simulation cell or is it in 
FullCellT? Anyhow DLPOLYTopologyReader::ReadTopology don't initialize 
FrameBase, which is of type FrameSpecsT.

A bit of documentation in dlpoly/dlp_io_layer.h would be helpful!

Original issue reported on code.google.com by christop...@gmail.com on 7 Nov 2013 at 10:13

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

This issue was closed by revision 089965f6486e.

Original comment by jungh...@votca.org on 8 Nov 2013 at 12:10

• Changed state: Fixed