Gmx trjconv for 'selected' trajectories

GROMACS version: 2021
GROMACS modification: No

Hi,
I am trying to trace the motion of a few fluid molecules that I isolated via gmx selection; my idea is to excract a sub-trajectory containing only the selected atoms:

gmx trjconv -f traj_22ns_26ns.trr -n advl_24.ndx -o advl_24.trr -s system.tpr

and then use it to ‘dump’ a few .gro files:

gmx trjconv -f advl_24.trr -dump 0 -n advl_24.ndx -s system.tpr -o test.gro

However, when I try to do so I get the following error:

Fatal error:
Index[0] 25885 is larger than the number of atoms in the
trajectory file (344). There is a mismatch in the contents
of your -f, -s and/or -n files.

which I believe is due to the fact that system.tpr refes to the whole system, and not to the selection only.
Is there a way to make this work? I would really try to avoid reading through the complete trajectory, as it is particularly heavy. It would be great if there were a direct way to produce a .tpr from the selection to then feed to gmx trjconv, is it somehow possible?

Update
I utilized

gmx convert-tpr -s system.tpr -n advl_24.ndx -o system_advl.tpr

to create a corresponding topology; however, if I now run gmx trjconv with the new .trp I get a segmentation fault.

...
Select group for output
Group     0 (resname_SOL_and_x_>_65.7_and_x_<_67.7_and_z_<_30.63400_and_z_>_29.12_f0_t23980.000) has   344 elements
There is one group in the index
Segmentation fault (core dumped)

You should be able to directly generate one pdb file with all frames that you can then convert to gro without a tpr. Or you can split the pdb file in separate files for each frame. I don’t know if you can directly generate gro.

I was hoping to get not only positions, but velocities too.
You thinkall I need to do is to change the output format of the first trjconv to .pdb (or maybe .gro)?

Ok, it works with .gro too, now it’s just a matter of separating each fame (but it should be easier).
However, is the segmentation fault expected? Seems like a bug in trjconv

A segmentation fault is not completely unexpected, but should never happen.
Can you run this through gdb with a debug build?

I can try