-
Notifications
You must be signed in to change notification settings - Fork 0
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
We now construct a DMLabel for boundary faces. #199
Conversation
Also, making it safe to call TDyCreateVectors and TDyCreateJacobian more than once.
Also added TDyGetBoundaryFaces and TDyRestoreBoundaryFaces.
Codecov Report
@@ Coverage Diff @@
## master #199 +/- ##
=======================================
Coverage 67.81% 67.81%
=======================================
Files 7 7
Lines 1224 1224
=======================================
Hits 830 830
Misses 394 394 Continue to review full report at Codecov.
|
ierr = DMCreateLabel(tdy->dm, "boundary"); CHKERRQ(ierr); | ||
ierr = DMGetLabel(tdy->dm, "boundary", &boundary_label); CHKERRQ(ierr); | ||
ierr = DMPlexMarkBoundaryFaces(tdy->dm, 1, boundary_label); CHKERRQ(ierr); | ||
ierr = DMPlexLabelComplete(tdy->dm, boundary_label); CHKERRQ(ierr); |
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.
Note that this Complete() marks the closure of every face, so we might change the comment above
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.
Good point. Are there cases where this isn't desirable? Just curious (I took this code from an example).
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.
Well, sometimes you want to do a face-specific thing, so you would need to filter out any non-faces, but that is usually easy. FE typically works with the whole boundary whereas FV just wants faces.
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 good
@jeff-cohere Can we add a new test or modify the existing test for this new PR? |
I'll see if I can modify one of the demos to simplify them a bit, given how much more lifting |
As discussed in #187, this PR introduces the use of
DMPlexMarkBoundaryFaces
to produce aDMLabel
named"boundary"
that we can use to enforce boundary conditions. I'm trying to be careful about how we approach this, because our demos are all pretty historical-looking. So this is just another in a series of PRs to improve the organization of the TDycore library.Additional items:
-tdy_init_file
,TDySetFromOptions
allocates storage for the solution vector and friends withTDyCreateVectors
and initializes things accordingly. I tried to initialize from a random field, too, but TH does this differently, so this must be done elsewhere for now.TDyCreateVectors
andTDyCreateJacobian
are documented and can be safely called multiple times (with no effect after the first time).TDyGetBoundaryFaces
andTDyRestoreBoundaryFaces
are introduced, to provide access to the (undifferentiated) faces on the domain boundary via the label. This provides a simple mechanism for traversing just the boundary faces."boundary"
label. However, I haven't changed the MPFA-O method for marking boundary faces, since it's logically consistent already. I did leave aTODO
comment in that section for subsequent cleanup if we want to tighten things up later.At this point, the set of faces on the domain boundary is generated automatically when the grid is created, so all demos can access it. I think this should close #187. @bishtgautam , let me know if you don't agree. #188 probably demands a little more attention, and the callback/virtual table way of organizing our different algorithms (#197) is looking ever more appealing.
Closes #187