Dear all,
Next GROMACS developer meeting will be Wednesday, April 16, 2025 9:00 AM.
Agenda:
<very brief description of the topic, and link to information on the ideas or to the issue> < who you are>
<very brief description of the topic, and link to information on the ideas or to the issue> < who you are>
Open questions
We usually reserve in total 20 min for each discussion topic. We suggest to use 5-10 min to present the problem and focus on a question that you want to address. Everybody is welcome!
Note this is a wiki post: Everybody in the developer category can edit!
To be able to post on the developers category, you need to member of the forum and send a request to join the GROMACS developers group using the following link
VM: AMBER does dihedral matching in a weird way (impossible to replicate just with the data files, since one needs to differentiate first and non-first arguments). This is needed to accurately match energies. OpenMM also does things this way.
AA/PB don’t like env. variable, a flag would be better, but it’s hard to actually implement. Berk earlier also recommended using the env. variable.
VM: Vytas also wanted to do it via pdb2gmx, but it does not know about atom types.
PB: I would suggest a combination of both env. var and a command line flag. Works only if both are set. And in the next release, we just drop the env. variable.
VM: This also applies to ff14 and perhaps ff03, so need to think if we want to apply the new ordering for them too. For now, we need to make it hard for people to mess up their work.
PB: Setting warning is useless. Make it an error. If a flag is set, add a note to log to be explicit.
VM: Also a hard error when non-ff19 is used. So that there’s no reasonable way to affect the existing forcefields.
PB: It’s important to have audit trail of what is being done. As long as we can trace what they did and they did things wrong, that’s ok. I wanted to the audit trail (how many warnings during grompp), but it wasn’t accepted; current TPR does not show if users ignored any warnings.
VM: Also, adding the new ff would change the order, so if people are using “forcefield #7” in their scripts, things would break. One more reason to use env. var. We should prevent industrial-scale stupidity, so let’s call it x-amber-..., to keep the order same.
AA: We should avoid breaking things between patch releases at any cost, but also make the transition between 2025 and 2026 smooth for those who use the feature.
VM: Env. var helps here. Vytas suggested that Amber 19 and tleap-ordering are only used together. This is good for correctness, but does not solve the problem of what the users see.
VM: Working with grompp is pain, dumping is unreadable and requires custom Python scripts to match types.
AA/PB: That’s why we need tests asap.
VM: But thorough testing requires combinatorically-exploding number of aminoacids; not suitable for unit-tests.
VM: Are there atom names/types in grompp?
PB: In the (legacy) atomnames datastructure there are atomTypeA etc fields. They are indices to the string table.
VM: And thank you, Paul, for the new API :)
Ad-hoc discussions:
VM/PB: There are some issues with HIP branch and compiling for Vega (gfx800-series). Paul knows what goes wrong.
VM/PB/AA: Brief AMD MI3xx benchmarking / future work (HeFFTe, rocFFT, MI300A) discussion.
VM: I ran some basic benchmarks to check that it is at all reasonable; will focus on the more advanced tests after the Amber FF work.