Closed GoogleCodeExporter closed 8 years ago
Hi Christoph,
From what you sent I appreciate that something goes wrong if one runs a
dev-version (1.3) of Votca with binding to dlpoly in the case of spce water
model. In particular, the field file reader seems to return a wrong number
of molecules in FIELD.
I also see that I am resposible for solving the issue, which is fine.
However, I need to be introduced into the workflow of your dev-branch and
such.
Could you please provide me with either brief instructions as to how one
should deal with such issues, or a link to where this sort of info can be
found.
Great to see the work is going on!
Original comment by abruk...@googlemail.com
on 24 Oct 2013 at 6:08
Hi Guys,
Please fix your CONFIG file here:
http://code.google.com/p/votca/source/browse/spce/ibi_dlpoly/CONFIG?spec=svn.csg
-tutorials.4c345fbf25352c3720d68cea41f9d642f99769da&repo=csg-tutorials&r=4c345fb
f25352c3720d68cea41f9d642f99769da
Note that the second line must contain at least three (int) numbers, the last
figure
being the total number of atoms (sites or beads) in the entire system.
Hope it helps.
Andrey
Original comment by abruk...@googlemail.com
on 25 Oct 2013 at 10:23
This issue was updated by revision 35457f2d6015.
Original comment by jungh...@votca.org
on 25 Oct 2013 at 4:21
Adding the number of molecules in CONFIG didn't help, but in the meanwhile I
fixed the segfault in xyzreader.c. This was a missing throw, now is stops with
an error:
$ csg_stat --options ../settings.xml --top .dlpoly --trj traj.xyz
begin to calculate distribution functions
# of bonded interactions: 0
# of non-bonded interactions: 1
field_scan(1/2): (re)allocating memory - SUCCESS!
I have 1 beads in 1 molecules
an error occurred:
number of beads in topology and trajectory differ
Original comment by christop...@gmail.com
on 25 Oct 2013 at 4:23
... please, make sure you're using the numbers from FIELD correctly,
as described below:
-------
# of molecular types = nmolt as returned to the C-side (the F-reader reads only
"molec" as a keyword)
MOLECULES 1
...
# of molecules of the latest (current) molecular type = MolecBase[im].nrept (or
MolecSpecsT->nrept)
NUMMOLS 2180
-------
The total number of molecules and atoms (or beads, returned as matoms) can be
calculated by summing up,
correspondingly, MolecBase[im].nrept and MolecBase[im].nsites while doing
for(im=0; im<nmolt; im++)
Original comment by abruk...@googlemail.com
on 25 Oct 2013 at 6:40
Guys, please remove it from bugs/issues, cause it is not...
it is a small thing that needs to be properly coded.
Will get to it tomorrow.
Thanks
Original comment by abruk...@googlemail.com
on 4 Nov 2013 at 6:55
i think it is fixed now, please verify
Original comment by victor.r...@gmail.com
on 7 Nov 2013 at 9:13
step_001 $ csg_stat --options ../settings.xml --top .dlpoly --trj traj.xyz
begin to calculate distribution functions
# of bonded interactions: 0
# of non-bonded interactions: 1
field_scan(1/2): (re)allocating memory - SUCCESS!
I have 2180 beads in 2180 molecules
NOTE: You are using OpenBox boundary conditions. Check if this is intended.
written CG-CG.dist.new
The number of molecules is now correct, but the boundary conditions are still
work, which leads to the wrong rdf, which is a separate issue.
One can use the following workaround for now:
$ cat topol.xml
<topology base=".dlpoly">
<box xx="40.3100" yy="40.3100" zz="40.3100"/>
</topology>
And the reported residuum are still work, too, which is a separate issue as
well.
Original comment by christop...@gmail.com
on 7 Nov 2013 at 5:14
Great to know!
NOTE: You are using OpenBox boundary conditions. Check if this is intended.
- 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.
- I do not understand this remark...
Original comment by abruk...@googlemail.com
on 7 Nov 2013 at 8:46
Let's stay on topic here, these are separate issues!
See issue #141 for the boundary condition issue and issue #142 for the residuum
naming issue.
Original comment by christop...@gmail.com
on 7 Nov 2013 at 10:20
Original issue reported on code.google.com by
christop...@gmail.com
on 24 Oct 2013 at 5:47