+(*)Correct rotational symmetry with USE_LEITHY #1
Conversation
This file contains 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
Hallberg-NOAA
force-pushed
the
LeithE_rotational_symmetry
branch
from
f30e2fd to
51ecd65
Compare
|
I have updated this PR so that it does not do any extra calculations in non-symmetric memory mode, and to eliminate the code that gave the previous (clearly incorrect) answers when |
This commit revises the smoothing code used when USE_LEITHY = True to give
answers that respect rotational symmetry and it also corrects some horizontal
indexing bugs and problems with the staggering in some halo update and smooth_x9
calls and reduces some loop ranges to their minimal required values. The
specific changes include:
1. Corrected a horizontal indexing bug when interpolating Kh_h and Ah_h to
corner (q) points when USE_LEITHY = True. These had previously been
inappropriately copied from the thickness point to the southwest of the
corner point. This required symmetric-memory-mode calculations of the
thickness point viscosities whenever USE_LEITHY is true, but to avoid adding
complicated logic, the symmetric-memory loop bounds are used for the
calculation of Kh.
2. Revised smooth_x9 to give rotationally symmetric answers and split it into
the two routines smooth_x9_h and smooth_x9_uv to reduce the memory used by
this routine and reduce the use of optional arguments.
3. Eliminated 4 unneeded halo update calls, and added error handling for the
case where Leith options are used with insufficiently wide halos.
4. Added new integers to indicate the loop ranges over which the viscosities
and related variables should be calculated, depending on which options are
active, and then adjusted 91 do-loop extents horizontal_viscosity code to
reflect the loop ranges over which arrays are actually used.
5. Added a new 2-d variable for the squared viscosity for smoothing that can
be used for halo updates and to avoid having a variable with confusingly
inconsistent dimensions at various points in the code.
6. Corrected the position arguments on 2 smooth_x9 calls and 4 pass_var calls
that are used when USE_LEITHY=.true. and SMOOTH_AH=.true. As previously
written, these smooth_x9 and pass_var calls would work when in non-symmetric
memory mode but would give incorrect answers when in symmetric memory mode.
These revisions change answers when USE_LEITHY is true, but answers are
bitwise identical in all other cases.
Hallberg-NOAA
force-pushed
the
LeithE_rotational_symmetry
branch
from
51ecd65 to
f38c8d5
Compare
iangrooms
merged commit 887e802
into
iangrooms:fix_biharmonic_leith
7 of 10 checks passed
|
I finally got a chance to look at and merge this PR. Thanks for putting it together! |
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.
This commit revises the smoothing code used when USE_LEITHY = True to give answers that respect rotational symmetry and it also corrects some horizontal indexing bugs and problems with the staggering in some halo update and smooth_x9 calls and reduces some loop ranges to their minimal required values. The specific changes include:
Corrected a horizontal indexing bug when interpolating Kh_h and Ah_h to corner (q) points when USE_LEITHY = True. These had previously been inappropriately copied from the thickness point to the southwest of the corner point. This required symmetric-memory-mode calculations of the thickness point viscosities whenever USE_LEITHY is true, but to avoid adding complicated logic, the symmetric-memory loop bounds are used for the calculation of Kh.
Revised smooth_x9 to give rotationally symmetric answers. The previous code was retained behind the new nonsym_sums logical argument to smooth_x9 to generate the previous non-rotationally symmetric answers if they are actively being used. However, if they are not actively being used, all the unused code hidden behind the broken_symmetry=.true. branch in smooth_x9 should be eliminated.
Added the new runtime argument LEITHY_NONSYMMETRIC_SUMS in cases when USE_LEITHY = True to determine whether to use the new rotationally symmetric smoothing code.
Eliminated 4 unneeded halo update calls, and added error handling for the case where Leith options are used with insufficiently wide halos.
Added a new 2-d variable for the squared viscosity for smoothing that can be used for halo updates and to avoid having a variable with confusingly inconsistent dimensions at various points in the code.
Corrected the position arguments on 2 smooth_x9 calls and 4 pass_var calls that are used when USE_LEITHY=.true. and SMOOTH_AH=.true. As previously written, these smooth_x9 and pass_var calls would work when in non-symmetric memory mode but would give incorrect answers when in symmetric memory mode.
Adjusted 13 do-loop extents in the USE_LEITHY=.true. code to reflect the loop ranges over which arrays are actually used, and another 78 loops now always work as though they are working with symmetric-memory.
These revisions can change answers when USE_LEITHY is true, but answers are bitwise identical in all other cases. There are new or corrected entries in some MOM_parameter_doc files.