docs: update NEWS.md

[AayushSabharwal]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Add any other context about the problem here.

[baggepinnen]

One might then ask, why does the default value of a parameter dictate how it can be used? This implies that the default is more than a default, it also has a semantic meaning, more akin to ~ than a default.

I'm not quite happy with this new limitation, it has been very useful to set defaults based on other parameters but later allow the value to be changed by the user. An example where this comes up is in model-based controllers, where it makes a lot of sense to default all the parameters in the controller to be the same as in the system it is controlling, but also to over ride the defaults to verify robustness w.r.t. model errors. Am I now forced to split = false to have this possibility?

[AayushSabharwal]

It makes sense then to not handle things this way. What other API would you propose for this behavior? A separate parameter_dependencies keyword for the system constructor?

[baggepinnen]

What was the problem you tried to solve by introducing this limitation? The previous semantics worked fine for at least some usecases (I'm sure it had problems as well). I'd argue that a default that depends on another variable does not make the parameters dependent on each other, it's only the default values that depend on each other.

[ChrisRackauckas]

The problem that is being solved is correctness. If someone says p1 ~ 2*p2 then we need to make sure it's correct. Right now there's downstream correctness fixes but those are being pushed to here so that code is correct.

[baggepinnen]

p1 ~ 2*p2 is an equation and that's not the case we're discussing here, we are talking about default values.

[baggepinnen]

unless overriden in downstream construction

This is what I want to keep allowing, but the text in NEWS.md suggests this will no be allowed

Parameters that have a default value depending on other parameters are now treated as dependent parameters. Their value cannot be modified directly.

[AayushSabharwal]

@parameters p1 = 1.0 p2 = 1.0
@variables x(t) = 1.0
@mtkbuild sys = ODESystem([D(x) ~ p1 * t + p2], t; parameter_dependencies = [p2 => 2p1])

prob = ODEProblem(sys, [x => 2.0], (0.0, 1.0), [p1 => 2.0])
@test prob.ps[p1] == 2.0
@test prob.ps[p2] == 4.0
prob.ps[p1] = 3.0
@test prob.ps[p1] == 3.0
@test prob.ps[p2] == 6.0

ps = prob.p
buffer, repack, _ = canonicalize(Tunable(), ps)
@test only(buffer) == 3.0
buffer[1] = 4.0
ps = repack(buffer)
@test getp(sys, p1)(ps) == 4.0
@test getp(sys, p2)(ps) == 8.0

replace!(Tunable(), ps, [1.0])
@test getp(sys, p1)(ps) == 1.0
@test getp(sys, p2)(ps) == 2.0

ps2 = replace(Tunable(), ps, [2.0])
@test getp(sys, p1)(ps2) == 2.0
@test getp(sys, p2)(ps2) == 4.0

Is this an acceptable API?

[ChrisRackauckas]

I think the text is just an odd explanation of it. It's that if you set p2 ~ 2*p1 then it's structurally set as non-tunable (to enforce the constraint), but in problem construction you can p2 => 1.5 override.

[AayushSabharwal]

You can't actually 😓 the parameter indices and associated metadata are finalized during complete, so they can't be changed after that.

[TorkelE]

I agree with @baggepinnen That having a parameter just be a simplified expression for other stuff, and having a default value, are two different things, and ideal should be kept that way.

Have it been checked how this affect setting default initial conditions that are parameters? E.g. X = X0 (where X is a variable and X0 a parameter?