Bug #2923

Multidir AWH simulations require the same box sizes

Added by Semen Yesylevskyy over 1 year ago. Updated over 1 year ago.

Target version:
Affected version - extra info:
Affected version:


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.

Associated revisions

Revision 793d6266 (diff)
Added by Berk Hess over 1 year ago

Disallow pull geometry direction-periodic with AWH

Fixes #2923

Change-Id: Ic309a5598c69e82824d80270466a2de7b00e7d41


#1 Updated by Berk Hess over 1 year ago

This is an error on the AWH grids not matching. Obviously these should match to be able to share.
I don't know what causes your grids to be different over the different simulation systems.

#2 Updated by Semen Yesylevskyy over 1 year 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?

#3 Updated by Berk Hess over 1 year ago

What is your reaction coordinate?

#4 Updated by Semen Yesylevskyy over 1 year 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

#5 Updated by Berk Hess over 1 year ago

I think this might be because you are using direction-periodic, which you should not use and should not want to use anyhow. Use direction instead.

I think we should disallow using direction-periodic with AWH.

#6 Updated by Berk Hess over 1 year ago

Could you do one test?
Please change line 616 of src/gromacs/awh/read_params.cpp from
period = static_cast<double>(norm(box[m_pullvec]));
period = 0;

And check if that fixes the issue?

#7 Updated by Semen Yesylevskyy over 1 year 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?

#8 Updated by Berk Hess over 1 year ago

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 over 1 year 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.

#10 Updated by Berk Hess over 1 year ago

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.

#11 Updated by Berk Hess over 1 year ago

  • 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.

#12 Updated by Berk Hess over 1 year ago

  • Status changed from Fix uploaded to Resolved

#13 Updated by Mark Abraham over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF