Rhombic Dodecahedron Box

[jacekkozuch]

Hi,

I just wanted to ask how to go about building a dodecahedral box for protein MD in Tinker. Somehow the option within xyzedit is not doing anything to my water or protein + water boxes.
Or do I just build my box as if it was cubic but keep the DODECAHEDRON keyword in the key file and the MD simulations will adapt the new PBC conditions?

Thanks and a happy new year.
Best,
Jacek

[zhi-wang]

Hi, I will forward your question to Prof. @jayponder. He is the author of this feature in the Fortran codebase. From my recollection, the shape of the box will not actually change for rhombic dodecahedron and octahedron boxes like you speculated. I may be wrong though.

I have not implemented the rhombic dodecahedron box in the GPU code yet because we are not convinced that it will indeed save a lot of running time compared to its overhead in PBC. Prof. @jayponder did some benchmarking in the past and he may comment here too.

[jacekkozuch]

Hi Zhi,

thanks for the response. If it's not implemented into the GPU code yet (and maybe not be in the end) then there's no need to contact Prof. Ponder. I hoped to be able to make my MD runs a bit more efficient by using the dodecahedron box, but if that's not the case, I'll just use the standard cubic.

Thanks!
Jacek

[jayponder]

Hi Jacek, Sorry for the slow reply. This was, in fact, a typo in XYZEDIT such that the program was skipping the conversion to rhombic dodecahedron and truncated octahedron. I've just pushed a fix for this to the Tinker code on Github.

To use either of the non-prism cell types, you should do what you were probably already trying... Start with a cubic box, and then run XYZEDIT using option 20 or 21. This will write out a new .xyz file with the cubic box trimmed to the corresponding rhombic dodecahedron or truncated octahedron. For the rhombic dodecahedron, the box size will also get modifed automatically. Note that after running XYZEDIT, you will need to manually add either the DODECAHEDRON or the OCTAHEDRON keyword to your keyfile before running any calculations. Also, these conversions are not "perfect", so you will need to minimize your box to remove new bad contacts introduced by the conversion, and perhaps add or subtract some solvent molecules (or change the box dimensions) to get your desired density.

Finally, as Zhi says above, I think neither of these cell types are currently implemented in Tinker 9. We have run several tests with CPU versions of Tinker, and the time savings with these non-prism box types is small at best. There are two reasons for this behavior: (1) since what you want to maintain is the closest contact between atoms in two distinct solute/protein molecules, you actually need to start from a larger original cubic box, and (2) the periodic boundary and minimum image calculations for these cells are more complex than for prisms, and this largely removes any speed advantage due to the smaller number of atoms.

[jacekkozuch]

Dear Jay,

thank you for your response, the explanation and the correction of the code.

Regarding:

and (2) the periodic boundary and minimum image calculations for these cells are more complex that for prisms and this largely removes any speed advantage due to the smaller number of atoms.

Is this true for AMOEBA MD or is this a general observation in MD? I always used rhombic boxes in fixed-charge MD, since I learned about the efficiency due to less atoms.

[jayponder]

My argument about time savings is general and has nothing to do with AMOEBA. As I noted above, you have to use a “bigger” rhombic dodecahedron dimension (or truncated octahedron) than cube dimension in order to get the same minimum distance between solute atoms. After accounting for this, the savings in total volume or in total number of atoms when using the rhombic dodecahedron is about 30% compared to using a cube. The periodic box and minimum image calculation for a cube is trivial, and just involves adding or subtracting multiples of the cube dimension along the x-, y- and z-axes. For the rhombic dodecahedron, there are square roots that must be taken, additional logic, and additional algebra. This is just the nature of the “geometry” and is independent of the specific force field model. In our hands, at least on CPUs, the time savings using the rhombic dodecahedron is small to zero.

[jacekkozuch]

I was not aware that the PBC algorithm can take up so much resources in the rhombic dodecahedron case.
Thank you for the clarification!