[gmx-users] Feedback wanted - mdp option for preparation vs production

Mark Abraham mark.j.abraham at gmail.com
Fri Aug 24 16:22:30 CEST 2018


Hi,

There's other examples, e.g. freeze groups, pressure coupling with position
restraints, maybe position restraints generally, generating velocities,
size of steps, time constants of coupling algorithms. Obviously we can
always improve docs and messages, but equally users aren't always going to
read them. :-)

How does the consideration of needing to discard a fraction of a production
run (e.g. with trjconv -b) matter?. The point of the new option (which
defaults to production for backwards compatibility) is to avoid people
building the habit of using -maxwarn 99 when they needed to get their
pre-production grompp calls to always work (particularly in scripted
workflows).

Mark

On Fri, Aug 24, 2018 at 4:11 PM Szilárd Páll <pall.szilard at gmail.com> wrote:

> The thermostat choice is an easy example where there is a clear case to be
> made for the proposed mdp option, but what other uses are these for such an
> option? Unless there are at least a few, I'd say it's better to improve the
> UI messages, option documentation, manual, etc. than introduce a ~
> single-use option than to force users to set an option that may not even be
> relevant (e.g. equilibration is simply chopped of with -b).
>
> --
> Szilárd
>
>
> On Fri, Aug 24, 2018 at 3:36 PM Paul bauer <paul.bauer.q at gmail.com> wrote:
>
> > To add my 2 cents to the discussion, I think having the explicit switch
> > between preparation and production runs will be definitely useful for
> > users, and I think it will also make it easier to rework the input
> > settings if we can simply have one check at the beginning that
> > determines if we are harsh in denying the use of options or not. As an
> > additional bonus, I think mdrun could decide based on this setting if it
> > is more bold in stating if options are wrong or not, something that gets
> > lost when people just default to use maxwarn as an option for grompp to
> > make errors go away.
> >
> > Cheers
> >
> > Paul
> >
> > On 24/08/2018 15:26, Justin Lemkul wrote:
> > >
> > >
> > > On 8/24/18 9:09 AM, Mark Abraham wrote:
> > >> Hi,
> > >>
> > >> You can't prevent misuse... give someone a scalpel and they might
> lose a
> > >> finger! The key targets for helping are the newer users who don't
> > >> have the
> > >> experience to know which way to hold the scalpel. If they can be
> > >> trained to
> > >> use these flags (e.g. because they see them in their tutorials) then
> the
> > >> warnings can have the intended effect. One can mitigate the impact of
> > >> someone always running in the least safe mode by reporting on that to
> > >> the
> > >> log file, so that they'll see it, and so will their collaborators, or
> > >> their
> > >> peers when they archive and share their results.
> > >
> > > I also think there's value in having a user go into an .mdp file and
> > > set "stage = preparation" because now they (presumably) know that what
> > > they are doing is applying an algorithm that is intended for a
> > > preparatory process. If we require a user to simply add -maxwarn 1 to
> > > their grompp command, the user begins to think "yeah, that's how I can
> > > make that error go away." The former requires scientific thought, the
> > > latter emboldens carelessness.
> > >
> > > For those wondering the backstory, I started a Redmine at
> > > https://redmine.gromacs.org/issues/2622 because I felt we were a bit
> > > harsh in making the use of Berendsen a warning, because we also
> > > caution users against using Parrinello-Rahman for equilibration. So if
> > > one shouldn't use Parrinello-Rahman and *can't* use Berendsen, what
> > > conclusion is the user to make about performing equilibration? In this
> > > case, it's acceptable to use Berendsen, if and only if the user
> > > acknowledges that the resulting ensembles are wrong and therefore
> > > should not be collected as real data.
> > >
> > > -Justin
> > >
> > >> Mark
> > >>
> > >> On Fri, Aug 24, 2018 at 2:48 PM Victor Rosas Garcia
> > >> <rosas.victor at gmail.com>
> > >> wrote:
> > >>
> > >>> El jue., 23 ago. 2018 a las 17:03, Mark Abraham
> > >>> (<mark.j.abraham at gmail.com
> > >>>> )
> > >>> escribió:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> [snip, snip]
> > >>>> Despite this, there are times when one might want to use such an
> > >>> algorithm,
> > >>>> and so we permit users to suppress warnings from grompp with
> -maxwarn.
> > >>>> However, encouraging such behaviour leads to people abusing
> > >>>> -maxwarn, and
> > >>>> we'd all like to avoid that.
> > >>>>
> > >>>> [snip, snip]
> > >>>> Following discussion among some developers, how do people feel
> about a
> > >>> new
> > >>>> mdp option that permits users to specify e.g. "production" or
> > >>>> "preparation," defaulting to "production." grompp retains its
> current
> > >>>> warning behaviour for "production," but merely advises about such
> > >>>> issues
> > >>>> when preparing systems. Do those names and behaviours seem
> > >>>> suitable? Do
> > >>> we
> > >>>> need more flavours of calculation type?
> > >>>>
> > >>>> Hello Mark,
> > >>> First of all, thanks for all the time and effort you put into these
> > >>> matters.
> > >>>
> > >>> Regarding these new flavours of calculation, how will these new
> > >>> flavours
> > >>> prevent abuse?  If people are abusing -maxwarn, what will keep these
> > >>> same
> > >>> people from using always "preparation" to suppress the warnings?
> > >>> GROMACS
> > >>> is a great program but in the end, it boils down to the fundamental
> > >>> question "do you want to do a good job or a bad job?" I'm all for
> > >>> getting
> > >>> clearer error messages and more complete warnings (sometimes I have
> > >>> learned
> > >>> from them).
> > >>>
> > >>> just my 2 cents
> > >>>
> > >>> Victor
> > >>> --
> > >>> Gromacs Users mailing list
> > >>>
> > >>> * Please search the archive at
> > >>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> > >>> posting!
> > >>>
> > >>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >>>
> > >>> * For (un)subscribe requests visit
> > >>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> or
> > >>> send a mail to gmx-users-request at gromacs.org.
> > >
> >
> > --
> > Gromacs Users mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> > posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> > send a mail to gmx-users-request at gromacs.org.
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.


More information about the gromacs.org_gmx-users mailing list