Closed GoogleCodeExporter closed 8 years ago
Adding a quote from my comment on the closed issue #142:
<<<
As for naming used by DL_POLY, it is in fact different from Gromacs, and I
mentioned it before. The atom names in DL_POLY formats are not unique, and the
proper distinction between unique atoms is only done by their indices. This is
not my invention and I won't defend it, but it has its advantages too. So,
DL_POLY's atom names are actually equivalent to Gromacs' atom types.
There is an ad-hoc way do have unique names for atoms within a molecular type
(a molecule instance in FIELD; these names would be the last column within the
"atoms" specs in FIELD), but I am not sure if it is any sort of standard, most
likely not (it's not imposed by the internal readers, nor by the manual).
>>>
Also, note that I sent Victor the manual for my DL_CGMAP tool that solves the
problem by allowing atom indices added to their names with a preceding hash
symbol:
1:no:Ca#1 1:no:Ca#2
or
1:no:Ca#* (in the case all the atoms in a molecule have the same name)
One can even skip the atom names altogether and only specify their indices
within a molecule or residue (when ResID/="*" in the latter case).
Original comment by abruk...@googlemail.com
on 11 Nov 2013 at 9:47
I see, so the problem is in the c++ part. Can you send me the DL_CGMAP manual,
so that we can implement it in the same way!
Original comment by christop...@gmail.com
on 11 Nov 2013 at 10:23
Fixed in:
<https://code.google.com/p/votca/source/detail?r=f4fc9553d8cfd454012753d20c8e8c4
70454837e&repo=csg>
Original comment by christop...@gmail.com
on 12 Nov 2013 at 3:32
Actually I have to reopen this as there is still a bug when using the fortran
interface.
If I use the pure c++ fail back implementation for TEST9 it works:
$ csg_dump --top .dlpoly | tail
molecule: 361 macid beads: 5
900 Name 1:no:C_2#1 Type C_2 Mass 12.01
901 Name 1:no:O_2#1 Type O_2 Mass 16
902 Name 1:no:O_3#1 Type O_3 Mass 16
903 Name 1:no:H_1#1 Type H_1 Mass 1.008
904 Name 1:no:H_2#1 Type H_2 Mass 1.008
However, when using the fortran interface (cmake -DWITH_DLPOLY_FORTRAN=ON):
$ csg_dump --top .dlpoly | tail
molecule: 361 macid beads: 5
900 Name 1:no:Ca#1 Type Ca Mass 40
901 Name 1:no:Ca#2 Type Ca Mass 40
902 Name 1:no:Ca#3 Type Ca Mass 40
903 Name 1:no:Ca#4 Type Ca Mass 40
904 Name 1:no:Ca#5 Type Ca Mass 40
So basically the type, which comes from FieldSite[is].type, but is is always 0.
This seems Victor has screwed something up in:
<https://code.google.com/p/votca/source/detail?r=db04f473320b514f11d821f9ca6252d
4f0c9253f&repo=csg>
Original comment by christop...@gmail.com
on 12 Nov 2013 at 3:52
This issue was closed by revision c25aa4b4e852.
Original comment by jungh...@votca.org
on 12 Nov 2013 at 4:04
This issue was updated by revision f1607c43b06f.
Original comment by christop...@gmail.com
on 17 Nov 2013 at 8:15
Original issue reported on code.google.com by
christop...@gmail.com
on 11 Nov 2013 at 7:36