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

[Barry Smith]

  It is not a temporary solution, it is a solution that does not also encompass the desired ability to remove a selected viewer; this functionality doesn't exist today anyways :-) so my change is in the correct direction :-).

On Jan 22, 2023, at 8:25 PM, Jacob Faibussowitsch <jacob.fai at gmail.com> wrote:
> 
>> But I'd like a short term solution for the current design bug, so I'll eventually try a minimal change to the code.
> 
> There is nothing is more permanent than a temporary solution.
> 
> Best regards,
> 
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> 
>> On Jan 22, 2023, at 20:12, Barry Smith <bsmith at petsc.dev> wrote:
>> 
>> 
>> One can turn on a multitude of viewers with ad hoc names at the same time like -ksp_view_solution.
>> 
>> My eventual hope is to consolidate them with an additional part of the argument, for 
>> example -ksp_view :::solution then one could have -ksp_view :::solution:cancel and something like -ksp_view :::ALL:cancel to cancel all of them.
>> 
>> But I'd like a short term solution for the current design bug, so I'll eventually try a minimal change to the code.
>> 
>> 
>> 
>>> On Jan 22, 2023, at 7:59 PM, Jed Brown <jed at jedbrown.org> wrote:
>>> 
>>> Can we have a -xxx_view none or null to unset the view? Could even be a viewer type that does nothing. I don't like the out-of-band -xxx_view_cancel.
>>> 
>>> Barry Smith <bsmith at petsc.dev> writes:
>>> 
>>>> ALL the other options are sticky.  Calling setFromOptions() twice does not change the value of rtol etc etc etc that was set the last time and even -ksp_monitor is sticky, why are the viewers so special in that they are the only ones that are not sticky? Is not consistent, doesn't make sense, when -ksp_monitor is sticky. It is just a freak feature of the implementation of PetscOptionsGetViewer() that no one realized was there when they wrote it (probably me :-)).
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Jan 22, 2023, at 1:16 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>> 
>>>>> 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).
>> 
>