GROMACS version: 21.4
GROMACS modification: No
Any plans to include a version of the latest amber protein FF, ff19sb, in the gmx standard distribution? … if not, can anybody tell me whether implementing this as additional ff folder in the top directory is reasonably straight forward or not? I am a bit worried about the CMAP terms…
thanks,
michael
CHARMM-GUI can build systems with ff19SB and should be able to provide GROMACS inputs.
I do not think there is much appetite for including new force fields, largely due to no one wanting to take responsibility for generating and validating these force fields. Every once and a while someone creates a new force field distribution, then when asked to validate it, they go quiet (because it’s such a rigorous process).
That said, I fully agree that more modern force fields are sorely needed. The available AMBER force fields officially supported by GROMACS are (at best) deprecated and (at worst) in some cases basically invalid.
talking about invalid - there is this:
which only covers part of the amber FFs, but doesn’t look too bad … errors of up to 0.2% in individual energy contributions are probably acceptable - the author of this document might have used single precision gmx, which would explain the differences …
But, I agree, with the most recent Amber FF available in gmx being basically 20 years old, it would certainly be good to have an update there - in particular at times when modelling of intrinsically disordered proteins becomes increasingly interesting, and it is well known that the older amber FFs show a poor performance there - Gromos FFs have not been tested a lot in this respect as far as I know, and the current OPLS implemetation in gromacs is also quite old …
I’d be happy trying to implement and validate FF19SB, if anybody could point me to a decent documentation on how to convert CMAP parameters to a gromacs readable format - is there such a thing?
cheers
michael
CHARMM-GUI has already implemented this, and should produce GROMACS inputs with ff19SB. Check out how they do it.
Thanks for pointing that (charmm gui) out - in fact I’ve been there. Problem is this is a web server, i.e., basically a black box, and the doc is not detailed enough to answer my question (cmap implementation in gmx)
But they provide the force field files; is that not what you’re trying to see? If you have a defined topology and a force field file that has the [cmaptypes] in it, does that not provide you with the information you’re looking for? Their devs asked me about the implementation and I offered some suggestions, but I honestly don’t know what they ended up doing to implement the residue-specific terms. But you should have the information, which we can certainly discuss here if needed.
thanks, i guess you are right, I’ll have a look at what charmm gui gives me and then try to compare that with the files in leap/ambertools, that should give an idea. I might come back to you though if i get stuck ;)