Hitting out of domain errors when optimizing Decapodes model

[jClugstor]

When optimizing parameters of a Decapodes model I'm running in to intermediate values that are out of domain

e.g. in the ODE function there might be something like this

var"dynamics_•4" = mag(var"dynamics_•5")
var"dynamics_•7" = n .- var"1"
var"dynamics_•3" = var"dynamics_•4" .^ var"dynamics_•7"

where it turns out that var"dynamics_•7" is less than zero for some combination of parameters, so var"dynamics_•4" .^ var"dynamics_•7" throws an OutofDomainError. I can set bounds on the parameters using Optimization.jl, but I can't prevent these intermediate values from going out of domain without manually changing the function.

I was wondering if a good solution might be to add an option to code generation that would use NANMath or something like it? That way the evaluation would return NAN if this happened.

[lukem12345]

Would a feature that allowed for arbitrary intermediate (i.e. not just top-level) variables to serve as Constants/ Parameters address this, or be useful for this particular scenario?

[jClugstor]

I don't think so, since these quantities are calculated from the model parameters and the states. The main issue is that in an unconstrained optimization the optimizer is trying parameters that are probably non-physical. Like in this case I was hitting parameters where var"dynamics_•4" turns out to be negative, so when doing the exponentiation it errors.

With something like NANMath the NAN would propagate and eventually return a NAN in the cost function, so the optimizer knows that those parameters don't work. But currently there's an error, which stops the whole optimization when one set of parameters is bad.

[jpfairbanks]

@jClugstor and I talked about this today. I understand the problem. A quick workaround would be to import NaNMath: ^ before you call gensim. Everything excep for user supplied nonlinearities shouldn't throw DomainErrors because they are just differential operators.

[jpfairbanks]

The broadcasting of arithmetic operations might be trouble because we do some normalizing of operations to get broadcasting right. But you could always define custom operators in the generate step of the compiler. If just importing NaNMath functions for the things you need to replace doesn't work, we could improve support deeper in the compiler.