AMBER with truncated octahedron box

[vi...@klingon.uab.es]

Dear developers,

I am experiencing a problem with the calculation of the COORDINATION collective variable using PLUMED (I tried versions 2.5 and 2.6) with AMBER both sander and pmemd (I tried amber18 and amber20). When using a truncated octahedron box, the coordination number is not properly computed, while it is for a cubic box. Seems PBC are not properly applied to a truncated octahedron cell. Does PLUMED support truncated octahedron boxes with AMBER? Or is there a keyword I should activate in this case?

Thank you for your attention.

Best regards,

pietro

[Giovanni Bussi]

Hi,

this is supposed to be supported. To be more specific:

- PLUMED supports any possible lattice, and requires the lattice vectors to be passed correctly.

- Since AMBER internally uses specific flags to store the type of lattice, there is some code that does the translation, and is included in AMBER (see e.g. here: https://github.com/plumed/plumed2/blob/v2.6/patches/amber18.diff#L317-L330).

You can double check that this is done correctly by printing the box:

cell: CELL

PRINT ARG=cell.*

If you confirm that this is not done correctly, we should probably fix something in the lines above (for PMEMD) and in the equivalent part of SANDER. In case, can you provide a simplified example?

Thanks!

Giovanni

--
You received this message because you are subscribed to the Google Groups "PLUMED users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/b666ecbd-0e4c-4457-80b7-4d2b6f05a639o%40googlegroups.com.

[vi...@klingon.uab.es]

Dear Giovanni,

thank you for the kind reply. I did what you suggested, and the cell vector seems to be correct. However, the COORDINATION collective variable is not properly computed. Actually, rebuilding the simulation cell with WRAPAROUND does not produce a proper model in the case of a truncated octahedron (all is fine with a cubic box). I prepared a simple test case: a box of water molecules, for which to compute the coordination number of oxygen #1. Please find in attachment all files required to run the test with AMBER (I provide two coordinates sets, one with molecules diffused out of the cell, another with all molecules in the cell, they provide different results):

wat.top -> topology file

last.rst -> coordinates with water molecules diffused out of the cell

last_wrap.rst -> coordinates with water molecules in the cell

md.in -> pmemd configuration file

plumed.dat -> plumed configuration file

job -> the command to run the calculation

Thank you for your time.

Best,

 pietro

El lunes, 15 de junio de 2020, 10:10:34 (UTC+2), Giovanni Bussi escribió:

Hi,

this is supposed to be supported. To be more specific:

- PLUMED supports any possible lattice, and requires the lattice vectors to be passed correctly.

- Since AMBER internally uses specific flags to store the type of lattice, there is some code that does the translation, and is included in AMBER (see e.g. here: https://github.com/plumed/plumed2/blob/v2.6/patches/amber18.diff#L317-L330).

You can double check that this is done correctly by printing the box:

cell: CELL

PRINT ARG=cell.*

If you confirm that this is not done correctly, we should probably fix something in the lines above (for PMEMD) and in the equivalent part of SANDER. In case, can you provide a simplified example?

Thanks!

Giovanni

On Sat, Jun 13, 2020 at 2:23 PM <vi...@klingon.uab.es> wrote:

Dear developers,

I am experiencing a problem with the calculation of the COORDINATION collective variable using PLUMED (I tried versions 2.5 and 2.6) with AMBER both sander and pmemd (I tried amber18 and amber20). When using a truncated octahedron box, the coordination number is not properly computed, while it is for a cubic box. Seems PBC are not properly applied to a truncated octahedron cell. Does PLUMED support truncated octahedron boxes with AMBER? Or is there a keyword I should activate in this case?

Thank you for your attention.

Best regards,

pietro

--
You received this message because you are subscribed to the Google Groups "PLUMED users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to plumed...@googlegroups.com.

[vi...@klingon.uab.es]

Dear Giovanni,

 I used the toy model of my previous email to run CP2K+PLUMED. The cell vectors computed by CP2K are different from the ones computed by the PLUMED patch for AMBER pmemd.

This are the cell vectors available to PLUMED when used with CP2K:

 #! FIELDS time cell.ax cell.ay cell.az cell.bx cell.by cell.bz cell.cx cell.cy cell.cz
 0.001000 25.783729 0.000000 0.000000 -8.594576 24.309133 0.000000 -8.594576 -12.154565 21.052328

While these are those available to PLUMED when used with AMBER pmemd:

#! FIELDS time cell.ax cell.ay cell.az cell.bx cell.by cell.bz cell.cx cell.cy cell.cz
 0.000000 14.886243 14.886243 14.886243 -14.886243 -14.886243 14.886243 14.886243 -14.886243 -14.886243

Best regards,

 pietro

[Giovanni Bussi]

I see. That means that AMBER uses a matrix of lattice vector that triangular: first vector along x axis and second vector in xy plane.

I am pretty sure I used AMBER+PLUMED very very long ago and the PBCs were passed correctly. It is possible that the internal AMBER conversion changed at some point? Maybe you  can ask on the AMBER mailing list if this is the case?

The fix should be relatively easy. You can change these lines:

+      plumed_box(1,1) = sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(2,1) = sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(3,1) = sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(1,2) = -sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(2,2) = -sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(3,2) = sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(1,3) = sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(2,3) = -sqrt(1.0/3.0)*pbc_box(1)
+      plumed_box(3,3) = -sqrt(1.0/3.0)*pbc_box(1)

to

+      plumed_box(1,1) = pbc_box(1)
+      plumed_box(2,1) = 0.0
+      plumed_box(3,1) = 0.0
+      plumed_box(1,2) = -pbc_box(1)/3.0
+      plumed_box(2,2) = sqrt(8.0/9.0)*pbc_box(1)
+      plumed_box(3,2) = 0.0
+      plumed_box(1,3) = -pbc_box(1)/3.0
+      plumed_box(2,3) = -sqrt(2.0/9.0)*pbc_box(1)
+      plumed_box(3,3) = sqrt(2.0/3.0)*pbc_box(1)

PLEASE DOUBLE CHECK THE MATH!!!

If this works, I think we should fix it (both in our patch and in the official AMBER code, since the patch is now included in AMBER).

Thanks a lot!

Giovanni

To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/702cd33c-46dc-4f23-934b-a9ec30866ab1o%40googlegroups.com.

[vi...@klingon.uab.es]

Dear Giovanni,

 

 I confirm that with these vectors things work properly. Many thanks for your help. I will write to the AMBER mailing list and let you know.

Thanks again!

Best regards,

 pietro

To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/702cd33c-46dc-4f23-934b-a9ec30866ab1o%40googlegroups.com.

[Giovanni Bussi]

OK I move this to GitHub: https://github.com/plumed/plumed2/issues/584

Thanks!!

Giovanni

To unsubscribe from this group and stop receiving emails from it, send an email to plumed-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/plumed-users/f1524b82-99ee-41bc-9ed3-686b17339140o%40googlegroups.com.