[gmx-users] Frequency confout is updated

chris.neale at utoronto.ca chris.neale at utoronto.ca
Thu Dec 17 02:52:45 CET 2009

You could also have a script that you optimize for your specific  
system that knows the number of frames in the xtc based on the file  
size and then trjconv -dump when your .xtc-polling script sees that it  
has been updated? Your visualization program could then update based  
on the output pdb.

I realize that this may create unnecessarily large .xtc files -- yet  
another reason to desire the ability for mdrun to concurrently write a  
secondary .xtc file that contains only a .ndx-defined subset of the  
system (in addition to the regular full atom .xtc). Still, you could  
cycle your mdrun and periodically purge the unnecessarily verbose .xtc  
that you use mostly for visualization.


Jack Shultz wrote:
> I guess I misinterpreted the description. I take it there is no built
> in mechanism to periodically write the structure.

There is :-) Trajectory output and checkpoint output.

> Maybe I could revise
> the source code to write the structure at every checkpoint?

Sure. That's what I was suggesting with my final comment. Find the
output mechanism that is used by -c and adapt it for use at the checkpoints.


> On Wed, Dec 16, 2009 at 10:07 AM, Mark Abraham <Mark.Abraham at  
> anu.edu.au> wrote:
>> Jack Shultz wrote:
>>> Hello,
>>> I would like to setup a screensaver to visualize structures as we are
>>> simulating them. We want to avoid slowing down the simulation
>>> significantly.
>> Not slowing things down significantly is only going to be possible when
>> GROMACS can use a processor that isn't going to get interrupted. I'd
>> recommend refreshing such a screensaver only every 30 seconds or so unless
>> you're intending to run only on one core of multi-core machines. Obviously,
>> test your mileage. The user isn't going to see much action on a desktop
>> machine, anyway.
>>> I found a solution that read pdb files. Is there a way
>>> to reduce the frequency mdrun updates the confout.gro?
>>> The structure file (-c) contains the coordinates and velocities of the
>>> last step
>>> -c  confout.gro  Output  Structure file: gro g96 pdb
>>> if I increase these values, does it write to these files less
>>> frequently or are we stuck with the updating this structure every
>>> step?
>>> nstxout: (100) [steps]
>>> frequency to write coordinates to output trajectory file, the last
>>> coordinates are always written
>>> nstvout: (100) [steps]
>>> frequency to write velocities to output trajectory, the last
>>> velocities are always written
>> As Justin pointed out, these .mdp options refer to the -t trajectory output,
>> and the -c structure file only receives the final configuration.
>> There's something to be said for you copying the -c mechanism and applying
>> it every few thousand simulation steps to your own intermediate output
>> structure file. The screensaver can simply poll that file.
>> Mark
>> --
>> gmx-users mailing list    gmx-users at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at http://www.gromacs.org/search before posting!
>> Please don't post (un)subscribe requests to the list. Use the www interface
>> or send it to gmx-users-request at gromacs.org.
>> Can't post? Read http://www.gromacs.org/mailing_lists/users.php

More information about the gromacs.org_gmx-users mailing list