[gmx-users] deshuf.ndx doesn't work for forces?

Chris Neale chris.neale at utoronto.ca
Thu Jan 24 23:25:36 CET 2008


OK, I can confirm this for 3.3.1. However, I don't think that the problem is one of shuffling or sorting but simply that
trjconv -f a.trr -o b.trr creates an exact copy of the .trr file *without* the forces. You can easily verify this by doing this:

trjconv -f a.trr -o b.trr
gmxdump -f a.trr > a.dumo
gmxdump -f b.trr > b.trr
diff a.trr b.trr > ab.diff

Note that b.trr is of smaller size then b.trr and the ab.diff file clearly shows that it is the forces that are missing.

I actually have never tested that before now so it appears that my g_desort routine will lead to the loss of force information 
at each re-sorting event by nature of passing through trjconv -o .trr.

I did take a quick look at the gmx_trjconv code but I am unable to determine the particular place where the code might be changed.
However, I think that I have isolated it to the need to add an output of force data from the -o .trr option to trjconv.

Chris



--- Original Message ---

Hi,
I think after the "trjconv -f *.trr -n deshuf.ndx" operation,  the new or=
ders of x and v in the trr file are correct.=20
Here "correct" means the order is the same as the intitial *.gro file you=
 use for grompp command. If the output
of trjconv is gro/pdb, you're right that it's only deshuffled, but not de=
sorted. But since there's no force in the gro
file, the bug i mentioned is only in the case when you choose trr as the =
output of your deshuffle operation.
Lanyuan Lu
----------------------------------------
>/ Date: Thu, 24 Jan 2008 12:28:47 -0500
/>/ From: chris.neale at utoronto.ca <http://www.gromacs.org/mailman/listinfo/gmx-users>
/>/ To: gmx-users at gromacs.org <http://www.gromacs.org/mailman/listinfo/gmx-users>
/>/ Subject: [gmx-users] deshuf.ndx doesn't work for forces?
/>/=20
/>>/ Message: 2
/>>/ Date: Wed, 23 Jan 2008 18:56:22 -0500
/>>/ From: LuLanyuan=20
/>>/ Subject: [gmx-users] deshuf.ndx doesn't work for forces?
/>>/ To:=20
/>>/ Message-ID:=20
/>>/ Content-Type: text/plain; charset=3D"gb2312"
/>>/
/>>/
/>>/ Hello All,
/>>/ I found sth like a bug regarding the deshuffle index file. I did a  =20
/>>/ simulation using multiple cpus and -sort -shuffle options. After  =20
/>>/ that I tried to use the deshuf.ndx file to recover the original atom =20
/>>/  order for my trr file by trjconv -n deshuf.ndx ... command.
/>/=20
/>/ As I understand it, the deshuf.ndx file does not allow you to desort, =20
/>/ merely to deshuffle.
/>/=20
/>>/ But by checking the output trr using the gmxdump, I found the oders =20
/>>/ of x  and v were deshuffled while the f oder remained unchanged. In  =20
/>>/ another word the values of forces were not consistent with those of  =20
/>>/ positions and velocities in the new trr file.
/>>/ Is this a bug?
/>/=20
/>/ So the order of the positions and velocities has changed, but are they =
/=20
>/ correct? I do not believe that gromacs 3.3.1 is capable of desorting, =20
/>/ nor is it supported. I have uploaded a tool called g_desort to the =20
/>/ users contribution section. It works well and is tested, but it's =20
/>/ usage is complicated when you want to load in .trr files via grompp.
/>/=20
/>>/ And is there anyway to get the correct oder for forces also?
/>/=20
/>/ I suggest that you try to reproduce this problem while using -shuffle =20
/>/ but not -sort.
/>/=20
/>>/ Thanks a lot.
/>>/ Lanyuan Lu/




More information about the gromacs.org_gmx-users mailing list