-
Notifications
You must be signed in to change notification settings - Fork 86
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
topology fixes and docs clean up #455
Conversation
Codecov ReportBase: 92.79% // Head: 93.06% // Increases project coverage by
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## master #455 +/- ##
==========================================
+ Coverage 92.79% 93.06% +0.26%
==========================================
Files 28 28
Lines 4222 4271 +49
==========================================
+ Hits 3918 3975 +57
+ Misses 304 296 -8
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View 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.
Thanks for the quick fix! The edge and face neighborhood should still have the same issue.
Face neighborhood doesn't have this issue, since it should be 1:1 correspondence for conforming grids. Nonconforming grids cannot encode the face neighborhood as discussed in the previous PR. For edge neighborhood this is true, but it is sort of exotic feature which probably isn't needed that often, but when it someone needs it I can do a follow up PR |
ok nvm, I added the |
Indeed, I agree that edge neighborhoods are not that commonly needed. I think I will open up a follow up PR extending the docs, because something is inconsistent in my head. Maybe I can find what it is with an example.
For vertex 5 the neighborhood in the exclusive topology is spanned by the global vertices (2,4,6,8) expressed in the element local vertex indices, correct? Now with this PR For the right face on element 1 the neighborhood is the left face in element two, right? So just a part of the face "(2,5)". With Do you agree that it would be better to rename the method to something different (i think they actually return something like to a vertex-patch, when I think about cell patches) and make the |
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 found a few minor issues.
Also, I think test coverage for getneighborhood
with FaceIndex is missing in 2d and 3d.
Since the FaceIndex |
These are two separate things. With one test we check if the data structure is correctly constructed. The next test is to check if the interface to the data structure works correctly. Note that we can make changes to the backend without changing the contract of the interface. |
Co-authored-by: Dennis Ogiermann <termi-official@users.noreply.github.com>
…sion tests for higher order
c60ffd1
to
896d1a4
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.
LGTM. I think this can be merged @fredrikekre .
You two are in charge of this code, so if you are happy with it I am happy with it :) |
fixes #518 and #453