Skip to content

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

Merged
merged 4 commits into from
Jun 25, 2019
Merged

Conversation

ali-ramadhan
Copy link
Member

This PR gets rid of default and non-default boundary conditions. Default boundary conditions are now explicitly Periodic in x,y and FreeSlip in z.

This will make implementing multiple wall-bounded dimensions easier/cleaner.

@codecov
Copy link

codecov bot commented Jun 20, 2019

Codecov Report

Merging #288 into master will decrease coverage by 0.07%.
The diff coverage is 42.85%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
src/boundary_conditions.jl 80.64% <100%> (-1.18%) ⬇️
src/time_steppers.jl 84.09% <33.33%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 40dbd96...51bc9e0. Read the comment docs.

@codecov
Copy link

codecov bot commented Jun 20, 2019

Codecov Report

Merging #288 into master will decrease coverage by 0.29%.
The diff coverage is 14.28%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
src/Oceananigans.jl 100% <ø> (ø) ⬆️
src/time_steppers.jl 82.95% <0%> (-1.14%) ⬇️
src/boundary_conditions.jl 80.64% <100%> (-1.18%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 40dbd96...4db4b31. Read the comment docs.

Copy link
Member

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

@ali-ramadhan
Copy link
Member Author

Thanks for taking a look. Good point. FreeSlip is technically not correct either as it only applies to the velocity field. I've removed it as a boundary condition and instead specify a no-flux boundary condition.

So now only doubly Periodic boundary conditions default to nothing as they're enforced via halo filling elsewhere in the code for now. The no-flux BCs will just add zeros but the performance hit should be negligible. I guess we only apply BCs in the z-dimension for now, so would be good to benchmark when x and y BCs are applied.

@ali-ramadhan ali-ramadhan self-assigned this Jun 25, 2019
@glwagner
Copy link
Member

glwagner commented Jun 25, 2019

I think its correct that Periodic boundary conditions have condition=nothing.

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 Periodic in the z direction at some point in the future, which may be useful for both science and validating the model against established results.

@ali-ramadhan
Copy link
Member Author

Shouldn't we fill halos in all 3 directions?

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.

@glwagner
Copy link
Member

I wasn't suggesting that z-halos becomes part of the PR --- I'm referring to this part of your comment:

I guess we only apply BCs in the z-dimension for now, so would be good to benchmark when x and y BCs are applied.

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.

@ali-ramadhan
Copy link
Member Author

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.

@ali-ramadhan ali-ramadhan merged commit 75cb66d into master Jun 25, 2019
@ali-ramadhan ali-ramadhan deleted the explicit-default-bcs branch June 25, 2019 12:31
arcavaliere pushed a commit to arcavaliere/Oceananigans.jl that referenced this pull request Nov 6, 2019
Explicit default boundary conditions

Former-commit-id: 75cb66d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup 🧹 Paying off technical debt
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants