One of the current pain points is related to specifying clp_constraints (type zero) where you are somewhat left 'guessing' the internals to know what target to write.
For instance, at the end of the model specification, 200 lines down from where the complex/element is fist specified you may find a clp_constraint tht looks like this:
clp_constraints:
- type: zero
target: coherent_artifact_1_artifact
interval:
- [1100, 1900]
Here coherent_artifact_1_artifact is not explicitly defined anywhere, you just need to 'know' it exists, because you have a coherent artifact, with at least order 1, named artifact. :see_no_evil: Even worse are the mixin of pfid and damped-oscillation related oscillation components. Needing to name the oscillation of doas dosc1, docs2, etc
SO that in zero constraints you can figure out that
- type: zero
target: osc2_sin
interval:
- [1450, 2000]
is related to PFID, whereas
- type: zero
target: dosc2_sin
interval:
- [1450, 2000]
is a zero constraint related to doas.
I think we could take advantage of the fact that the new library/elements definition could allow for easier close to the source definitions.
Proposed refactoring
make clp_constraints part of elements (close to target)
each elements get unique clp_constraints
bubbling up (implicit constraints) was discussed to be undesirable, so explicit it is
some excessive copy pasting could be avoid by clever use of yaml syntax
as part of implementation investigate possibility for extend mechanism to preserve (keep) constraints
(new) target can be one or more compartments, with None implicitly meaning all components in the element
Benefits
[ ] Specification of constraints (much) closer to their target (less ambiguity)
[ ] Simpler model specifcation, less error prone
Possible cons
[ ] Change w.r.t. 0.7.x API (lots of changes already anyways)
[ ] Specification of element more complex (but only a little bit)
Additional context
It should be investigated if the other constraints (equality, equal area) could benefit from a similar refactor.
One of the current pain points is related to specifying clp_constraints (type zero) where you are somewhat left 'guessing' the internals to know what target to write.
For instance, at the end of the model specification, 200 lines down from where the complex/element is fist specified you may find a clp_constraint tht looks like this:
Here coherent_artifact_1_artifact is not explicitly defined anywhere, you just need to 'know' it exists, because you have a coherent artifact, with at least order 1, named artifact. :see_no_evil: Even worse are the mixin of pfid and damped-oscillation related oscillation components. Needing to name the oscillation of doas dosc1, docs2, etc
SO that in zero constraints you can figure out that
is related to PFID, whereas
is a zero constraint related to doas.
I think we could take advantage of the fact that the new library/elements definition could allow for easier close to the source definitions.
Proposed refactoring
Benefits
Possible cons
Additional context
It should be investigated if the other constraints (equality, equal area) could benefit from a similar refactor.