-
Can lammps use the newest amber forcefield, ff19SB, which makes use of the CMAP term? The lammps documentation states: “The AMBER force field does not include the CMAP term.” but could be referring to the older forcefield generations.
-
Is it necessary to use the charmm/charmmfsw/charmmfsh pair style to properly utilize the AMBER forcefields? I do not want to be limited by the TIP3P water model, “The TIP3P water model is strongly recommended for use with the CHARMM force field.” If so, is the pair style still the limiting factor? Hence, does a new one still needs to be added? Note, ff19SB can utilize more accurate water models, such as OPC.
-
What is the most recommend tool for protein PDB to lammps coordinate and force-field parameter files? AmberTools, (amber2lmp is outdated), CharmmGUI, MoSDef, etc.
Let me respond to your questions with a question: does it say anywhere in the LAMMPS documentation that it is fully compatible with all variants of the Amber force fields?
You have to understand that most of what is provided in the LAMMPS distribution is contributed by users or developers outside the core of LAMMPS. This is particularly true for running simulations with setups taken from other packages like CHARMM, NAMD, Gromacs, Tinker, or Amber. Thus all the provided tools and statements in the documentation correspond to the state of those packages at the time when the tools, source code, and documentation were contributed (in many cases this goes back more than 10 years) or updated, and the correctness of those statements and the source code depends on the knowledge and experience of the contributors.
In other words, if you want to be 100% compatible with Amber, you should use the Amber software stack and not LAMMPS. Also, if something is not said explicitly as being supported or compatible, then you can assume that it is not. So, it you still intend to run your simulations with LAMMPS, you have to do, what people before you have done when they wanted to use LAMMPS with an Amber force field: you have to make tests for every little bit and aspect and confirm to yourself that everything you need to use is done exactly as you needed. If not, you need to contribute new styles or new tools or an improved documentation. Our goal for the LAMMPS documentation is that each command and style is describing exactly what it does. How, you can stitch those commands and styles together and make it produce meaningful simulations, is mostly your job.
Of course, we highly welcome contributions or corrections that provide features not available, for as long as they don’t break any existing functionality and are not too disruptive.
Again, if you don’t want to invest that effort, you can fall back to using the Amber MD software (pmemd).
Let me respond to your question for my question with a question: Does “The AMBER force field does not include the CMAP term.” refer to ff99SB, ff14SB, ff19SB or collectively all AMBER forcefields? The contribution date may indicate The Amber forcefield at the time of contribution.
Your question indicates as my original question has elucidated, the documentation is rather misleading, especially with the provided equation. As of now, due to the word “The”, it appears to be a specific AMBER force field.
The effort, fine-tuning, and contributions are part of simulations, but just need some clarifications for specifically utilizing LAMMPS to simulate proteins. As mentioned in the documentation there are many force-fields, AMBER is just one of many.
It appears you have somewhat answered questions 1. and 2. However, for question 3., do you have any insight?
You are asking for something that is impossible to do. One cannot predict the future and thus it is impossible in any documentation to describe the status of the future. And considering the amount of text in the LAMMPS documentation, you cannot expect that everything is always up-to-date. There is simply not enough time and manpower. As I mentioned, you are most welcome to try and test everything, compare to what pmemd does and then submit a pull request with the necessary changes to the documentation, since this is how most of the currently available information came to be.
Again, you are asking for a specificity that is very difficult to implement. It is easy to state what can be done, but it is much harder to say what cannot be done, since at some time in the future this may change.
No.
@alphataubio may have more to add.
no idea. my best guess is the bayesian uninformed prior: odds are 50/50. i dont know how AMBER implements CMAP or format of input files it expects.
look at:
src/MOLECULE/fix_cmap.h
src/MOLECULE/fix_cmap.cpp
src/KOKKOS/fix_cmap_kokkos.h
src/KOKKOS/fix_cmap_kokkos.cpp
i took the claim “The AMBER force field does not include the CMAP term” from Brooks (2009) when i wrote the charmm howto so obviously this could be an outdated statement.
one question: ff19SB is the newest amber forcefield ? that’s six years old. the latest charmm version of parameters is July 2024 (which is used when generating a LAMMPS system with charmgui):
https://mackerell.umaryland.edu/charmm_ff.shtml
again i dont know i wasnt even aware that the charmm pair styles could be used with amber parameters. i believe the expression is YMMV. what i can assure you however is the KOKKOS charmmfsw/kk code is the fastest most unit-tested and regression-tested implementation of CHARMM anywhere (vs charmm original fortran md code vs gromacs vs …).
The warning about TIP3P is about the LJ parameters of charmm atom types that were optimized with TIP3P water around them. If ff19SB has parameters that were optimized with another water model (ie OPC), then that’s the ONLY water model you should be using with the ff19SB parameter set you’re using. otherwise what you have is just a really fancy random number generator. also you would need that other water model to be implemented in LAMMPS already. thats another can of 
charmmgui is only viable option AFAIK. everything else is 
AMBER ff19SB is in fact the newest AMBER forcefield to my knowledge. They don’t update force fields frequently, which to me feels defensible from a reproducibility point of view.
You can use LAMMPS to implement OPC and OPC3 water models. OPC3 is a rigid three-site model and can be run as a standard molecule with fix shake. OPC has an off-centre O charge and can be run with the lj/cut/tip4p/long style, which (despite the name) can run a generic 4-site water model with the appropriate parameters. Equally well, you can also run a 4-site explicit water molecule with fix rigid...small for integrating the rigid body equations of motion.