Multidir AWH simulations require the same box sizes
I'm not sure if this is a bug or a requirement of the AWH code but it seems to be not logical. If one do AWH simulations with shared bias and -multidir option it is natural to use several systems with different initial values of reaction coordinate to speed up convergence. Typically such systems are generated by placing the ligand in different distances of pulling it through the reaction coordinate in auxiliary simulation prior to AWH run. It is natural that such initial systems would have different box sized if generated from NPT simulation.
However, if different tpr files in multidir setup have different box sized the error is emitted:
Error in user input:
Shared AWH bias 1 has different grid sizes in different simulations
This error appears even if the reaction coordinate does not span the whole box. In the course of AWH run different simulations proceed normally in NPT ensemble which means that different box sized are well tolerated in fact.
This seems to be a bug or at lest an unexpected behavior.
#2 Updated by Semen Yesylevskyy 10 months ago
This is also a mystery for me. The systems were produced by saving frames from preliminary pulling simulation and it only works if I do it in NVT, not NPT. The difference in box size is really minor - not more than 1A.
Is it possible to add a kind of flag to tell that the grid should be computed for the first tpr and used for all the rest?
#4 Updated by Semen Yesylevskyy 10 months ago
Here is how pulling section looks like in my mdp file. This is a 2D profile with 1st coordinate - position of ligand in the membrane along Z and the 2nd - distance between two ends of the ligand.
pull = yes
pull-nstxout = 1000
pull-nstfout = 1000
pull-ngroups = 3
pull-ncoords = 2
pull-group1-name = membr
pull-group2-name = GEM
pull-group3-name = SQ
pull-coord1-groups = 1 3
pull-coord1-geometry = direction-periodic
pull-coord1-vec = 0 0 1
pull-coord1-type = external-potential
pull-coord1-potential-provider = awh
pull-coord1-dim = N N Y
pull-coord2-groups = 2 3
pull-coord2-geometry = distance
pull-coord2-type = external-potential
pull-coord2-potential-provider = awh
pull-coord2-dim = Y Y Y
awh = yes
awh-nstout = 500000
awh-nbias = 1
awh1-ndim = 2
awh1-dim1-coord-index = 1
awh1-dim1-start = -3.5
awh1-dim1-end = 3.5
awh1-dim1-force-constant = 100000
awh1-dim1-diffusion = 5e-5
awh1-dim2-coord-index = 2
awh1-dim2-start = 0.25
awh1-dim2-end = 1.9
awh1-dim2-force-constant = 100000
awh1-dim2-diffusion = 5e-5
awh-share-multisim = yes
awh1-share-group = 1
#7 Updated by Semen Yesylevskyy 10 months ago
Unfortunately I can't recompile Gromacs on the cluster, so I can't test this.
Concerning direction-periodic: what should I do if my reaction coordinate spans more than 1/2 of the box size? In "normal" pulling usage this an indication for direction-periodic. Will direction work correctly for awh in this case?
You can test on your workstation or laptop. Running 0 steps is sufficient
Spanning more than half the box is not a problem per se. The distance from the reference should not be more than half the box for other geometries, but can be up to half the box in both directions.
Distance-periodic gives a non-periodic distance (maybe the name is confusing). We could make this work with AWH, but then the total AWH range should be smaller than the full box size.
#9 Updated by Semen Yesylevskyy 10 months ago
I confirm that the problem is due to direction-periodic. If changed to direction it works as intended with different box dimensions. I guess that the best idea is probably to issue a warning in the case of using direction-periodic with awh (or may be even an error). It is really confusing for the user to get this "different grid size" error.
Sure, a user should not get that error.
The question is whether to disallow direction-periodic (with a clear message) or to allow it when the range is less than the box size. But then we need to be 100% that no bugs can occur. I'll think a bit more to see if this is safe.
- Status changed from New to Fix uploaded
- Assignee set to Berk Hess
- Target version set to 2019.2
I think the utility of allowing direction-periodic does not way against the complexity of the checks, so I uploaded a "fix" to disallow this. It prints a hint to use direction instead.