Add all Amber ion params

[aizvorski]

Amber has quite a lot of different kinds of ion parameters in dat/leap/parm/frcmod.ions*. There are sets for each water model, which can be either the Li/Merz "lm" or Joung/Cheatham "jc" sets, and also "hfe", "iod" or standard, and also 12-6 or 12-6-4 (Amber 22 manual, section 3.6. Ions). To some extent these can be mixed and matched with water models, for example OPC is recommended to be used with either the lm 12-6 opc standard set or the jc tip4pew set (manual , section 3.5.1).

OpenMM so far takes a different approach where a water model xml file seems to have builtin ions (no mix and match), and also they are tied to the protein forcefield, not the water model. So for example data/tip3p.xml doesn't have ions, but data/amber14/tip3p.xml has one specific set of ions.

I'd like to convert one-to-one all Amber ion frcmod files into OpenMM xml files with the same names and the same contents to avoid any confusion about either the naming or contents. So for example ambertools/dat/leap/parm/frcmod.ionsjc_tip4pew -> openmm/app/data/ionsjc_tip4pew.xml

The intended usage would be to select a water model and ions set like this app.ForceField('amber14-all.xml', 'opc3.xml', 'ionsjc_tip4pew.xml') and so forth. There could be some aliases for combined sets as well.

This is needed to get usable ions for OPC and OPC3, as well as to not restrict which combinations of water+ions are available to use.

1. Does this sound okay? Before taking this on (which is likely to be quite a lot of work), are there any potential issue with this plan, or something else we should do instead?
2. Could someone show me how openmm/wrappers/python/openmm/app/data/amber14/tip3p.xml was generated? (it seems auto-generated, apologies if there was a readme that already explains this). I'd like to be able to regenerate those before doing more conversions.

[aizvorski]

@peastman Was thinking of having a shot at this as it is needed to get OPC ions, any feedback before I get started on it?

[peastman]

Force field conversions are done at https://github.com/openmm/openmmforcefields. It converts more files than what we ultimately bundle with OpenMM. You can find the full set of Amber files at https://github.com/openmm/openmmforcefields/tree/master/amber/ffxml. It still groups the ions and water parameters together though. It's all configured through a single file that specifies what output files to generate and what input parameter files to include in each one.

@jchodera and @zhang-ivy might have thoughts on your suggestion of splitting them out.

[rkingsbury]

@aizvorski thanks for posting; I am also seeking this exact same capability and just ran across your post. Let me know if I can help. It sounds like, in principle, we can edit solvents.yaml in openmmforcefields so as to generate the combinations of water+ion parameters we need?

[aizvorski]

@zhang-ivy Do you think the split as described is a good idea? Any tips how it can be done reusing code from openmmforcefields convert_amber.py?

I have some other more detail-oriented questions esp what should we put in AtomTypes class= and name= fields, but mainly would like feedback on whether we want to do this and what we would do as an alternative if not.

@peastman If everything was converted, would there be any objection to including all those param files?

[peastman]

I don't think we'd want to bundle all of them with OpenMM itself, but that's part of the point of the openmmforcefields package: to be a more comprehensive package including more obscure or less used parameter sets. John and Ivy are the main people developing it, so I'll leave it to them to say whether they think including these would be good.

[aizvorski]

@peastman "I don't think we'd want to bundle all of them with OpenMM itself" - Why not?

If we follow the same pattern as now, to get working ions for OPC and OPC3, we'd need (at least) four more xml files. The only param sets in amber that wouldn't be included are (I think)12-6-4 sets (which don't have an obvious translation, although curious if you think they can be converted to a CustomNonbondedForce) and the HFE and IOD sets. It's not far from that to simply convert everything.

[zhang-ivy]

in principle, we can edit solvents.yaml in openmmforcefields so as to generate the combinations of water+ion parameters we need?

I'm not familiar with converting the solvent forcefields -- I've only worked on converting the GLYCAM forcefield into an openmm xml, but yes this sounds right.

Do you think the split as described is a good idea? Any tips how it can be done reusing code from openmmforcefields convert_amber.py?

You can check out my glycam conversion pipeline here. You'll have to do a deep dive of convert_amber.py to figure out exactly what things to need to change in solvents.yaml. You'll also may need to modify convert_amber.py. Sorry I don't have any more specific advice, I'd have to do look at the code more closely myself and I don't have the bandwidth for that right now.

As for whether its a good idea -- it sounds like if you have a use case where its essential to use special ion parameters then its a good idea, but one thing to note is that it was certainly a headache to do the conversion, so be prepared for that.

Maybe @jchodera has some additional feedback on this?

[jchodera]

@aizvorski : Why don't we add the conversion of the OPC solvent and corresponding ion files---along with a recommended bundle---to https://github.com/openmm/openmmforcefields? We're due for a new release to go along with the OpenMM 8 beta anyway, so it should be easy to deploy this and other solvent models of interest through there.

We'd just add the appropriate solvents and ions to the solvents.yaml, which likely requires a bit more tinkering to get everything to convert propertly.

[aizvorski]

@jchodera I just added a PR for this. I would request we put the ion files in openmm rather than openmmforcefields, since without it some of the water models here are not fully usable. Another issue, some of the current default ion sets (TIP3P-FB, TIP4P-FB) diverge from latest Amber, and adding all the converted ion files here allows at least reproducing what Amber does even if we don't change the defaults. The only downsides is a bit larger file size of what is shipped (probably not hugely significant) and some potential for user confusion since there are now more options (probably best addressed with documentation). What do you think?

[aizvorski]

@rkingsbury The conversion is done in PR #3773, please give it a try!

If you can make a water and salt box and compare its Amber energy vs the energy produced in OpenMM with these sets, that would be most helpful. I just finished the conversion so haven't had a chance to do that.

[rkingsbury]

@rkingsbury The conversion is done in PR #3773, please give it a try!

If you can make a water and salt box and compare its Amber energy vs the energy produced in OpenMM with these sets, that would be most helpful. I just finished the conversion so haven't had a chance to do that.

Outstanding, thank you @aizvorski ! I will try to test it out. I'm actually not very familiar with Amber itself (I use antechamber to prepare structures for LAMMPS but have not directly run anything with AmberTools). Nevertheless, I can compare OpenMM result to my LAMMPS runs and see if they're consistent.