Idea: Exploit hierarchical composition in simulation generation

[lukem12345]

Currently, we generate simulation code only on single Decapode objects, after oapply is performed.

However, we could take advantage of repeated sub components which only differ in the pointers to their inputs and outputs. For each node in a composition diagram for which the same Decapode is plugged in, we could compile it to a simulation helper function, which could be re-used inside the main ODEProblem function generated.

This will surely result in simulation functions with fewer total lines of code. However, it is not apparent whether this would result in more efficient generated code that the Julia compiler can optimize, or whether this could improve pre-compile times.

So, we should manually create an example of this generated code and compare. A reasonable example would use the unconnected RelationDiagram of 2 or more distinct nodes, plugging in e.g. the Brusselator Decapode for each component. (I.e. The strategy used for non-interacting multi-species Navier-Stokes.)

An occurrence of this “in the wild” is the hierarchical composition in the Non-Hydrostatic Buoyancy example, in which tracer computations for salinity and temperature are repeated:

isotropic_nonhydrostatic_buoyancy = apex(oapply(nonhydrostatic_composition, [
  Open(momentum,          [:V, :v, :b, :StressDivergence]),
  Open(isotropic_tracer,  [:continuity_V, :v, :c, :turbulence_StressDivergence, :turbulence_nu]),
  Open(isotropic_tracer,  [:continuity_V, :v, :c, :turbulence_StressDivergence, :turbulence_nu]),
  Open(equation_of_state, [:b, :T, :S])]));
to_graphviz(isotropic_nonhydrostatic_buoyancy)

[jpfairbanks]

MTK also generates code but at the scalar level. I think they generate basic blocks with on the order of 100k lines. I don't think that we are pushing the boundaries of code generation in Julia with even our biggest decapodes.

[lukem12345]

Yeah I'm wondering where the cutoff is in terms of effectively inlining with copies of the same Decapode.