Choices: Create an option for hand-wired SimpleQDefs usable in code generation

[balacij]

These are QDefinition Exprs that a software developer would have audited themselves. This option is not really any different than ODEInfos passed around, and will be usable for GlassBR rather than creating a fake IM and a fake DD to wire the interpZ and interpY usage.

This PR only makes sense in the greater context of #4664 and #4659.

[JacquesCarette]

I hate the description of this - it uses too much Drasil-speak. It doesn't help me parse what the meaning of this change is.

[balacij]

So, the rationale is this: when we look to generate code, we pull on formulas derived in the SRS and on hand-written packets of information about how problem-relevant ODEs should be solved. This PR adds support for a third option: custom formulas that a software developer would handcraft.

Are the types I used in this PR perfect? No, absolutely not (returning to this at the end). This PR is really only necessary for two things:

1. As a necessary step to unblocking drasil-code: Auto-register variables defined in Mods. #4659 with GlassBR: Move code-oriented QDefs forced into SRS to Choices as hand-wired QDefs. #4664 .
2. Better understanding what we really need from drasil-code.

Why is this something we need? Is this something we really want? It's hard to say. The reason why this is needed right now is because we don't currently support generating reading/writing code for matrices nor vectors. In the case of GlassBR, where two matrices must be read in, the variables referring to said matrices cannot be marked as inputs because of our inadequate support for their types in code generation.

• DD:calofDemand
• IM:dimlessLoad

So, what do we do instead? We create the above two models, a DD and an IM, that manually wire in matrix-reading code for them using two hand-written modules also provided through Choices. Obviously this is sub-optimal and we should be able to support this (#3355), but, we don't.

While this situation is bad: (a) we have a solution that we use in GlassBR and (b) being able to inject hand-crafted formulas or whatnot in-place of those found in an SRS from the POV of a software developer is not necessarily a bad thing. Again, it is sub-optimal, but it's not "bad" necessarily either.

Returning to my comment earlier about the types used in this PR: Are the types I used in this PR perfect? No, absolutely not. That is because they (at the very least) are not adequately discussed in greater context. We should have an equivalent "system" centred around building solutions for software problem definitions and generating an SDS. That would contain the rationale for these hand-written, un-argued formulas. We currently don't do any of that and have a weak set of "code types," so the types used in this PR continue that pattern by using types from the math-specification level (when we should be using more code-specification level types, or at least I believe).

As part of the drasil-code re-design, this will need to be re-designed as well.

[smiths]

I do not have an opinion on the implementation, but the idea @balacij is discussing makes sense to me. This is similar to the interpY and interpZ discussion (#4664). We have been faking it when we need some computing knowledge. That faking it is completely defensible, since we used it to make progress. Eventually having theories for vectors in matrices is what we want to have.

[balacij]

Thank you @smiths ! That is exactly what I mean with this. I've moved a bit of the discussion to the code as well with a link to this PR and #4664.

With that, I'm comfortable with this being ready-for-review now.

[JacquesCarette]

The feature of being able to weave in hand-written code to a Drasil-produced software solution makes sense. We should make sure that it is clearly documented as part of the process.