WIP: Adding @constants

[lamorton]

See #1802. The basic idea is:

• Create new @constants that are like @parameters but must have a default value
• Constants are not name-spaced, they are assumed to be globally unique (ex, μ₀ for permeability of free space doesn't belong to any particular model).
• Constants are collected from equations during generate_function & their definitions (equating the symbol to its default value) are injected into the preface of the function.

So far only ODESystems have been equipped to use @constants. Failure to handle them properly will result in an UndefVar error when attempting to call a generated function.

Initially I tried treating constants similarly to parameters: adding a cs field to the system & renamespacing them when flattening systems. However, adding a new field was breaking lots of tests b/c of the constructor signature change. If it is decided that we should go back this way, maybe making an equivalent to NullParameters so that there can be a default value for cs and making that argument to the constructor optional would be the workaround.

Other approaches I tried for replacing constants with their values:

• injecting the constant definitions into the system of equations & using structural_simplify to knock them out
• Using substitute to replace the constants with their values in the equations prior to building the function

[lamorton]

There's a bug in the CodeCov webpage for me: most of the time, when I go to the Project and try to show the dropdown code diffs, I get a spinner for a split-second and then it collapses. It worked once though, but then I refreshed and it's failing again. I have the problem on both Firefox and Chrome (I'm on Windows 10). I can't debug the CodeCov right now because of this.

[lamorton]

I'm working up some documentation & fixes for the codecov regression. Otherwise it's ready to go.

One feature we'll want to add eventually is support for substituting the constants with their literal values at the beginning of structural_simplify. This will allow further simplifications that are only possible with literals rather than symbols (eg, solution of linear equations that involve dividing by a constant).

[isaacsas]

Does this handle updating constants in events too?

[lamorton]

@isaacsas No, constants are immutable. If needs to be updated in an event, it should be a parameter, not a constant.

[isaacsas]

Sorry, I meant does the event code need to be updated to work with constants similar to the updates you made across the various system types?

[lamorton]

🤣 Got it now. I'll sprinkle some constants in test/funcaffect.jl and find out. Basically, work is needed in any places where build_function or toexpr are getting used. I ~~think~~ thought I covered my bases by fixing all the generate_callback instances for each system type.

Edit: good catch, there were some build_functions lurking in systems/callbacks.jl that I missed.

[lamorton]

@ChrisRackauckas @YingboMa The DataDrivenDiffEq failure is an upstream bug. I think the invalidations failure is also an intermittent bug with SnoopCompile. I think this is ready for review.

[ChrisRackauckas]

Yes the DataDrivenDiffEq upstream issue is known.

[lamorton]

@ChrisRackauckas Is the Invalidation failure not also a known issue? Same thing happened to Yingbo's PR and another one.

[ChrisRackauckas]

Yes it seems to be hyperactive.

[lamorton]

@ChrisRackauckas @YingboMa anything else you'd like to see prior to a review?

[YingboMa]

Thanks a lot! I will review this tomorrow.

[YingboMa]

Sorry for the late review. I just pushed some modifications to the PR.