That sounds reasonable. I don't like hidden options except for when
they are associated with manuscripts that have not yet been published.
If people want to make -maxwarn more difficult to use, it might be
possible to use one of the two following mutually exclusive options:
A) do not include -maxwarn in the grompp -h output, but mention it
when grompp fails with a warning, and include the warning text along
with the description of how to use -maxwarn.
B) keep -maxwarn in the grompp -h output, but add a new flag
-i_know_what_i_am_doing that does not appear in the grompp -h output.
When a user applies the -maxwarn flag, grompp terminates without
producing a .tpr file but outputs the warning about the problems that
may be associated with -maxwarn and a description that in order to use
-maxwarn, the user must also include the -i_know_what_i_am_doing flag.
I realize that option B is just pushing everything back one level from
option A, but I prefer this because then the grompp -h output is more
complete, which is especially important since a part of the .pdf
manual is autogenerated from grompp -h as I understand it.
Finally, thanks Justin and Mark for the discussion on this topic. It
is possible that I am wrong here and the original suggestion is the
best way to go. I just wanted to get my opinion out there.
Chris.
-- original message --
On 30/12/2010 4:36 AM, Justin A. Lemkul wrote:
chris.neale at utoronto.ca wrote:
Strongly disagreed. I use maxwarn all the time. If it was a hidden
option, how would I have ever known about it? Further, if it was a
hidden option, then developers would need to be very careful about
throwing warnings only in the most dire situations because the
general user would not know how to circumvent them. This is also
not optimal.
There are many things that one is capable of doing with gromacs
that are incorrect (e.g. coupling ions to their own temperature
coupling group). But there is no need to make all of these things
hidden options. As you stated, there are lots of things in gromacs
that really should not be used unless one knows the exact
consequences of doing so.
I still think allowing users to blindly override a fatal error with
a simple command line argument is potentially dangerous, but perhaps
only to the person doing it. I agree that -maxwarn can be
advantageous, but in the rare cases where one might need to use it,
that's what this list is for. There is already a distinction
between "notes" and "warnings," based upon severity. Most problems
with the input file are classified as "notes," I believe.
Perhaps there is a solution short of completely removing the option
from view (although I'm still OK with that). I have already updated
the wiki with the following:
http://www.gromacs.org/Documentation/Errors#XXX_non-matching_atom_names
Please feel free to modify as you feel would be useful.
Maybe there should be some additional error information printed when
this comes up, like an obvious message of "Please check the order of
your topology relative to your coordinate file" in conjunction with
what is already printed. Or, perhaps more generically, if a fatal
error is triggered, the user should be advised that the problem may
be severe enough that -maxwarn should not be employed.
I agree that Gromacs shouldn't attempt to supplant the users' own
sense of logic, but I don't feel like informative error messages (at
the very least) seek to do this.
Perhaps -maxwarn could stay as it is, and when it is used, a fairly
aggressive NOTE is printed at the bottom of the grompp output observes
that n things were suppressed and that unless you know exactly how and
why they arose, and thus why they can be ignored, the use of -maxwarn
can be merely delaying the appearance of a related serious problem.
Mark
--
gmx-users mailing list gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
