Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

[Jed B. <je...@je...>]

Roy Stogner <roy...@ic...> writes:

> On Tue, 7 Nov 2017, John Peterson wrote:
>
>> On Tue, Nov 7, 2017 at 11:05 AM, Zack Vitoh <jan...@gm...> wrote:
>>
>>> WARNING! There are options you set that were not used!
>>> WARNING! could be spelling mistake, etc!
>>> Option left: name:-d value: 2
>>>
>>> I am wondering why I get these warnings, though.
>>
>> This is a warning from PETSc to let you know that it does not recognize
>> those command line options. That's OK because they are libmesh command line
>> options.
>
> It is kind of confusing to new users, though, isn't it?  It would be
> nice to silence.
>
> We could set -options_left to turn off the false positive warning, but
> then we might miss true positives.
>
> I wish we had a utility method to just strip our own options out of
> argc/argv before they get passed to libMeshInit.  The library could
> easily strip out all our internal "--solver_system_names",
> "--enable-fpe", etc.  options, and user and example codes could easily
> strip out argv[fixed_index] arguments...
>
> But I don't see how we could help application code strip out arbitrary
> application-specific arguments.  E.g. I really like the tricks we do
> in adaptivity_ex3/run.sh and I bet that PETSc warning would be even
> *more* confusing if it only happened on the few occasions we use such
> tricks.
>
> GetPot command-line-overriding-input-file arguments never start with a
> dash, and PETSc arguments always do except when they're values
> following a dashed argument, so we might have a method to strip out
> all non-dashed arguments unless they follow a dashed argument... but
> at this point we're talking about complicated code where mistaken
> assumptions might introduce an actual bug in an attempt to fix an
> overzealous warning.  Plus it wouldn't even *fix* all the warnings,
> because PETSc has dashed arguments with no non-dashed argument to
> follow, and users might follow one of those arguments with a GetPot
> argument.

If you have a list of options that you handle, you can use
PetscOptionsHasName(NULL, NULL, "-your-option", NULL) so that PETSc
knows it is used and won't warn about it.  Might be simpler than munging
the command line before passing it off.

> Do PETSc options ever include an =?  

No.

> We could have a method which strips out any argument with an = in
> it...
>
> Oh, but we'd *also* need to handle application-specific
> position-independent arguments which *aren't* just input file
> overrides, like the options we grab via GetPot in
> src/apps/calculator.C

PETSc doesn't process or complain about these.