Dear Justin:
I could not find new files here: MacKerell Lab
Is it the right place? There, what I see is still as below, even after a browser refresh.
CHARMM36 Files for GROMACS
CHARMM36 force field in GROMACS format, including CGenFF version 4.6 and the CHARMM36m protein force field revision. Updated July 2022.
The current version of the CHARMM36 port for GROMACS is dated July 2022, corresponding to the CHARMM toppar release of the same date. It contains the same topologies and parameters as the July 2021 update (including the option to use LJ-PME with lipids, given in the second port listed below) and adds some new parameters, and modified amino acids, among other items. See the âtoppar_historyâ file in the CHARMM toppar distribution above for details. Files updated 12/8/2022 to fix typos related to TIP4P-Ew water parameters and an issue related to cholesterol NBFIXes.
I donât have a very good solution for this aside from leaving a bunch of previous ports online that have bugs on them. In my experience, users do not read provided information very well so I am leery of doing this, knowingly allowing someone to download something that is broken. We have done this in the past (and you see in the list on Alexâs site) when we have found more serious issues but those were cases in which things were online for a long time before an issue was discovered. In the latest port, issues have been detected within a few days. I have been posting updates on the third-party tools section of the forum (where I post all C36-related announcements) so I hope this is enough notification. Aside from the cholesterol issue, most things that have come up have been rather obvious errors in mostly non-standard features.
Your question does not have anything to do with the topic of this post. But anyhow ⌠The link you posted works for me. I would suspect something blocking your connection. Start with contacting your internet provider. Can you access http://mackerell.umaryland.edu/ at all?
Then I would think that either your internet service provider (university?) is blocking traffic to that site or the University of Maryland is blocking access from your IP. Perhaps there has been too much bot traffic, or something.
I just checked the recent GROMACS port of the CHARMM36 FF (charmm36-feb2026_cgenff-4.6.ff.tgz). Apparently the dihedral âCTL2-CEL1-CEL1-HEL1â is again not explicitly defined and the definition for âCRL1 CTL1â is still present in [ pairtypes ] . Editing the FF port according to the suggestions in this thread gives me the same energies as the forcefield.itp from the CHARMM-GUI for a small membrane patch. Is there a particular reason for this?
I will double check the tests but I would strongly caution against making manual changes to the force field; this was a solved issue but we may still be missing something. The use of NBFIX on intramolecular terms has always been a corner case but leads to different energies; we previously got the hierarchy right and the NBFIX terms were correctly applied and overrode the pair definition from combination rules. Iâll look into this.
Can you provide the energies from CHARMM-GUI and the (unedited) GROMACS port? I cannot reproduce the problem; my lipid energies all match, including cholesterol.
My apologies, I think I found the solution to my issue:
I did not look close enough to the numbersâŚ
The current definition of CRL1 CTL1 under the [ pairtypes ] directive and the [ nonbond_params ] directive is CRL1 CTL1 1 0.357250385974 0.115060000000. Those fit exactly to definition of CRL1 CTL1 in the [ nonbond_params ] directive of the forcefield.itp provided by CHARMM-GUI. I only recognized that there is an entry for CRL1 CTL1 in [ pairtypes ] and directly assumed it is the âoldâ definition discussed in this thread.
Redundancy of [ pairtypes ] and [ nonbond_params ]
If I ran my single-point energy calculation removing CRL1 CTL1 in [ pairtypes ] , GROMACS apparently uses the definition in the nbfix.itp and therefore I get the same energies between your GROMACS port and the output of the CHARMM-GUI.
Q1: Is there any reason why this non-bonded interaction is defined twice here?
Misunderstanding about the CTL2-CEL1-CEL1-HEL1 dihedral.
I assumed you wanted to integrate this dihedral to the GROMACS port, but reading the thread in more detail showed to me that I misunderstood you here. However, I decided to add this dihedral to the forcefield to make it more comparable to the output of the CHARMM-GUI.
Many thanks for your time and sorry again for the inconvenience!
The defined pairs specify the interactions subject to FudgeLJ and FudgeQQ, and NBFIX is just a special case of overriding even those scaled 1-4 interactions (in CHARMM, the scaling factor is 1.0 anyway, but this is all done to be fully consistent with how CHARMM implements the hierarchy of parameter interpretation).