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 <j...@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 <bsm...@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 <j...@jedbrown.org> wrote: >>> >>> Matthew Knepley <knep...@gmail.com> writes: >>> >>>> On Sun, Jan 22, 2023 at 1:06 PM Barry Smith <bsm...@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).