-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Coordinates from GROMACS vacuum simulations can cause overflow as input to AMBER #86
Comments
After a single step the coordinates are completely sensible. Perhaps the vacuum box origin is at (0, 0, 0) so that we need to translate the molecule to the middle, then back again at the end. This is what I need to do for solvation too. In [1]: import BioSimSpace as BSS
INFO:numexpr.utils:Note: NumExpr detected 20 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8.
INFO:numexpr.utils:NumExpr defaulting to 8 threads.
WARNING:root:Warning: importing 'simtk.openmm' is deprecated. Import 'openmm' instead.
In [2]: m = BSS.Parameters.openff_unconstrained_2_0_0("CC").getMolecule()
In [3]: p = BSS.Protocol.Minimisation(steps=1)
In [4]: process = BSS.Process.Gromacs(m.toSystem(), p)
/home/lester/Code/openbiosim/biosimspace/python/BioSimSpace/Process/_gromacs.py:294: UserWarning: No simulation box found. Assuming gas phase simulation.
_warnings.warn("No simulation box found. Assuming gas phase simulation.")
/home/lester/Code/openbiosim/biosimspace/python/BioSimSpace/_Config/_config.py:96: UserWarning: No simulation box found. Assuming gas phase simulation.
_warnings.warn("No simulation box found. Assuming gas phase simulation.")
In [5]: process.start()
Out[5]: BioSimSpace.Process.Gromacs(<BioSimSpace.System: nMolecules=1>, BioSimSpace.Protocol.Minimisation(steps=1, restraint=None, force_constant=10.0 kcal_per_mol/angstrom**2), exe='/home/lester/.conda/envs/openbiosim/bin.AVX2_256/gmx', name='gromacs', work_dir='/tmp/tmpoiefdyqf', seed=None)
In [6]: process.wait()
In [7]: s = process.getSystem()
In [8]: s[0].coordinates()
Out[8]:
[(-0.7500 A, 0.0400 A, 0.0100 A),
(0.7500 A, 0.0000e+00 A, 0.0000e+00 A),
(-1.1300 A, -0.6400 A, 0.8100 A),
(-1.1800 A, 1.0300 A, 0.2000 A),
(-1.2000 A, -0.3300 A, -0.9400 A),
(1.0800 A, -0.7400 A, -0.7700 A),
(1.2300 A, 0.9600 A, -0.2700 A),
(1.2000 A, -0.3200 A, 0.9500 A)] |
No, shouldn't be needed since you can see that negative coordinates are present above. I guess it's just wandered off a long way! Looks like it goes bonkers after about 50 steps. |
annoying...maybe the hydration free energy tests can all use OpenMM as engine for equilibration for the time being? |
Yes, I'd suggest using OpenMM for vacuum minimisation/equilibration for now. |
For GROMACS we implement vacuum simulations by using pseudo-PBC conditions, i.e. running calculations in a near infinite box, as described here. (This approach works with all versions of GROMACS that we support.) However, a result of this is that absolute molecular coordinates can end up being really large, so can't be used as input to other engines, e.g. AMBER, since they overflow the formatting restrictions of the input file. For example:
I'm confused why this is happening since the molecule should be placed at the centre of the box, but perhaps this isn't working correctly. For a minimisation it should be easy enough to translate it back to some reasonable place afterwards, but maybe not for other protocols where a user might want a trajectory.
The text was updated successfully, but these errors were encountered: