-
Notifications
You must be signed in to change notification settings - Fork 237
Explicit default boundary conditions #288
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #288 +/- ##
==========================================
- Coverage 68.36% 68.29% -0.08%
==========================================
Files 22 22
Lines 882 880 -2
==========================================
- Hits 603 601 -2
Misses 279 279
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #288 +/- ##
=========================================
- Coverage 68.36% 68.06% -0.3%
=========================================
Files 22 22
Lines 882 880 -2
=========================================
- Hits 603 599 -4
- Misses 279 281 +2
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.
Looks good --- though, anticipating a replacement of the current boundary condition implementation to one using halo regions, I think we should not introduce a FreeSlip
condition, but instead use a Flux
condition with condition=0
, because this is simpler, reduces code length, and should not produce a performance detriment.
Thanks for taking a look. Good point. So now only doubly |
I think its correct that Shouldn't we fill halos in all 3 directions? That way everything is neat and simple and there's no special directions. It will also allow us to easily implement |
That would be nice and I have the halo filling figured out for the z-direction already, but it's not within the scope of this PR. |
I wasn't suggesting that z-halos becomes part of the PR --- I'm referring to this part of your comment:
I think this comment could be incorrect, because our future strategy will involve filling halos to satisfy the boundary conditions, rather than "applying" them, as is currently done in the z-direction. |
Ah that's true, yes, if we fully switch to halos first. |
Explicit default boundary conditions Former-commit-id: 75cb66d
This PR gets rid of default and non-default boundary conditions. Default boundary conditions are now explicitly
Periodic
in x,y andFreeSlip
in z.This will make implementing multiple wall-bounded dimensions easier/cleaner.