-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
Zerod connector nodes #1848
base: main
Are you sure you want to change the base?
Zerod connector nodes #1848
Conversation
10b7038
to
eefe4ca
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1848 +/- ##
==========================================
- Coverage 74.41% 74.35% -0.06%
==========================================
Files 386 387 +1
Lines 53628 53631 +3
Branches 9063 9068 +5
==========================================
- Hits 39905 39876 -29
- Misses 10652 10686 +34
+ Partials 3071 3069 -2 ☔ View full report in Codecov by Sentry. |
3ca0fab
to
3822451
Compare
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.
Thanks for separating this out, @ischoegl. I think introducing the ConnectorNode
object type is useful and avoids some repetition. Broadly, though, the interface for the different derived types of connectors is different enough that I think the interface for using them should continue to be through objects of those particular types to avoid the need for dynamically casting to the derived types, both internally and for external users.
* In a reactor network, walls and flow devices (valves, pressure regulators, etc.) | ||
* form edges of a directed graph that connect reactors that form nodes. |
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.
This seems to get into the nomenclature question -- are connectors nodes (vertices) as the name ConnectorNode
implies, or edges, as described here?
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.
I corrected this based on the discussion in Cantera/enhancements#213 (comment)
//! Pair of reactors forming end points of the connector. | ||
pair<shared_ptr<ReactorBase>, shared_ptr<ReactorBase>> m_nodes; |
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.
I don't think the pair
adds much here -- two separate member variables ends up being easier to use.
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.
I have a (slight?) preference for pair
as it is a directed graph, where a ConnectorNode
connects to exactly two reactors. As it is an implementation detail, we can always adjust at a later point.
test/zeroD/test_zeroD.cpp
Outdated
auto edge = newConnectorNode("Valve", node0, node1, "valve"); | ||
ASSERT_EQ(edge->name(), "valve"); | ||
|
||
auto valve = std::dynamic_pointer_cast<FlowDevice>(edge); | ||
ASSERT_EQ(valve->in().name(), "upstream"); | ||
ASSERT_EQ(valve->out().name(), "downstream"); | ||
|
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.
The fact that you can do almost nothing with a ConnectorNode
without having to std::dynamic_pointer_cast
it to a more derived type tells me that we should largely be hiding newConnectorNode
from users. The preferred interface would then either be the newWall
and newFlowDevice
functions, or just expecting them to use make_shared<Wall>(...)
and the like.
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.
I created two new versions of newWall
and newFlowDevice
that use reactors as parameters and deprecated the old versions.
try { | ||
return WallCabinet::at(i)->area(); | ||
return ConnectorCabinet::as<Wall>(i)->area(); | ||
} catch (...) { | ||
return handleAllExceptions(DERR, DERR); |
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.
Especially as we move toward the generated clib
, I'm not sure it's worth jamming more disparate types into the same Cabinet
.
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.
The generated CLib uses exactly one header file for all class specializations - all use the same Cabinet
(at least in the current implementation, which of course may be refined as the project progresses). My plan for zeroD
is to establish two node types - ConnectorNode
and ReactorBase
(potentially renamed ReactorNode
for consistency). As ReactorNet
is another required class, the CLib interface would be implemented using three headers.
fix doxygen for flowdeviceGroup
3822451
to
967735b
Compare
Add newWall and newFlowDevice with reactors as parameters, and deprecate old versions.
The C++ class does not inherit from WallBase.
967735b
to
c791052
Compare
@speth - Thank you for the review (and for catching some pre-3.1 remnants of #1788). I believe your comment regarding not restricting the interface to |
Changes proposed in this pull request
This PR pulls out the less controversial modifications from #1788, while improving the nomenclature (see Cantera/enhancements#213 (comment)):
ConnectorNode
base, which combineWall
andFlowDevice
objects; all objects are captured in updated factories.If applicable, fill in the issue number this pull request is fixing
Addresses Cantera/enhancements#213
Checklist
scons build
&scons test
) and unit tests address code coverage