# Access SNESMonitorSet in PETSc plugin
**URL:** https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925
**Category:** Feature Request
**Created:** [May 20, 2025, 10:25pm UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925 "2025-05-20T22:25:20Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@cmd](https://community.freefem.org/u/cmd)
#### Post date: [May 20, 2025, 10:25pm UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/1 "2025-05-20T22:25:20Z")
When using `TSSolve()`, we can define custom monitors using `TSMonitorSet()` as in: [examples/hpddm/heat-TS-2d-PETSc.edp](https://github.com/FreeFem/FreeFem-sources/blob/b1e524c8ca6a9b44cb9eff780459bacfc12a3ad7/examples/hpddm/heat-TS-2d-PETSc.edp#L57).
Relevant source code [here](https://github.com/FreeFem/FreeFem-sources/blob/f28642435ebbb9f9eaffa4fefbf2f53066431873/plugin/mpi/PETSc-code.hpp#L4764).
Is there already an implemented approach to do something similar with `SNESMonitorSet()` when using `SNESSolve()`? I want to avoid writing such monitors within the residual function as I am using quasi-Newton methods which evaluate the residual multiple times per iteration.
I wonder if a solution similar to the TS approach might introduce conflicts [here](https://github.com/FreeFem/FreeFem-sources/blob/f28642435ebbb9f9eaffa4fefbf2f53066431873/plugin/mpi/PETSc-code.hpp#L4712) since the current implementation already uses `SNESConvergenceTest()`?
---
### Author:  [@prj](https://community.freefem.org/u/prj)
#### Post date: [May 21, 2025, 4:27am UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/2 "2025-05-21T04:27:29Z")
I don’t foresee any issue using both a custom monitor and a custom convergence test.
---
### Author:  [@cmd](https://community.freefem.org/u/cmd)
#### Post date: [May 21, 2025, 10:13am UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/3 "2025-05-21T10:13:56Z")
Ok, but wouldn’t a naive copy of the TS monitor logic introduce an issue [here](https://github.com/FreeFem/FreeFem-sources/blob/f28642435ebbb9f9eaffa4fefbf2f53066431873/plugin/mpi/PETSc-code.hpp#L4704), since the custom convergence monitor is linked to the syntax `monitor = …`? Are there any examples I can test with that use a custom convergence test?
---
### Author:  [@prj](https://community.freefem.org/u/prj)
#### Post date: [May 21, 2025, 2:29pm UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/4 "2025-05-21T14:29:37Z")
That’s a good point. I’m not sure why the current code use the variable name `monitor` for something else that… setting a custom monitor. There should be a new named parameter, so then it would be possible to have both a custom monitor and convergence test.
---
### Author:  [@cmd](https://community.freefem.org/u/cmd)
#### Post date: [May 21, 2025, 2:45pm UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/5 "2025-05-21T14:45:36Z")
OK. I’ll draft a PR that repurposes `monitor = ...` for its stated purpose and adds a new optional parameter `convergence = ...` to support custom convergence tests. This will obviously break anything that uses custom SNES convergence monitors through the existing interface, however.
---
### Author:  [@prj](https://community.freefem.org/u/prj)
#### Post date: [May 21, 2025, 2:47pm UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/6 "2025-05-21T14:47:30Z")
I’d appreciate it. I’ll take the blame for any breakage 🙂
---
### Author:  [@cmd](https://community.freefem.org/u/cmd)
#### Post date: [May 21, 2025, 4:50pm UTC](https://community.freefem.org/t/access-snesmonitorset-in-petsc-plugin/3925/7 "2025-05-21T16:50:39Z")
Just submitted [here](https://github.com/FreeFem/FreeFem-sources/pull/343). Please let me know if you have any feedback or comments.