Is there a way to change a single parameter in am ODEproblem and rerun it?

I do define a model with a set of parameters that comes from the default settings for the components.

I then want to change a parameter and rerun the problem.

I could of course set up a parameter input map

p = [
p1 => 1
p2 => 2
p3 => 3
p156 => 156

and then use varmap_to_vars and remake to get the new model. And that is usually how I do it.

But in some cases I want to avoid setting up the whole parameter map, only to change one parameter, and in those cases, I’d like to have something like the CellMLToolkit method:

p = list_params(ml)
update_list!(p, :stimulus_protocol₊IstimPeriod, 250.0)
prob = ODEProblem(ml, (0, 10000.0); p=p)

Is such a thing possible for an MTK model?

What exactly is the problem with varmap_to_vars? It is runtime concerns or
is the code not nice enough for you? Using the defaults keyword, is seems pretty close to your suggested variant and you could simply define a function update_params! if you need it often.

using ModelingToolkit: varmap_to_vars

p_new = varmap_to_vars([p156 => 157.0], parameters(sys), defaults=Dict(p))
prob_new = remark(prob, p = p_new)

I did not know that keyword (I looked for the documentation on varmap_to_vars and could not find that in what I found). In the cases were I have the parameter map p as described. That will be really helpful. Thanks a lot.

However, in this case p does not exist yet. So nothing to put into defaults (if I understand your example correctly).

So I guess the question is can I get p (the input map) from parameters(sys) and prob.p, which contain the two vectors that could create that?


prob.p[156] = 157

does work, but requires me to now the order of the parameter vector (which I don’t do all the time, since the equations change between variation of models. Most of the time the parameter list stays in the same order, but not when I replace a simple model for a more complex one.

Something like:

prob.p[:p156] = 157

or (in my case):

prob.p[:AV.c1] = 0.75

where AV is the component, and c1 is the parameter to be changed, would be what I’m after.

I just realised that my (seemingly obvious) idea to switch from a parameter file, which has all parameters as global parameters that are then used in the creation of the model (so no globals within the model functions themselves) to a parameter map of the model parameters, wouldn’t be practical, since I use the different parameters (with the same valuse, so only defined once) in different models.

So I’d need separate maps for different models, since MTK/DifferentialEquations doesn’t like unused parameters in the maps.

My models have between 80 and several hundred parameters. But

  • most of them will stay at their sane defaults, which are set in the functions that create the equations
  • others will be set once at the @named component creation (from those global parameter variables) and then stay the same
  • a varying subset will be defined as the optimisation/tuning parameters.

I want to avoid having to create p with all of these hundreds of lines (error prone) and have a p that only contains the last set.

So I was wondering if there is a function like that already (like the default parameter I didn’t know about) or if I need to hack one together myself.

If there isn’t I’d put a feature request on github, and possibly have a go myself to implement it properly.

I already have a reparameterise(prob, sys, p) which takes the whole parameter map p, will add the default option to that, so it deals with partial maps as well.

That’s very helpful.

Note that sys now exists in the ODEFunction, so in theory we can setup remake to use it correctly. Just no one has done it.

1 Like

Interesting. How do I get that? I only have ODESystem and ODEProblem in my case?

so in theory we can setup remake to use it correctly. Just no one has done it.

Would that mean one could use

remake(prob, p = [p156 => 157])

in order to change only the value of p156 and leave the others as they are?

yes, if someone improves the remake dispatch. It’s in prob.f.sys.

1 Like


I’ll put that on github as a suggestion, then. Not a high priority, but I guess it would be a neat feature. Teaching is looming, so I don’t think I can dive that deep into the code (and I’m a high-level user, so the internals are all black magic to me).

1 Like