Update packmol-related functionality to allow use of non-GAFF water

[davidlmobley]

Currently, tools here can build general mixtures essentially any set of organic molecules fairly effectively as long as you are content with GAFF versions of those molecules. Separate tools (on the GROMACS side) can solvate arbitrary solutes in typical water models. However, we currently cannot handle the scenario where you might want to simulate arbitrary solutes in a mixture of water (modeled via a traditional water model) and some other solvent. We only support: a) solutes solvated in GAFF solvents such as flexible GAFF-water b) solutes solvated in pure water

I want to change this. My proposal at this point is to:

• Modify openmoltools.amber.build_mixture_prmtop to add an optional (1) argument, watermodel, which would specify what water model will be used IF water is a component of the mixture
• Modify openmoltools.packmol.pack_box to add an optional (1) argument, watermodel, which wiould specify what water model will be used IF water is a component of the mixture

(1) optional: I propose to make these optional for API stability (i.e. so someone expecting GAFF-water, i.e. @kyleabeauchamp , doesn't suddenly find themselves with TIP3P instead)

The modification to openmoltools.packmol.pack_box will, I think, only be needed for non-three-point water models, since in that case we need to have packmol use a different number of points when generating the box in the first place. But for three-point waters it is sufficient, I believe, to simply swap the parameters used.

Currently I'm planning on implementing the first of these by simply changing what arguments are provided to tleap. It could also be achieved by reading the finished system into parmed, splitting, and swapping out the water parameters. Though this solution is more general (i.e. it could be used to swap parameters for other molecules as well) I don't see an obvious use case for it and it seems more logical to just use the desired water model in the first place. So that's the approach I'll use unless there are any objections.

If there are no objections I'll likely do this next week.

[kyleabeauchamp]

I am fine with api instability as long as you still give me a way to do what I was doing in my density paper. E.g if you think tip3p should be default, that's fine as long as I have an optional way to do gaff. On Jun 19, 2015 3:15 PM, "David L. Mobley" notifications@github.com wrote:

Currently, tools here can build general mixtures essentially any set of organic molecules fairly effectively as long as you are content with GAFF versions of those molecules. Separate tools (on the GROMACS side) can solvate arbitrary solutes in typical water models. However, we currently cannot handle the scenario where you might want to simulate arbitrary solutes in a mixture of water (modeled via a traditional water model) and some other solvent. We only support: a) solutes solvated in GAFF solvents such as flexible GAFF-water b) solutes solvated in pure water

I want to change this. My proposal at this point is to:

• Modify openmoltools.amber.build_mixture_prmtop to add an optional (1) argument, watermodel, which would specify what water model will be used IF water is a component of the mixture
• Modify openmoltools.packmol.pack_box to add an optional (1) argument, watermodel, which wiould specify what water model will be used IF water is a component of the mixture

(1) optional: I propose to make these optional for API stability (i.e. so someone expecting GAFF-water, i.e. @kyleabeauchamp https://github.com/kyleabeauchamp , doesn't suddenly find themselves with TIP3P instead)

The modification to openmoltools.packmol.pack_box will, I think, only be needed for non-three-point water models, since in that case we need to have packmol use a different number of points when generating the box in the first place. But for three-point waters it is sufficient, I believe, to simply swap the parameters used.

Currently I'm planning on implementing the first of these by simply changing what arguments are provided to tleap. It could also be achieved by reading the finished system into parmed, splitting, and swapping out the water parameters. Though this solution is more general (i.e. it could be used to swap parameters for other molecules as well) I don't see an obvious use case for it and it seems more logical to just use the desired water model in the first place. So that's the approach I'll use unless there are any objections.

If there are no objections I'll likely do this next week.

— Reply to this email directly or view it on GitHub https://github.com/choderalab/openmoltools/issues/134.