Add OpenMM module

[joaomcteixeira]

The code presented in this commit was entirely done by Ivar de Leeuw during his Master course: Major Research Project (GSLS), academic year 2021-2022.

I am pushing the code after Ivar's request and in its exact original form.

In the next commits, the team will work on Ivar's code to accommodate it fully to the HADDOCK3 project.

Thanks, Ivar, for all your great work and best luck with your future studies!

[joaomcteixeira]

Made a general linting around files. Addition lint can still be done on function and variable names.

[mgiulini]

Hi @joaomcteixeira, just had a quick chat with Ivar De Leeuw about the version of the dependencies he used: it's openmm v. 7.7.0 and pdbfixer 1.8.1. I'll modify the INSTALL.md accordingly

[joaomcteixeira]

Okay. I strongly suggest having them defined as optional dependencies, same as lightdock and gdock.

[mgiulini]

Okay. I strongly suggest having them defined as optional dependencies, same as lightdock and gdock.

I totally agree.

[mgiulini]

tried a run with the example file openmm-test.cfg and commit ID #c79f47a. It's already a great work. A few "style" improvements from my user experience:

• we should clarify if the simulation uses implicit or explicit solvent at the beginning
• we should report the difference between equilibration and the actual simulation
• the logging during the actual simulation should be more frequent to allow the user to track the progress, we should inspect a bit the core openmm functions
• we could split the function runOpenMM in two or more pieces for enhancing the readability
• a warning appeared Warning: importing 'simtk.openmm' is deprecated. Import 'openmm' instead. probably we can safely ignore it, but I still have to check
• the integrator seed should be added as a user-defined parameter and printed during the execution, so that we could obtain (almost) identical calculations

[joaomcteixeira]

a warning appeared Warning: importing 'simtk.openmm' is deprecated. Import 'openmm' instead. probably we can safely ignore it, but I still have to check

I would say this is not ours and is something from openmm because we don't import from simtk. not in the original Ivar's code nor in the linted one.

[joaomcteixeira]

@mgiulini, the pre-last commit solves the globals() problem. It was not necessary because the value was the same as the key, so we can simply avoid calling the globals() dictionary.

Also corrected some defaults that were lists to single strings

[mgiulini]

As for the reproducibility: it is possible to assign a seed to the integrators, but not to the modeller functions. Therefore, the solvation boxes specified at the beginning of the simulations are bound to differ.

[amjjbonvin]

Aren’t the solvation boxes built from a pre-equilibrated water box?

[joaomcteixeira]

This is so beautiful!

[mgiulini]

Aren’t the solvation boxes built from a pre-equilibrated water box?

Hi Alex, the solvation box in openmm is built by default using the TIP3P solvent model, which should be already equilibrated. But the solute-solvent interface mixture is not equilibrated at all, as the water molecules are simply removed in correspondence of the solute.

[amjjbonvin]

That’s standard procedure. The first equilibration step should be to minimise the solvent with the solute position restrainted, and then heat up the system slowly releasing the solute so that the solvent adapts to the solute (and not vice-versa)

[mgiulini]

That’s standard procedure. The first equilibration step should be to minimise the solvent with the solute position restrainted, and then heat up the system slowly releasing the solute so that the solvent adapts to the solute (and not vice-versa)

Precisely! Following Ivar's code, I didn't include the full procedure in the current implementation to save resources. The system is built, energy-minimized, and then quickly "equilibrated" at the simulation temperature (300 K) for a few steps. Should I include the full equilibration protocol?

[amjjbonvin]

Precisely! Following Ivar's code, I didn't include the full procedure in the current implementation to save resources. The system is built, energy-minimized, and then quickly "equilibrated" at the simulation temperature (300 K) for a few steps. Should I include the full equilibration protocol?

I guess this should be checked at least. In principle starting directly at 300K is fine as long as there are positions restraints on the solute that are slowly removed.

[mgiulini]

Precisely! Following Ivar's code, I didn't include the full procedure in the current implementation to save resources. The system is built, energy-minimized, and then quickly "equilibrated" at the simulation temperature (300 K) for a few steps. Should I include the full equilibration protocol?
I guess this should be checked at least. In principle starting directly at 300K is fine as long as there are positions restraints on the solute that are slowly removed.

I will investigate the code more thoroughly then :)

[VGPReys]

resolve #776