It’s a special enough case that NonlinearProblem((du,p,t)->prob.f(du,u,p,0.0), prob.u0) is fine. It’s not more than one line of code.
Thank you very much @ ChrisRackauckas, ,the pretty-good solution.
prob3 = NonlinearProblem((du,u,p)->prob.f(du, u, p, 0.0), prob.u0)
sol2 = solve(prob3, NewtonRaphson())
Sorry for reviving this, but is there a way in recent ModelingToolkit releases to build a similar NonlinearProblem based on prob directly ? The solution you proposed loses the “indexing by name” capability of ModelingToolkit solutions, and I would like to avoid rebuild all values by hand.
I can open a new topic if required.
Open an issue on ModelingToolkit if you have an example to solve. Using SteadyStateProblem constructor should just work and is tested. And it should support symbolic indexing. So my guess is that this is all solved by now unless there’s a bug that you’re specifically hitting that we don’t know about, hence an issue.
Hum, I do not have a simple model to show this right now and I do not think it warrants and issue.
It looks like I have the same need as the OP, which seems to be : solve the initialization problem at some given initial condition imposed for one of the variables.
SteadyStateProblem seems not to enforce this initial constraint on part of the solution.
Right now I solved this by adding some kind of multiplier to omptimize in an OptimizationProblem to fulfill this initial constraint, but that feels far-fetched.
I will try and open a new topic and link this one.
Interesting. All of the problem types (SteadyStateProblem, OptimizationProblem, NonlinearProblem) should be running the initializer these days. For non-ODEs, the initialization is just parameter initialization though, since they are non-dynamic.
Ok, let me assemble some MWE in a new topic and we will continue the discussions there.