I would say this is a bug in petsc4py, the following diff should fix this.
I’m not sure why this if is there, as it’s perfectly valid to call
PetscOptionsClear(NULL).
Thanks,
Pierre
diff --git a/src/binding/petsc4py/src/petsc4py/PETSc/Options.pyx
b/src/binding/petsc4py/src/petsc4py/PETSc/Options.pyx
index 4db3c52f022..8a923a6dd8e 100644
--- a/src/binding/petsc4py/src/petsc4py/PETSc/Options.pyx
+++ b/src/binding/petsc4py/src/petsc4py/PETSc/Options.pyx
@@ -90,7 +90,6 @@ cdef class Options:
def clear(self) -> Self:
"""Clear an options database."""
- if self.opt == NULL: return
CHKERR(PetscOptionsClear(self.opt))
return self
> On 27 Oct 2025, at 10:23 AM, SCOTTO Alexandre via petsc-users
> <[email protected]> wrote:
>
> Dear PETSc Community,
>
> In my developments, I am managing possibly several KSP solvers with options
> handled by the Options database. During my tests, I encountered the following
> behavior:
>
> Code:
> options = PETSc.Options("ksp_")
> options.setValue("atol", 7e-8)
> options.view()
>
> options.clear()
> options.view()
>
> Output:
> #PETSc Option Table entries:
> -ksp_atol 7e-08 # (source: code)
> #End of PETSc Option Table entries
>
> #PETSc Option Table entries:
> -ksp_atol 7e-08 # (source: code)
> #End of PETSc Option Table entries
>
> It seems that the clear() method does not really clear the Option database.
> To ensure that the several KSP I deal with are set with their own options
> (without getting options from a KSP previously set), the only way I found was
> to explicitly call the delValue() method for all the option keys passed:
>
> 1. Iterate over a dictionary of options and use setValue(name, value)
> 2. Set the KSP with option database: KSP.setFromOptions()
> 3. Iterate over a the keys of the dictionary and use delValue(name) to
> effectively clear the option database.
>
> Does it seem normal to you, is there something I am missing out?
>
> Regards,
> Alexandre Scotto.
