[gmx-users] -b option for g_order
b.griepernau at bioinformatik.uni-saarland.de
Thu Dec 1 17:29:32 CET 2005
The trajectory has a frame at 46000ps.
The headers of the xtc-file are:
natoms= 21548 step= 22940000 time= 45880 prec= 1000
natoms= 21548 step= 22945000 time= 45890 prec= 1000
natoms= 21548 step= 22950000 time= 45900 prec= 1000
natoms= 21548 step= 22955000 time= 45910 prec= 1000
natoms= 21548 step= 22960000 time= 45920 prec= 1000
natoms= 21548 step= 22965000 time= 45930 prec= 1000
natoms= 21548 step= 22970000 time= 45940 prec= 1000
natoms= 21548 step= 22975000 time= 45950 prec= 1000
natoms= 21548 step= 22980000 time= 45960 prec= 1000
natoms= 21548 step= 22985000 time= 45970 prec= 1000
natoms= 21548 step= 22990000 time= 45980 prec= 1000
natoms= 21548 step= 22995000 time= 45990 prec= 1000
natoms= 21548 step= 23000000 time= 46000 prec= 1000
natoms= 21548 step= 23005000 time= 46010 prec= 1000
natoms= 21548 step= 23010000 time= 46020 prec= 1000
natoms= 21548 step= 23015000 time= 46030 prec= 1000
The promblem seems to be resolved if we cut the large trajectory (0 to
50 ns) in smaller pieces, at least g_order works fine for a .xtc file
including only frames from 45 to 48ns.
David van der Spoel wrote:
> Beate Griepernau wrote:
>> Dear all,
>> I did a simulation of a membrane over a time period of 50ns writing out
>> coordinates every picosecond.
>> Next I edited the .xtc-file to get a new .xtc file keeping only the
>> data of every 10th step using trjconv and option -skip.
>> On this new .xtc-file I applied g_order with different beginning and
>> ending times (option -b and -e).
>> For most beginning and ending times this procedure works well, but for
>> beginning times around 46000ps the routine 'g_order' gets stuck: I
>> don't get an error message, but just the notice 'Skipping frame
>> 0time 45890.000' .
>> Using later start times > 46100 works well again.
>> I checked my .xtc file using several other routines, e.g. gmxcheck and
>> trjconv to write a snapshot of the trajectory at the time im question,
>> and it worked well.
>> Does anybody know why this problem occurs and how it can be solved?
> This is probably not specific for g_order. Does the trajectory have a
> frame at 46000?
> Could it be that the original framenumbers are still in place (i.e.
> step etc.)?
> Please run gmxdump on the xtc file and print the headers of the frames
> at 46000 and the one before and after and send it to the list.
>> Thanks for your help.
>> gmx-users mailing list
>> gmx-users at gromacs.org
>> Please don't post (un)subscribe requests to the list. Use the www
>> interface or send it to gmx-users-request at gromacs.org.
More information about the gromacs.org_gmx-users