[petsc-dev] PetscOptionsGetViewer() problems with multiple usage on the same object but different options databases

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Sun, Jan 22, 2023 at 1:06 PM Barry Smith <bsmith at petsc.dev> wrote:
>
>>
>>   That makes incrementally adding new options to an existing object
>> difficult, since each call to setFromOptions() screws up previous calls.
>>
>> We already have
>>
>> -ksp_monitor_cancel
>> -ksp_converged_reason_view_cancel
>>
>
> Let me address it another way. If I understand correctly, what happens
> currently is that at each ViewFromOptions() call, the database is inspected
> and if a *_view is found, then the view is executed. So when you replace
> the database, if this option is not found then nothing happens. This seems
> to satisfy a kind of options locality. If instead we make some options
> sticky, like -ksp_view, so that once given they never expire, this would
> make the code exceedingly hard to reason about, especially if options are
> set deep inside something, before a user is knowingly doing things. This
> does not sound like the right model to me.

We could have something like PetscOptionsMerge() if one wants to preserve previously set options while adding some new ones (without tainting the global database). I don't like stickiness in general (a key reason why CMake is impossible to reason about and best practice is to run rm -rf * && cmake .. -DALL_THE_OPTIONS).