ModelingToolkit.jl icon indicating copy to clipboard operation
ModelingToolkit.jl copied to clipboard

Proposal for `@constants`

Open lamorton opened this issue 3 years ago • 5 comments

What if we introduced a new category of @constants, alongside @parameters? My use case is including physical constants or unit conversion factors. These don't belong in parameter vectors, especially not the anonymous conversion factors generated by the unit conversion pass.

Basically, we'd add a new metadata tag MTKConstantCtx, analogous to MTKParameterCtx. The @constants macro would require a default value. build_function would just use the default value.

This method is less flexible than something like a tag on the parameter vector (b/c it requires rebuilding the system to change a parameter to a constant). However, I want these constants to not appear in the parameter vector at all. So we'd have two different ways to make some thing constant. I'm wondering if that's too confusing.

lamorton avatar Sep 02 '22 07:09 lamorton

That's a good idea.

YingboMa avatar Sep 02 '22 15:09 YingboMa

Agreed. The same idea also exists in Modelica.

crlaugh avatar Sep 02 '22 15:09 crlaugh

Working on a prototype.

lamorton avatar Sep 04 '22 05:09 lamorton

I'm stuck on how to treat these during flattening/renamespacing. @YingboMa Do we want to assume these are global or should we allow to have different values for different subsystems? I'm leaning toward the former - if it's not global, it's not a real constant, it's just a fixed parameter.

lamorton avatar Sep 06 '22 14:09 lamorton

Prototype is here. Still needs more work before it's ready for a PR, but I'd like feedback on my strategy first.

lamorton avatar Sep 13 '22 15:09 lamorton

Done!

lamorton avatar Nov 04 '22 03:11 lamorton