more robust detection of analysis-point variable #134
Conversation
Codecov Report
@@ Coverage Diff @@
## main #134 +/- ##
==========================================
- Coverage 65.34% 65.25% -0.09%
==========================================
Files 33 33
Lines 1434 1439 +5
==========================================
+ Hits 937 939 +2
- Misses 497 500 +3
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| namespace[] = ns | ||
| apr[] = ap | ||
| (ap.out.u ~ ap.in.u + d), d | ||
| (ap_var(ap.out) ~ ap_var(ap.in) + d), d |
There was a problem hiding this comment.
Should we also compare that their variable names equal?
There was a problem hiding this comment.
If there is only a single variable, I figured it was unambiguous no matter what it was called. If there were more than one variable, I threw an error instead. This happens already in the ap_var function.
The reasoning for allowing any one variable is to make it more likely that it will work for user-defined components etc. without the user having built the components using our RealInput/RealOutput components.
There was a problem hiding this comment.
Making the matching based on name rather than type is a bit unfortunate in any case. An alternative approach would be to store the variable name in the analysis point, and default to u if none was provided. I'm not sure for about how the syntax for this would look though.
Analysis points are supposed to be used with
RealInput/RealOutput, and those both have an inner variable calledu. This PR attempts to connect other kinds of components as well, but throws an error if there is more than one state variable, in which case which one is referred to by the AP is ambiguous.