MOM_domain_infra: Document FMS passthroughs #3
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
This patch explicitly identifies `global_field_sum` and `group_pass_type` as FMS pass-throughs. These remain undocumented and cannot be wrapped, but the exceptional reasons for retaining them justifies their existence as pass-throughs. Since `global_field_sum` is unused in MOM6/src, it does not require an explicit definition or wrapper. Legacy drivers may still require this definition, however, so we retain it here. The contents of `group_pass_type` are never accessed, and it is only used to facilitate internal mpp operations, so it does not need to formally be part of the MOM6 API and can be left undocumented. Since these two functions are exceptions to the rule that all active operations should be wrapped and documented, it makes sense to explicitly identify them as such.
Hallberg-NOAA
pushed a commit
that referenced
this pull request
Nov 30, 2021
* reads in porous topography parameters from CHANNEL_LIST_FILE *new module to compute curve fit for porous topography *porous constraints used to modify continuity_PPM, CoriolisAdv, and Rayleigh bottom channel drag
Hallberg-NOAA
added a commit
that referenced
this pull request
Nov 30, 2021
(+) porous topography implementation
Hallberg-NOAA
added a commit
that referenced
this pull request
Dec 23, 2021
Use the por_face_area[UV] in the effective thickness calculations in zonal_face_thickness and merid_face_thickness, so that they are more consistent with their use elsewhere in the code for the relative weights in calculating the barotropic accelerations. Because these por_face_area arrays are still 1 in all test cases, the answers are unchanged in any test cases from before a few weeks ago, but there could be answer changes in cases that are using the very recently added capability (in PR #3) to set fractional face areas. This change was discussed with Sam Ditkovsky, and agreed that there is no reason to keep the ability to recover the previous answers in any cases that use the recently added partial face width option. This commit also expanded the comments describing the h_u and h_v arguments to btcalc(), zonal_face_thickness(), and merid_face_thickness() routines, the diag_h[uv] elements of the accel_diag_ptrs type and the h_u and h_v elements of the BT_cont_type. All answers and output are bitwise identical in the MOM6-examples test suite and TC tests, but answer changes are possible in cases using a very recently added code option.
marshallward
pushed a commit
that referenced
this pull request
Dec 29, 2021
Use the por_face_area[UV] in the effective thickness calculations in zonal_face_thickness and merid_face_thickness, so that they are more consistent with their use elsewhere in the code for the relative weights in calculating the barotropic accelerations. Because these por_face_area arrays are still 1 in all test cases, the answers are unchanged in any test cases from before a few weeks ago, but there could be answer changes in cases that are using the very recently added capability (in PR #3) to set fractional face areas. This change was discussed with Sam Ditkovsky, and agreed that there is no reason to keep the ability to recover the previous answers in any cases that use the recently added partial face width option. This commit also expanded the comments describing the h_u and h_v arguments to btcalc(), zonal_face_thickness(), and merid_face_thickness() routines, the diag_h[uv] elements of the accel_diag_ptrs type and the h_u and h_v elements of the BT_cont_type. All answers and output are bitwise identical in the MOM6-examples test suite and TC tests, but answer changes are possible in cases using a very recently added code option.
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 patch explicitly identifies
global_field_sumandgroup_pass_typeas FMS pass-throughs. These remain undocumented andcannot be wrapped, but the exceptional reasons for retaining them
justifies their existence as pass-throughs.
Since
global_field_sumis unused in MOM6/src, it does not require anexplicit definition or wrapper. Legacy drivers may still require this
definition, however, so we retain it here.
The contents of
group_pass_typeare never accessed, and it is onlyused to facilitate internal mpp operations, so it does not need to
formally be part of the MOM6 API and can be left undocumented.
Since these two functions are exceptions to the rule that all active
operations should be wrapped and documented, it makes sense to
explicitly identify them as such.