[gmx-users] -b option for g_order

Beate Griepernau 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.

Beate



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.
>>
>> Regards,
>> Beate
>> _______________________________________________
>> gmx-users mailing list
>> gmx-users at gromacs.org
>> http://www.gromacs.org/mailman/listinfo/gmx-users
>> 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 mailing list