On Thu, 2013-11-21 at 13:24 -0200, Gustavo Seabra wrote:
> On Thu, Nov 21, 2013 at 11:53 AM, Jason Swails
> <jason.swails.gmail.com> wrote:
>
> On Thu, 2013-11-21 at 09:00 -0500, Brian Radak wrote:
> > I always did find that to be the most frustrating of
> mistakes...
> >
> > Would it be possible to add a warning if a qmmm namelist is
> present but
> > ignored (*i.e.* ifqnt = 0)?
>
> If ifqnt is explicitly set to 0 in the input file, I don't
> think any
> warning should be issued---it is quite easy to imagine use
> cases when a
> user would want to disable QM/MM and _not_ delete their entire
> QM/MM
> namelist.
>
> It's pretty easy to add a warning if ifqnt is not set in
> &cntrl but
> &qmmm is present. Perhaps this is not going far enough,
> though. The
> available options for when &qmmm exists but ifqnt is not set
> are:
>
> 1) Just print a warning to the mdout but carry on with no
> change to the
> existing default behavior.
>
>
> That's not very different from what happens now. If QM is on, there is
> already a bunch of different info printed out that just isn't there
> otherwise. That alone should tell the user QM is on. The absence of
> this information already tells QM is off.
Determining what happened based on what is NOT printed is far less
reliable than determining what happened based on a message that IS
printed. The latter is also quite a bit more friendly to new users.
> 2) Quit with an error, forcing users to either set ifqnt=0 or
> delete the
> &qmmm namelist to disable QM/MM.
>
>
> That's bad. Very bad. Very ofter we turn QM on and off to test things,
> and that's the beauty of the current implementation: you can have a
> ready input file, and just change a switch to have QM on. Want to try
> a MM run? change the switch back.
This is only triggered if the &cntrl namelist does not have ifqnt
specified at all. You can still put ifqnt=0 and run a simulation with
no QM/MM even if it has a &qmmm namelist. Any input files that this
change 'breaks' could be fixed by adding "ifqnt=0" to the &cntrl
namelist.
> 3) Change the default behavior so that the default value of
> ifqnt is 1
> if &qmmm is present and 0 otherwise.
>
>
> That would break all sorts of things, and old inputs would stop
> working as they were supposed to.
Again, not saying &qmmm being present triggers QM/MM -- just that QM/MM
being present and ifqnt NOT being in &cntrl triggers QM/MM. I'm not
personally a fan of 3, I just included it as an option for completeness.
> I'd say that *if* we want anything different, it must be (1), with a
> simple, one-line message. But I really fail to see the advantage.
The advantage lies in typical user intent. If a user goes through the
trouble of defining a QM/MM namelist but then does not explicitly tell
sander whether or not to use QM/MM, is it more likely that they simply
forgot to put ifqnt=1 or that they were relying on the ifqnt=0 being the
default to disable QM/MM? If the former is far more likely, then I
imagine users would rather find out about their mistake _before_ running
simulations than after their (potentially lengthy) simulation has ended.
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Nov 21 2013 - 08:00:03 PST
