-noappend constant-pH MD

User discussions
1

GROMACS version: 2021
GROMACS modification: constant-pH (Aho et al.)

Disclaimer: The question was also posted here.

Dear Users,

we recently setup some constant-pH simulation (small molecule with multi-site representation) using the recent implementation by Aho et al. (cpHMD). For one of our setups, we used gmx mdrun -noappend to run the simulations on our local cluster. I then stumbled across the following warning in the manual:

cphmd command currently does not work with .edr files saved as separate part after continuation (when -noappend is used in mdrun ). We currently recommend all the users to append data to the initial files when continuing simulations.

I am wondering now how this affects our simulations? Can we still use the data stored in the .xtc and .edr files, or should we repeat the simulations? The lambda-coordinates extracted from md.part0001.edr and md.part0002.edr appear to be correct. For example, md.part0002.edr starts at 11.006 ns, and its lambda-coordinates match exactly with those stored in md.part0001.edr at that time point. However, we encounter the following error for some simulations after the second append (e.g., for md.part0003.edr) using gmx cphmd or gmx energy:

Fatal error:
Energy header magic number mismatch, this is not a GROMACS edr file
If you want to use the correct frames before the corrupted frame and avoid
this fatal error set the env.var. GMX_ENX_NO_FATAL

I would greatly appreciate it if someone could provide a more detailed explanation of why the -noappend option should be avoided in constant-pH MD simulations, and whether the fatal error regarding a magic number mismatch is related to this.

Thank you very much already in advance!

All the best,
Marius

2

Which git commit are you using? I cannot find this cphmd error message in the code.

3

Hi @hess,
if I do git log the latest entry in the downloaded repository (I did not run git pull since the installation) is:

commit 28807b1162cacd9dc797520bc509d12edca13d1a (HEAD -> main, origin/main, origin/HEAD)
Author: Berk Hess <hess@kth.se>
Date:   Wed Apr 9 15:39:53 2025 +0200

    Two fixes to enable compilation with gcc-13
4

Ah, I see now that you pasted text from the manual, not an error message.

Then this is unfortunately a limitation of the code. I don’t understand exactly what the issue is. Have you tried concatenating the files with eneconv? I guess that won’t work either.

5

The first block quote was pasted from the manual, and the last block quote is an actual error message raised by GROMACS.

My question has two parts:

  1. Does using -noappend affect the physical correctness of our simulations or any further analysis? From my understanding of the manual, the only drawback is that you must run gmx cphmd on each .edr file individually. This may make the analysis slightly more tedious, but the outputs should remain physically valid.
  2. Could the corruption of the .edr files be caused by using -noappend in our cpHMD simulations, or is it more likely due to an issue with our file system?
6

Yes, but it’s not clear to me if those two issues are separate. The results will be correct with -noappend. But it could be that using -noappend generates an unreadable edr file.

7

Okay that could explain our observation. Interestingly, it seems that not all our systems are affected by this issue. If I find some time I will try to investigate that issue a little bit more closely. For now, we will repeat the affected simulations with -append. Thank you very much! :)

8

Maybe it’s related to the strange time of your checkpointing and it will work if checkpointing occurs at and nstenergy step.