Update CHARMM36 to February 2026 release - #450
Conversation
|
It sounds like we should hold off on this until we get confirmation on whether those changes were intentional or bugs. |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #450 +/- ##
=======================================
Coverage 84.48% 84.48%
=======================================
Files 5 5
Lines 799 799
=======================================
Hits 675 675
Misses 124 124 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
I got a fast response confirming that the torsion change is a bug. I was also able to get CHARMM to compile without modifications by using CMake + Ninja with an option that their build script now provides. I believe that the issue I was seeing was a CMake-related bug. I'll rerun the conversion and test suite and see if any more issues show up. |
Updates CHARMM36 to the February 2026 release. A few new problems with this release that required workarounds:
HB1-CT1-CT3-HA3was added totoppar/stream/prot/toppar_all36_prot_modify_res.strto support a new N-methylalanine residue. This overrides the torsionX-CT1-CT3-Xwhen it is loaded, affecting regular alanine and therefore the energy of effectively every protein. I am pretty sure this is a bug in the force field files that I will try to report/ask about. With our current conversion system, the only way around this is to skip the entire file and all of its residues.H3Owas added, but instead of making a new atom type, they reused one from the protein force field, which has to be loaded with the water parameter files now for this to work. This messes up the entire conversion system. Unless someone really wants this, the easiest thing to do (that I did) is to skip this residue.This changes lots of force field files. It's not clear if there are (intentional and/or unintentional) changes to existing residues, although there are definitely none in
charmm36_protein.xml. This should still probably be considered a new version of the force field, which raises the question of whether we want to replace the old one in OpenMMForceFields like we did last time or distribute both the 2024 and 2026 releases.