Hi, Ben, Andy,
Andy is correct. The place to save intermediate xmin steps is where
the new gradient is computed forcing a non-bonded update. Gradient
evaluations using the old non-bonded list are called from within the
line searching routine and it makes no sense to save those trial steps.
It is also true that an xmin restart from a saved intermediate step
would not be identical with an uninterrupted xmin search since
preconditioning and other pieces of information will be lost, but this
is not crucial, the restart would require a few more steps to
converge, but that's all. I understand Ben's concern and it would be
addressed by this simple "checkpointing".
Best wishes,
Istvan
Quoting Andreas Goetz <agoetz.sdsc.edu>:
> Hi Ben, Istvan,
>
>>>>> I'm trying to include writing restart and trajectory files in
>>>>> the XMIN algorithm, initially for my use in QM/MM calculations,
>>>>> so I can save files at each step instead of having to go back to
>>>>> the start if the calculation fails (since each step may take an
>>>>> hour or more).
>>>>>
>>>>> My initial solution, which works passably well, was to call
>>>>> minrit and corpac (based on ntwr and ntwx) at the end of the
>>>>> main do loop in run_xmin. (At the moment, this is only done if
>>>>> run_xmin is called directly, not from run_lmod.) This is based
>>>>> on n_force_calls. The problem is that some steps do more than
>>>>> one force call, so that a trajectory written on every force call
>>>>> contains more steps than the corresponding mdout file. Ideally,
>>>>> the steps counted to determine ixdump and itdump would be those
>>>>> that are counted for mdout-writing purposes.
>>>> Each xmin step does a line search which requires several gradient
>>>> evaluations (force calls). You don't want to write coordinates during
>>>> the line search but only for each new xmin step.
>>>>
>>>>> Inside the do loop, I can see a rather complicated case switch,
>>>>> and it's not obvious to me which branches start a new "step",
>>>>> and which ones do another force evaluation within the same
>>>>> "step". Could anyone clarify which is which? I would guess that
>>>>> "case (CALCENRG_NEWNBL, CALCGRAD_NEWNBL, CALCBOTH_NEWNBL)" does
>>>>> not do a new step and that "case (CALCENRG_OLDNBL,
>>>>> CALCGRAD_OLDNBL, CALCBOTH_OLDNBL)" does, but I'm not certain...
>>>> As far as I can see, a new xmin step is done for
>>>>
>>>> case ( CALCENRG_NEWNBL, CALCGRAD_NEWNBL, CALCBOTH_NEWNBL )
>>>>
>>>> which is also when the minimization progress is printed. This is where
>>>> you want to write the coordinates.
>>>>
>>>> All the best,
>>>> Andy
>>
>> I'm trying to use XMIN to do QM/MM minimisations with PUPIL. If I'm
>> doing, for example, a large QM region (70+ atoms) at the DFT level,
>> a single force evaluation may take an hour or more. Hence, I would
>> like to be able to save a restart file often, up to every step.
>>
>> Furthermore, I would like to be able to write trajectories (mdcrd
>> or netcdf), again up to once per mdout step, so I can see what's
>> happening in the system over "time".
>>
>> At the moment, as outlined, it's doing every force evaluation. But
>> the problem there is that a single step (as counted in the mdout
>> file) may have multiple force evaluations, and it's not obvious
>> when one step begins and ends. Nor is it obvious that a restart
>> file generated in such an "intermediate" force evaluation is safe
>> to pick up and run with if things bomb out.
>>
>> So I would like to have a way to write restrt and mdcrd frames
>> based on steps as counted in the mdout file.
>
> I think you can proceed as I described in my earlier post. You will lose
> information from the minimizer, though, if you only write the
> coordinates. It would be nice if Istvan could comment on this as I am
> not familiar with the internal structure of the xmin code.
>
> All the best,
> Andy
>
> --
> Dr. Andreas W. Goetz
> San Diego Supercomputer Center
> Tel : +1-858-822-4771
> Email: agoetz.sdsc.edu
> Web : www.awgoetz.de
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue May 11 2010 - 01:00:03 PDT
