Incorrect box info after mapping a Gromacs dodecahedron box

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Use csg_map to map a dodecahedron Gromacs box (gro or xtc)

$ csg_map --top topol.tpr --trj conf.gro --out mapped.gro --cg SOL.xml
OR
$ csg_map --top topol.tpr --trj conf.gro --out mapped.xtc --cg SOL.xml

where the last line of conf.gro is:
4.00000   4.00000   2.82843   0.00000   0.00000   0.00000   0.00000   2.00000   
2.00000

the last line of mapped.gro is:
4.00000   4.00000   2.82843   0.00000   2.00000   0.00000   2.00000   0.00000   
0.00000

2. The box info for conf.gro and mapped.gro differ

The box info for conf.gro and mapped.gro should be the same.

I think changing the 96-97th lines of src/libcsg/modules/io/growriter.cc :
from
            box[0][1],box[0][2],box[1][0],
            box[1][2],box[2][0],box[2][1]);
to
            box[1][0],box[2][0],box[0][1],
            box[2][1],box[0][2],box[1][2]);

and 64th line of src/libcsg/modules/io/gmxtrajectorywriter.cc :
from
frame.box[i][j] = box[i][j];

to
frame.box[j][i] = box[i][j];

fixes this bug. I didn't commit the fix, because I am not sure if this fix does 
not break anything.

Original issue reported on code.google.com by cahit.dalgicdir on 4 Dec 2013 at 9:50

Attachments:

• votca-gmx-dode-map-bug.tar

[GoogleCodeExporter]

Ok, have you tested your changes for the other two boundary conditions? 
(Triclinic, Open)

And what does the newest version of csg_dump says, which boundary condition it 
has found?  

Original comment by christop...@gmail.com on 4 Dec 2013 at 7:25

• Changed state: Accepted

[GoogleCodeExporter]

I tried with, rectangular, cubic, dodecahedron, octahedron and open box types:

The mapped configurations of rectangular and cubic box types give the same box 
vectors as those of the atomistic configurations both before fix and after fix. 
(expected as the diagonal elements of the matrix do not change)

However, the box vectors of the mapped configurations for dodecahedron and 
octahedron box types match to their atomistic counterparts, after fix but fail 
to match before fix.

Also, the lines match with the open box (where all the box vectors equal zero).

The latest csg_dump yields for all the box types above and for both cases of 
before fix and after fix (except the open box, where I don't know how to 
compile a box with zero vectors with grompp and generate a tpr file):
Boundary Condition: open

That shouldn't be right, I guess.

However, when I use csg_map to map the atomistic configuration, the correct box 
types (orthorhombic, triclinic etc) seem to be assigned. (I uncommented the 
cout lines in topology.cc (Topology::autoDetectBoxType, line 313).

So anything else, I should check?

Original comment by cahit.dalgicdir on 5 Dec 2013 at 11:07

[GoogleCodeExporter]

Sounds good to me, thanks for testing! Do you want to commit it yourself or do 
you want to send me a patch?

Original comment by christop...@gmail.com on 5 Dec 2013 at 6:34

[GoogleCodeExporter]

OK, I did the commit. Thanks.

Original comment by cahit.dalgicdir on 6 Dec 2013 at 3:25

[GoogleCodeExporter]

Thanks!

Btw, please add the following block to your ~/.hgrc
[ui]
username = Steve Losh <steve@stevelosh.com>

Original comment by christop...@gmail.com on 6 Dec 2013 at 4:41

• Changed state: Fixed

[GoogleCodeExporter]

With your name and email of course...

Original comment by christop...@gmail.com on 6 Dec 2013 at 7:02

[GoogleCodeExporter]

:) Sorry, fixed it now. Actually the block was there, but the name was not 
typed correctly.

Original comment by cahit.dalgicdir on 6 Dec 2013 at 8:00

[GoogleCodeExporter]

this is a quite critical fix, so I reopened this issue for an additional check.

Could you please verify if csg_stat still produces the exact same rdf as g_rdf. 
The following reason: The distance function relies on the fact that the box 
matrix is upper triangular (or lower, don't remember which way), otherwise the 
distances are wrong. I thought the distances were correct for a triclinic box, 
but now the matrix is transposed. So it could be also that the writer is wrong 
instead of the reader...

See also issue #125

Victor

Original comment by victor.r...@gmail.com on 8 Dec 2013 at 10:53

• Changed state: Reopened

[GoogleCodeExporter]

sorry, I was not reading properly, i thought you were changing the reader.

closed again

Original comment by victor.r...@gmail.com on 8 Dec 2013 at 10:56

• Changed state: Fixed

[GoogleCodeExporter]

I back-ported this fix to the 1.2 branch!

Original comment by christop...@gmail.com on 13 Jul 2015 at 2:34