On Sat, Jan 21, 2023 at 4:34 PM Barry Smith wrote:
>
> If I run KSPSetFromOptions() on an options database that contains
> -ksp_view and then push another options database that does not contain
> -ksp_view and call KSPSetFromOptions() again it undoes the previous setting
> of that viewer. So -
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
> On Jan 22, 2023, at 12:45 PM, Matthew Knepley wrote:
>
> On Sat, Jan 21, 2023
On Sun, Jan 22, 2023 at 1:06 PM Barry Smith 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 i
Matthew Knepley writes:
> On Sun, Jan 22, 2023 at 1:06 PM Barry Smith 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_r
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
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 writes:
> ALL the other options are sticky. Calling setFromOptions() twice does not
> change the value of rtol etc etc etc that w
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_v
> 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 wr
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 wrote:
>
>> But
