-
Notifications
You must be signed in to change notification settings - Fork 35
Datum access #704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datum access #704
Conversation
Codecov Report
@@ Coverage Diff @@
## master #704 +/- ##
==========================================
+ Coverage 79.74% 80.02% +0.28%
==========================================
Files 38 38
Lines 2839 2854 +15
==========================================
+ Hits 2264 2284 +20
+ Misses 575 570 -5
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also update the "docs/src/internals/strucutres_3_instances.md" file just to reflect the two new fields for CompositeComponentInstances?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! The one thing I'm wavering on now is whether parameters
and variables
are the best names for the new fields in the ComposteComponentInstance
. Maybe it should be something like parameter_refs
instead. But maybe we should just merge this now and then open a new issue to ask David's thoughts on that later?
Hmm so would the idea of not naming them |
yeah mostly the second point-- just that they don't actually store parameter/variable values, but references to them. minor point, but I feel like David would have a clear opinion on it so we could just revisit it later! |
#677
Currently we have implemented the methods and constructors needed to access parameters and variables in the top level composite components of a model with a call like
next steps are to add more comprehensive testing and think about corner cases like renaming. also, do we want to be able to use this syntax for lower levels i.e. if
:B
is a child composite component of:top
but not in thecomps_dict
ofm.mi
, should we be able to do