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.
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.
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.
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.
Gustavo.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Nov 21 2013 - 07:30:02 PST
