dlpoly topology reader (c++ part) reports wrong atom types

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Get http://www.ccp5.ac.uk/DL_POLY/TUTORIAL/EXERCISES/TEST9.tar.gz
2. Run csg_dump --top .dlpoly

I have 905 beads in 361 molecules
Boundary Condition: triclinic
 Box matix: 50 0 0
            0 24.0175 -9.60696
            0 0 24.1645

List of molecules:
molecule: 1 Ca beads: 1
0 Name 1:no:Ca Type Ca Mass 40
molecule: 2 Ca beads: 1
1 Name 1:no:Ca Type Ca Mass 40
...
molecule: 361 macid beads: 5
900 Name 1:no:Ca Type Ca Mass 40
901 Name 1:no:Ca Type Ca Mass 40
902 Name 1:no:Ca Type Ca Mass 40

All atoms have type Ca, which seems to be wrong!

Another question, how is FieldSite[is].type determined from FieldSite[is].name? 
The 1st column in the ATOMS section of the FIELD file, is the sitename not the 
type, right? How does one get the type? By removing _[1-9] at the end?

On a side note, bead names like "1:no:Ca" are pretty useless to create a 
mapping. I would suggest something like 1:no:Ca1, 1:no:Ca2, etc.

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed title: dlpoly topology reader (c++ part) reports wrong atom types

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

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

• Changed state: Reopened

[GoogleCodeExporter]

This issue was closed by revision c25aa4b4e852.

Original comment by jungh...@votca.org on 12 Nov 2013 at 4:04

• Changed state: Fixed

[GoogleCodeExporter]

This issue was updated by revision f1607c43b06f.

Original comment by christop...@gmail.com on 17 Nov 2013 at 8:15