Skip to content
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

Open
wants to merge 18 commits into
base: main
Choose a base branch
from
Open

Conversation

ischoegl
Copy link
Member

@ischoegl ischoegl commented Feb 4, 2025

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)):

  • Create a new ConnectorNode base, which combine Wall and FlowDevice objects; all objects are captured in updated factories.
  • Changes are propagated to all relevant API’s, i.e. Python, CLib and MATLAB.

If applicable, fill in the issue number this pull request is fixing

Addresses Cantera/enhancements#213

Checklist

  • The pull request includes a clear description of this code change
  • Commit messages have short titles and reference relevant issues
  • Build passes (scons build & scons test) and unit tests address code coverage
  • Style & formatting of contributed code follows contributing guidelines
  • The pull request is ready for review

Copy link

codecov bot commented Feb 4, 2025

Codecov Report

Attention: Patch coverage is 59.06433% with 70 lines in your changes missing coverage. Please review.

Project coverage is 74.35%. Comparing base (e6f3e9d) to head (c791052).
Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
src/clib/ctreactor.cpp 13.95% 37 Missing ⚠️
src/zeroD/ConnectorFactory.cpp 65.00% 12 Missing and 2 partials ⚠️
interfaces/cython/cantera/reactor.pyx 80.00% 6 Missing ⚠️
src/zeroD/FlowDevice.cpp 86.36% 3 Missing ⚠️
src/zeroD/Wall.cpp 66.66% 3 Missing ⚠️
include/cantera/zeroD/ConnectorNode.h 80.00% 2 Missing ⚠️
src/zeroD/ReactorBase.cpp 66.66% 2 Missing ⚠️
include/cantera/zeroD/FlowDevice.h 0.00% 1 Missing ⚠️
include/cantera/zeroD/Wall.h 0.00% 1 Missing ⚠️
src/zeroD/ConnectorNode.cpp 87.50% 0 Missing and 1 partial ⚠️
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.
📢 Have feedback on the report? Share it here.

@ischoegl ischoegl force-pushed the zerod-connector-nodes branch 5 times, most recently from 3ca0fab to 3822451 Compare February 4, 2025 14:50
@ischoegl ischoegl marked this pull request as ready for review February 4, 2025 16:01
@ischoegl ischoegl requested a review from a team February 4, 2025 16:01
Copy link
Member

@speth speth left a 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.

Comment on lines 18 to 19
* In a reactor network, walls and flow devices (valves, pressure regulators, etc.)
* form edges of a directed graph that connect reactors that form nodes.
Copy link
Member

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?

Copy link
Member Author

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)

Comment on lines +63 to +66
//! Pair of reactors forming end points of the connector.
pair<shared_ptr<ReactorBase>, shared_ptr<ReactorBase>> m_nodes;
Copy link
Member

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.

Copy link
Member Author

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.

Comment on lines 67 to 70
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");

Copy link
Member

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.

Copy link
Member Author

@ischoegl ischoegl Feb 16, 2025

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.

Comment on lines 500 to 503
try {
return WallCabinet::at(i)->area();
return ConnectorCabinet::as<Wall>(i)->area();
} catch (...) {
return handleAllExceptions(DERR, DERR);
Copy link
Member

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.

Copy link
Member Author

@ischoegl ischoegl Feb 16, 2025

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.

@ischoegl ischoegl force-pushed the zerod-connector-nodes branch from 3822451 to 967735b Compare February 16, 2025 16:49
@ischoegl ischoegl force-pushed the zerod-connector-nodes branch from 967735b to c791052 Compare February 16, 2025 16:59
@ischoegl
Copy link
Member Author

ischoegl commented Feb 16, 2025

@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 newConnectorNode is valid, so I added two updated versions that retain the original split between newWall and newFlowDevice. Regarding your CLib comment, the exact implementation will be fleshed out according to Cantera/enhancements#220, so I'd like to table this for the moment.

@ischoegl ischoegl requested a review from speth February 16, 2025 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants