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

[Roy S. <roy...@ic...>]

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.

Do PETSc options ever include an =?  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

This is sounding less and less sane; I give up.
---
Roy