Replace the previous ADAPTIVE coordinate with the flux-based AG implementation #25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the adaptive coordinate from the Gibson PhD thesis. It involves a flux-based calculation of density and smoothing adaptivity terms, which are weighted depending on the local isopycnal slope. Because these two terms alone aren't a sufficient constraint, interfaces can be nudged toward a pre-defined grid using the filtered_grid_motion mechanism. Additionally, to prevent convective instabilities resulting purely from grid motion, water masses can be "pushed" through vanished layers. As a structural change, the filtered_grid_motion subroutine and its controlling parameters are lifted out to the new ALE/filter_utils module, so that the main AG code can reside in ALE/coord_adapt without a circular dependency back on MOM_regridding.
We can pull out the contributing terms in the coordinate from within the regridding routine, and the framework is set up to pull arbitrary information out from the regridding step. This should be useful for coordinate debugging.
This probably needs slightly more careful analysis to make sure we're really doing the right thing.
These variables are only set on land points, but the diagnostics are including them regardless. While it shouldn't affect the regular operation of the code, the diagnostics could end up containing junk data.
The two timescales (adaptivity diffusivity and restoring) needed to be annotated with the s_to_T scaling in order to pass the dimensional consistency test for T.
We need to pass through the US structure.
We were failing the grid rotation test because of some floating point differences. It makes much more sense to compare to epsilon anyway.
There was a lot of duplicated code between these sections, making it very hard to verify they were even written exactly the same.
Seems like we were bringing in junk data for slopes which was causing differences across restarts.
It's useful to be able to dump the diagnostics out, but we need this weird "attach the diag CS later" method, which we might not always want to do. Instead, let's just make diagnostics conditional.
This filter only acts on points, if their masks are valid. Shouldn't require any halo extension.
A couple of issues here. First, there was a typo in the V-direction filter, so it was using the wrong mask. More importantly, the stencil was reaching through uncalculated cells and past the edges of the domain, leading to FPE.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Moving #6 to come from this fork so it can be deployed. Original description below, otherwise see the original PR for some discussion.
This changes the old
ADAPTIVEcoordinate that blended between grids with a new flux-based implementation called AG (Adaptive Grid). In its current state, there are a few things that may need to be changed:dtgets passed into regriddingDue to the use of a stencil for determining the smoothing/adaptivity flux, there's a non-reproducibility between symmetric and non-symmetric memory modes that I haven't yet worked out. This is raised in the
tc2.bcase that I added for regression testing in the GitHub Actions suite.This has been a part-time endeavour for ages, so I don't completely remember all the implementation specifics. Please criticise as necessary!
I will update with some of the mathematical justification, and a parameter description, which should go into the documentation.