But I still cannot figure out why I am getting a lot more dihedral angles in OpenMM compared to what is reported by NAMD and in the PSF file (the dihedral section reports the number of dihedrals) When you use getNumTorsions() on the PeriodicTorsionForce in OpenMM, you get a list of the total number...

Now I'm using force group num 6 and assuming the non bonded force's force group num is always 6. Is this true? I also try to find if there is an enumeration type defining force group numbers and couldn't find it. You definitely can't rely on this. This happens to be true if you serialize a system f...

No, there is no C++ API for working with force field files. It basically just has the library for actually running molecular mechanical calculations -- nothing for setup or analysis (for instance, there is no trajectory writer, either!). If you want to work with CHARMM files, you will need to write ...

vdbedem wrote: Any particular reason to exclude negative residues?

Nope. Didn't realize PSF files used them when I wrote the parser (I use CHARMM minimally myself). I'll fix it. Thanks for the report and the fix!

I would use MPI, personally. But that's precisely what John Chodera's library does. So I guess the best answer I can think of is to do what repex does. Which is to say, just use repex (or implement the same thing in C++ if you want to do that and can reproduce the rest of the required machinery from...

Because you are not at a true local minimum. Note that it is very difficult to get to a true local minimum (where the force on every atom is zero). The minimization criteria for OpenMM is (I believe) satisfied when the difference in energy between successive steps is less than the tolerance. Forces ...

This is a consequence of scipy's NetCDF class slowing down as the NetCDF file grows in size. The reader is the fastest Python option, but the writer is slower than the one from NetCDF 4 and slows down over time. I could probably work around this issue by supporting NetCDF writing through the netCDF4...

Yes, _d suffixes were removed a long time ago. Here is the issue where debug library naming was brought up as a question: https://github.com/pandegroup/openmm/issues/398 and then the PR that changed this behavior: https://github.com/pandegroup/openmm/pull/408 When you compile in Debug mode, what tha...

No, you would have to solvate the molecule with CHARMM or something equivalent. You could solvate in VMD and use autopsf to create the PSF file, or you could use CHARMM-GUI if you don't have access to CHARMM directly.

We're currently working on a CHARMM FF conversion, but it's not quite ready yet.

zebra_123456 wrote:Could it be because "dt" is not a user-defined variable?

"dt" is the time-step and is typically constant, I think (except for some kinds of variable integrators perhaps). Were you defining your own "dt" variable for something else? Did this not result in an error?