From: Peter Freddolino (petefred_at_ks.uiuc.edu)
Date: Mon Mar 02 2009 - 10:51:44 CST
The constraint position would start precisely where it finished; it is
simply calculated based on the velocity, current timestep, and original
SMD pdb file.
I should also add that while it is possible to switch from binary to
ascii restart files, it is not a good idea due to the loss of precision.
Peter
Hugh Martin wrote:
> That's fantastic, a follow up question though: if I were to use your
> first suggestion, would the constraint position in the second simulation
> start precisely where it finished in the first simulation or would it be
> reset to the SMD atom? There is some lag between the two in my
> simulations, stopping and restarting periodically corrects this.
>
> Many thanks,
>
> Hugh
>
> 2009/3/2 Peter Freddolino <petefred_at_ks.uiuc.edu
> <mailto:petefred_at_ks.uiuc.edu>>
>
> Hi Hugh,
> you shouldn't need to generate a new SMD.pdb file if you use an
> appropriate starting timestep for your subsequent simulations, which is
> a cleaner way to do things. You can read the last timestep from the
> restart xsc file:
>
> proc get_first_ts { xscfile } {
> set fd [open $xscfile r]
> gets $fd
> gets $fd
> gets $fd line
> set ts [lindex $line 0]
> close $fd
> return $ts
> }
>
> set currenttimestep [get_first_ts $inputname.xsc]
> firsttimestep $currenttimestep
>
> Alternatively, you can convert binary <-> ascii using catdcd:
>
> catdcd -o file.coor -otype namdbin file.pdb
> catdcd -o file.pdb -s file.psf -stype psf file.coor
>
> Finally, you need to use binaryrestart, not binaryoutput, to toggle
> ascii vs. binary restart files. binaryoutput only applied to the output
> files written if a run finishes completely.
>
> Best,
> Peter
>
> Hugh Martin wrote:
> > Hello,
> >
> > I'm attempting to automatically string together subsequent NAMD SMD
> > simulations via a script which detects when the previous
> simulation has
> > finished, converts and renames files to act as input files for the
> next
> > simulation, and then submits the job automatically. In order to do
> this
> > I need to convert the pdb output file from an initial simulation
> into an
> > SMD.pdb input file for a subsequent simulation (this would be done
> by a
> > trivial substitution of a field in the pdb output file). I only
> wish to
> > use an ASCII pdb file to refer namd to the SMD atom position; for the
> > coordinates, velocities and periodic boundaries I need to use binary
> > input files coor, vel, and xsc. Basically, I need both binary and
> ASCII
> > forms of output in order to link two SMD simulations automatically.
> >
> > This presents a problem, as by using binary input files, NAMD
> insists on
> > producing binary output files for restart files and final
> > coordinate/velocity files (circumventing fields such as "binaryoutput
> > off" in the .conf file). This makes direct conversion of the output
> > coordinate file to an ASCII SMD.pdb file non-trivial.
> >
> > Therefore, if my script, which links the first simulation to the
> > subsequent simulation, is going to succeed, I need NAMD to either
> output
> > in both binary and ASCII fomats (is this possible?), or I need to
> > convert the binary output into ASCII (.coor to .pdb) using the command
> > line (I know .coor files can be converted to .pdb files using vmd,
> > however scripted use of VMD windows on distant machines is not
> possible
> > to my knowledge).
> >
> > Any help or ideas would be greatly appreciated.
> >
> > Many thanks,
> >
> > Hugh
>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:52:25 CST