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....@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 <bsm...@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 <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). >> >
