# Is \`callback\` really compatible with NonlinearProblem?

**URL:** https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332
**Category:** Numerics
**Tags:** nonlinearsolve
**Created:** [December 3, 2025, 4:19pm UTC](https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332 "2025-12-03T16:19:24Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![bmxam](https://avatars.discourse-cdn.com/v4/letter/b/b38774/32.png) [@bmxam](https://discourse.julialang.org/u/bmxam)
#### Post date: [December 3, 2025, 4:19pm UTC](https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332/1 "2025-12-03T16:19:24Z")

</div>

Hi everyone,

According to the documentation ([Nonlinear Problems · NonlinearSolve.jl](https://docs.sciml.ai/NonlinearSolve/stable/basics/nonlinear_problem/#SciMLBase.NonlinearProblem)), “_if you set a callback in the problem, then that callback will be added in every solve call_”. So **I tried to add a callback but nothing seems to happen** , see the following example.

```julia
using NonlinearSolve

f(u, p) = u .* u .- p
u0 = [1.0, 1.0]
p = 2.0
prob = NonlinearProblem(f, u0, p; callback = x -> error("hello world"))
sol = solve(prob) # nothing special happens

condition(args...) = true
affect!(integrator) = error("hello world !")
cb = DiscreteCallback(condition, affect!;)
prob = NonlinearProblem(f, u0, p; callback = cb)
sol = solve(prob) # nothing special happens

```

I saw on discourse the use of `termination_condition`, do you recommend to tweak this callback to insert what I want to do and return a termination condition? Or should I use the `step` interface to take control of the iterations and insert my callback?

PS : I’m using NonlinearSolve version 4.12.0

---

<div class="post-metadata">

### Author: ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [December 3, 2025, 6:55pm UTC](https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332/2 "2025-12-03T18:55:27Z")

</div>

Yeah, pretty sure that’s a doc bug. @ChrisRackauckas can you confirm?

---

<div class="post-metadata">

### Author: ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [December 3, 2025, 10:22pm UTC](https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332/3 "2025-12-03T22:22:24Z")

</div>

yes that is a docs issue

---

<div class="post-metadata">

### Author: ![bmxam](https://avatars.discourse-cdn.com/v4/letter/b/b38774/32.png) [@bmxam](https://discourse.julialang.org/u/bmxam)
#### Post date: [December 5, 2025, 10:02am UTC](https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332/4 "2025-12-05T10:02:37Z")

</div>

Would it be a problem to append a callback(s) call right after the `CommonSolve.step!` call (I mean here : [NonlinearSolve.jl/lib/NonlinearSolveBase/src/solve.jl at d47550f65edf7285368b4975ad44922f47841f3c · SciML/NonlinearSolve.jl · GitHub](https://github.com/SciML/NonlinearSolve.jl/blob/d47550f65edf7285368b4975ad44922f47841f3c/lib/NonlinearSolveBase/src/solve.jl#L284))?

I’m not confortable to open a PR since I’m not familiar with the project architecture (moreover, this feature may not be something you guys want).

---

<div class="post-metadata">

### Author: ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [December 5, 2025, 12:07pm UTC](https://discourse.julialang.org/t/is-callback-really-compatible-with-nonlinearproblem/134332/5 "2025-12-05T12:07:45Z")

</div>

it would need a proper interface based on the cache type, and that cache type would need to document its API. Doable, and something that should get done, but not in the library yet.
