>>
>> Ross Walker wrote:
>>
>>> Hi Ben,
>>>
>>> I think this would be useful and should probably be done in the
>>> same way a negative ntwr works write now. E.g sequentially
>>> numbered restart files every abs(ntwr) steps. It should be fairly
>>> simple to do I think. Just find where the minimization writes a
>>> restart file at the end and have it call an equivalent routine
>>> after the coordinates have been updated in runmin based on the
>>> value of ntwr with the filename based on whether ntwr is positive
>>> or negative.
>>
>>
>> OK, I've done that, more or less, and have just uploaded the
>> changes to the CVS tree.
>>
>> In brief:
>>
>> I've shifted the "write restart file" command from sander.f to
>> runmin.f. This allows better logging of the file writing, so it
>> will now say "writing restart file at X number of steps" for the
>> last restart file as well as for the intermediate ones, if any.
>>
>> Along with that, I moved the "write restart file" command in
>> sander.f inside the XMIN and LMOD switches. Those calls are still
>> in sander.f, though, not inside the XMIN and LMOD subroutines. For
>> the sake of consistency, I suppose it would be good to move them
>> into those routines, but not understanding so much about what XMIN
>> and LMOD did, I didn't really want to mess with them right now.
>>
>> Runmin.f and its counterpart, minrit.f, allow writing of restart
>> files so that ntwr 0 will overwrite "restrt" every ntwr steps, and
>> ntwr < 0 will create a unique "restrt" every ntwr steps. Similarly,
>> ntwx 0 will now write a coordinate trajectory with frames saved
>> every ntwx steps. It seemed best to make the behaviour of "ntwr"
>> and "ntwx" under minimisation match the same under dynamics as
>> closely as possible.
Daniel Roe wrote:
> One unintended side effect of this change is that now during
> trajectory post-processing the output trajectory potentially gets
> written twice, once during the minimization in runmin.f and once
> after minimization in trajene.f (this is what's happening now that's
> causing the trajene and trajene_netcdf trajectory write tests to
> fail). The way I see there are two ways to proceed. One is to disable
> trajectory writing in runmin.f if imin==5, the other is to disable
> trajectory writing in trajene.f altogether. The former preserves the
> original behavior, but only allows writing of post-minimization
> coordinates. The latter allows writing of as many coordinates during
> the minimization step as you would like, but requires more care in
> choosing ntwx. Either way would be fairly easy to implement. Does
> anyone have an opinion either way?
>
> -Dan
Hi Dan,
Hmm...I confess I hadn't thought about the dangers of trying to do this.
I haven't really done any minimisation of whole trajectories.
Are you saying that for each point in the original trajectory, a whole
"minimisation trajectory" is produced, making what's almost (but not
quite) a trajectory of trajectories?
If so, I can see the problem.
Instinctively, I'd go for option #2 of your suggestion, to give more
flexibility to users and to keep their ability to save trajectories
during minimisations. But I'm not sure what you mean by care in choosing
ntwx. If ntwx is an interval which is used in both the output trajectory
and the individual minimisation trajectories, what's a sensible value?
If they are probably going to be different, I suppose we might be better
off going for option #1, for the sake of simplicity.
Other thoughts?
Cheers,
Ben
--
Benjamin P. Roberts
Postdoctoral Research Associate
Quantum Theory Project
University of Florida
2301 New Physics Building #92
PO Box 118435
Gainesville FL 32611-8435
USA
Phone: +1 352 392 6712
Cell: +1 352 222 3677
Member of the Royal Australian Chemical Institute
and of the American Chemical Society
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Sep 14 2009 - 13:42:25 PDT
