-
Notifications
You must be signed in to change notification settings - Fork 195
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
FINALLY reverse the k index #462
Conversation
Are we integrating bottom-up or top-down now? Ultimately it might be nice to eliminate that step and explicitly time-step the vertical velocity, since thats valid for general boundary conditions... |
For w is
Seems that we're actually implementing the second. Might be nice to have direct access to the surface via |
The convention we use for the other variables stored on faces is that our "interior" data spans from In addition, we use a convention that face indices are "left" of cell indices. Thus Why do you want "direct" access to the surface at The fact is simply that the face at If/when we use named axis conventions for |
We've mostly been concerned with surface ocean physics so naively it would seem nice to have the surface not be a halo cell. Might have been an issue in the past when we didn't have vertical halos because then you don't even have a cell for the surface. Out of curiousity then, would an implementation of surface wave effects (#443) have to touch the halos? |
Your suggestion seems more to change indexing behavior rather than convention for halos --- but maybe thats not true given that we use the halos more as ghost points now, rather than overlap regions for MPI stuff, etc. Presumably, we could simply define the |
Codecov Report
@@ Coverage Diff @@
## master #462 +/- ##
=======================================
Coverage 73.34% 73.34%
=======================================
Files 27 27
Lines 1508 1508
=======================================
Hits 1106 1106
Misses 402 402
Continue to review full report at Codecov.
|
Fixed a few more things and I've updated Regression tests fail so I'll see what's wrong there tomorrow. We should probably go in this order:
|
Regression tests all pass on my laptop! Next I'll merge in master to make sure Then we can regenerate the regression data with a reversed Differences are all very small so I'm confident we're producing the same numbers as before (up to machine precision and truncation error):
|
But the tracer values at the top and bottom boundaries are wrong after one time step, so must be a boundary issue...
After reversing the k index u, v, w, and S are all correct if you take one time step for the LES regression tests (non-LES regression tests all pass). But T values at the top and bottom grid cells are wrong. Still thinking of what could be effecting T but not S (which also runs with AMD and flux boundary conditions)... T is the only field with a gradient boundary condition, but enforcing gradient boundary conditions shouldn't have changed and looks fine to me... I think this is the last bug, if fixed this should hopefully become ready to merge . |
Thanks @glwagner! All four regression tests pass now! I'll regenerate the regression data in a subsequent PR which also removes all the |
Differences are close to machine epsilon so pretty sure this branch produces the same numbers as before, up to truncation error (and we do integrate from the bottom up to enforce continuity now).
|
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 great. Also happy about the house cleaning. Looks like some NetCDF stuff snuck in here too; not sure how that happened, but it seems minor.
@@ -49,7 +49,7 @@ export | |||
|
|||
# Model output writers | |||
Checkpointer, restore_from_checkpoint, read_output, | |||
JLD2OutputWriter, FieldOutput, FieldOutputs, | |||
JLD2OutputWriter, NetCDFOutputWriter, FieldOutput, FieldOutputs, |
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.
?
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.
Yeah this was an issue after I merged master in, I guess we forgot to export it in PR #433.
Bad practice on my part to include changes not relevant to reversing the k index.
@@ -214,7 +211,7 @@ function ChannelBCs(; north = BoundaryCondition(Flux, nothing), | |||
|
|||
x = PeriodicBCs() | |||
y = CoordinateBoundaryConditions(south, north) | |||
z = CoordinateBoundaryConditions(top, bottom) | |||
z = CoordinateBoundaryConditions(bottom, top) |
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.
Very satisfying.
@@ -136,9 +135,8 @@ function test_function_differentiation(T=Float64) | |||
∂y_ϕ_f = ϕ²[2, 2, 2] - ϕ²[2, 1, 2] | |||
∂y_ϕ_c = ϕ²[2, 3, 2] - ϕ²[2, 2, 2] | |||
|
|||
# Note reverse indexing here! |
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.
Nice.
I was thinking of releasing v0.13 once this is merged (need to sort out v0.12 tag first). Would be good to tag a version and be able to say "pre-v0.13" is bad k-indexing and "v0.13+" is good k-indexing as this is a pretty big change and model output is now different (some analysis and plotting scripts will have to be modified). |
FINALLY reverse the k index Former-commit-id: 41a2b55
This PR finally reverses the
k
index although it's still a work in progress as a few tests fail. In particular, it seems that incompressibility is not satisfied even though I managed to get the "recomputing w from continuity" test to pass.Need to think about this some more.
Resolves #90
Resolves #468
Resolves #480