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