we could make users select a leaprc as part of their installation, but
still suggest which one to use as the default. for clarity it could still
be named with appropriate details.
On Mon, Mar 9, 2015 at 8:20 AM, Jason Swails <jason.swails.gmail.com> wrote:
> On Sun, Mar 8, 2015 at 9:18 PM, Jason Swails <jason.swails.gmail.com>
> wrote:
>
> >
> > On Mar 8, 2015, at 3:40 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> >
> > I would like there to be a 'default' force field that is either:
> >
> > 1) Loaded by leap by default.
> >
> > 2) Loaded with 'source leaprc.default'
> >
> > This would make things a lot simpler for beginning users. Option 1 might
> > prove troublesome since I don't know how well one can unload parameter
> sets
> > in leap if you wanted to switch things out so option 2 with documentation
> > might be optimal.
> >
> >
> > I think choosing a force field should be deliberate. (1) is already
> > possible if you decide what force field you like best and name that file
> > “leaprc”. (2) is also avoiding a deliberate choice. Deliberation
> > reinforces the importance of choosing a force field, even if they just
> pick
> > the one we suggest they use (because the act of typing “source
> > leaprc.ff14SB” tells them what they’re using).
> >
> > I think better tutorials (like B0 from Ben and you) are more important
> > than providing a way of putting off (indefinitely?) learning about the
> > concept of force field choices and selection.
> >
>
> I was thinking about this some more, and I keep going back and forth. I'm
> warming to the idea of (1), but it worries me. Our general promise is
> that, so long as features are supported, running a protocol with Amber 12
> and then again with Amber 14 will produce the same (note, not *identical*)
> results. If we start the practice of providing a 'default' leaprc that
> changes every version, this is no longer true. How important is that? It
> seems like it would be easy enough to explain, but could be potentially
> confusing. We'd also have to change our 'promise' (which has been stated
> on the Amber mailing list, but nowhere 'official' to my knowledge) to
> exclude the prmtop generation stage in terms of both forwards- and
> backwards-compatibility.
>
> All the best,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> 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 Mon Mar 09 2015 - 05:30:04 PDT
