On Thu, 18 Dec 2014 10:14:23 +0100
Josh Berryman <the.real.josh.berryman.gmail.com> wrote:
> Well, you get a DV/DL result out in the normal mdout file if you set
> ifsc=0, logdvdl=0
Only every ntpr steps.
> and the docs already list logdvdl under the softcore-related options,
> so its reasonable-ish to have this apply only when ifsc!=0
The docs should not be an excuse for limiting useful
_additional_ functionality. The point of logdvdl is to output the
gradients for _every_ step. There is no logical reason to limit this
to softcore runs.
> In terms of having the needed functionality, and behaviour being
> consistent with documentation, Dave's mdread2() fix is OK, however
> the need for this is a symptom of the overall state of TI
> calculations between sander and pmemd being fairly complicated and
> having something of a transitional feeling about it.
Allowing ifsc=0, logdvdl=1 now would not break current functionality (it
expands it) and is not really inconsistent with current documentation.
It just turns into an additional "hidden" feature (unless you document
it, and I don't see a reason why that should not be done).
I very much agree that the current state with two codes doing the same
think in different ways is certainly not ideal. (Funny actually,
knowing how differently free energies were being done with AMBER in the
past. How many different (setup) schemes have there been so far:
4,5?)
> I guess this is the way it is for backwards compatibility.
Backwards compatibility only means that newer version must have the
same features and behave in the same way for the functionality in the
old code. New features can be added as long as they don't break the
old ones.
> Do we need to keep supporting the old (multiple parmtop) way of doing it?
> Would a rewrite simplify both code and docs? Plenty of big clusters
> are still on AMBER12 or earlier, so bear in mind that changed made
> today may not reach users until 2020 anyway.
I'm not sure how much the availability of certain software versions on
larger installation matters. Those who need and want new features will
have their own license anyway and can freely run this wherever they
like.
Ditching the old multi-parmtop code seems attractive from the TI
perspective (I do not know for what else it is used) because it adds an
unnecessary layer of complexity for setup and of course it would make
the docs simpler (they generally would profit from some
clarifications!). But the problem, I think, is that pmemd/14 is not
fully backward compatible. Pmemd doesn't support TI simulations in
vacuum, idecomp != 0 is not supported, there may be others.
> New behaviour could be that ifsc = 0 is equivalent in output to
> ifsc=1,scalpha=0, but with the actual softcore vdw calculation being
> skipped in the code (invisibly to the user but of course saving a
> little time).
>
> Josh
>
>
>
> On 17 December 2014 at 20:27, David A Case <case.biomaps.rutgers.edu>
> wrote:
>
> > On Wed, Dec 10, 2014, Hannes Loeffler wrote:
> > >
> > > I have attached files for a sander14 run with TI/softcore. I get
> > > a segfault when I try to run this. The problem is with logdvdl =
> > > 1. When I delete this in the input files the jobs runs fine.
> >
> > The example has ifsc=0, so (at least in one sense) it is not
> > really "TI/softcore". In any event, in the current code, combining
> > ifsc=0 and logdvdl=1 won't work, because the arrays used by the
> > logdvdl option
> > are never allocated.
> >
> > Does anyone know the background here? Is logdvdl supposed to be
> > used even when ifsc=0? If so, the log_dvdl() routine should
> > probably not be in the softcore module, and (certainly) its
> > allocations should not be sc_allocate().
> >
> > For now, I've put a check in mdread2() to disallow this combination.
> > Moving the discussion over to the amber-developers list.
> >
> > ....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Dec 18 2014 - 03:00:02 PST
