Gmx trjcat -demux command causes fatal error: "Sorry, write_trxframe can not write unknown"

GROMACS version: 2020.1
GROMACS modification: No


I’ve used GROMACS to perform a short REMD simulation (200 ps) in order to test whether my choice of temperature range allowed sufficient exchanges between replicas.

The REMD simulations progressed and finished without problems and produced the following files in each replica directory: remd.part0001.log, remd.part0001.xtc, remd.part0001.edr, remd.part0001.trr, remd.part0001.gro using -deffnm remd and -noappend to run the REMD simulation.

Concatenating the .part0001.log files with the command:

cat …/rep_{0…16}/remd.part0001.log > REMD.log

worked fine; the replica directories are named rep_0, rep_1, etc. and I was in a separate directory to create the new files (hence going up one directory with cat …/rep_{0…16}/…).

The replica_index.xvg and replica_temp.xvg files were successfully created with the command: REMD.log

However when trying the command:

gmx trjcat -f …/rep_{0…16}/remd.part0001.xtc -demux replica_index.xvg

it results in the output below. It appears to be calling the correct .xtc files from all replica directories. I’ve trying renaming the files remd_0.xtc, remd_1.xtc. etc. and work from a single directory, to no avail. There isn’t much info to go by besides “Sorry, write_trxframe can not write unknown”.

Command line:

gmx trjcat -f …/rep_0/remd.part0001.xtc …/rep_1/remd.part0001.xtc …/rep_2/remd.part0001.xtc …/rep_3/remd.part0001.xtc …/rep_4/remd.part0001.xtc …/rep_5/remd.part0001.xtc …/rep_6/remd.part0001.xtc …/rep_7/remd.part0001.xtc …/rep_8/remd.part0001.xtc …/rep_9/remd.part0001.xtc … /rep_10/remd.part0001.xtc …/rep_11/remd.part0001.xtc …/rep_12/remd.part0001.xtc …/rep_13/remd.part0001.xtc …/rep_14/remd.part0001.xtc …/rep_15/remd.part0001.xtc …/rep_16/remd.part0001.xtc -demux replica_index.xvg

Note that major changes are planned in future for trjcat, to improve usability and utility.Read 17 sets of 1684 points, dt = 0.117647

Reading frame 0 time 0.000

Program: gmx trjcat, version 2020.1
Source file: src/gromacs/fileio/trxio.cpp (line 557)

Fatal error:
Sorry, write_trxframe can not write unknown

For more information and tips for troubleshooting, please check the GROMACS
website at

Seems like I am not the first to encounter this issue: Problem demuxing a PTReplica Exchange

But back then no one had any suggestion either. '^_^

Hi winterdl,

I just had a brief look at the source code of trjcat to infer what is happening. While it’s hard to understand exactly what is going wrong by just staring at code, I’m guessing that something is off determining the output file type.

Could you try to use an -o option to explicitly tell GROMACS what type of output file you want to write?

If that does not work, it’s useful to upload a minimal example where things crash, then I can go and debug - in this case, it’s easier to continue the discussion after creating an issue here:


Thanks Christian,

I may have solved the problem, but let’s go step by step! Unfortunately, the issue is the same when specifying the output:

gmx trjcat -f …/rep_{0…16}/remd.part0001.trr -demux replica_index.xvg -o trajout.xtc

Results in the exact same message (I think trajout.xtc is the default output name anyway).

During all my attempts, I noticed the 16_trajout.xtc file is created before the error kicks in. I assume -demux starts with the replica with the highest number to create 16_trajout.xtc, 15_trajout.xtc, etc.

For some reason I decided to try instead:

gmx trjcat -f …/rep_{0…16}/remd.part0001.trr -demux replica_index.xvg -o {0…16}_trajout.xtc

And that created all _trajout.xtc files, all with similar sizes (good sign), and the following output:

Command line:
gmx trjcat -f …/rep_0/remd.part0001.xtc …/rep_1/remd.part0001.xtc …/rep_2/remd.part0001.xtc …/rep_3/remd.part0001.xtc …/rep_4/remd.part0001.xtc …/rep_5/
remd.part0001.xtc …/rep_6/remd.part0001.xtc …/rep_7/remd.part0001.xtc …/rep_8/remd.part0001.xtc …/rep_9/remd.part0001.xtc …/rep_10/remd.part0001.xtc …/rep
_11/remd.part0001.xtc …/rep_12/remd.part0001.xtc …/rep_13/remd.part0001.xtc …/rep_14/remd.part0001.xtc …/rep_15/remd.part0001.xtc …/rep_16/remd.part0001.xt
c -demux replica_index.xvg -o 0_trajout.xtc 1_trajout.xtc 2_trajout.xtc 3_trajout.xtc 4_trajout.xtc 5_trajout.xtc 6_trajout.xtc 7_trajout.xtc 8_trajout.xtc 9_tr
ajout.xtc 10_trajout.xtc 11_trajout.xtc 12_trajout.xtc 13_trajout.xtc 14_trajout.xtc 15_trajout.xtc 16_trajout.xtc

Note that major changes are planned in future for trjcat, to improve usability and utility.Read 17 sets of 1684 points, dt = 0.117647

Last frame 20 time 200.000

GROMACS reminds you: “I love fools’ experiments. I am always making them.” (Charles Darwin)

I am not sure why it was necessary to specify all names for the output files since by using -o trajout.xtc or no -o flag at all, GROMACS clearly tries to generate more than one output file (given the replica number prefix).

I now have to look into the 17 trajectories to make sure I concatenated the correct sections of each replica.

If you’d like more information, where can I find some guidance to 1) decide what’s a minimal example (maybe trying to demultiplex two replicas?) and 2) what exactly am I meant to upload?



Hi Daniel,

That’s already a bunch of very useful information and I believe I have an idea on how we could fix this, or at least give a more meaningful message to the users in the next GROMACS version.

When I mentioned a minimal example, I just meant cutting down the data needed to recreated the failing behaviour, the two-trajectory case would be useful, if it’s reasonably fast to create, alternatively cutting down the trajectories in length, so that it’s not GBs being uploaded (don’t spend the afternoon, just to cut down a little bit) It’s just a means to speed up the debugging process. It would be nice if you could upload everything that is needed, so that I can run GROMACS on my workstation and see the same error as you do; in your case all the rep_{0…16}/remd.part0001.trr and replica_index.xvg

Sounds good! I’ll upload the files a little later.

To be a little clearer (just noticed I was inconsistent with my commands), the issue occurs (and the solution works) regardless of whether .xtc or .trr files are used as input.

I also noticed when I paste Bash code here, two dots become three dots (when I paste {0…16}). Not sure why that is, but I use two dots in the commands, as per Bash language.

Hi Daniel,


To avoid re-formatting, you can use the pre-formatted text feature and enclose your bash commands in backticks, `, see here




Thanks for the tip!!

I’ve uploaded the files as requested: