[gmx-users] making maxwarn a hidden option

[chris.neale at utoronto.ca]

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