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
Received on Mon May 10 2010 - 12:00:06 PDT
