Skip to content
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

+Use verticalGrid_type to specify vertical extents #1268

Merged
merged 16 commits into from
Jan 6, 2021

Conversation

Hallberg-NOAA
Copy link
Collaborator

Completed the move to use the verticalGrid_type, and not the ocean_grid_type,
to specify the number of layers and the vertical extents in memory of 3-d
arrays. This required the addition of new GV arguments in dozens of routines.
This PR also includes some extensive corrections in the nonstandard use of white
space, so when this is reviewed, I recommend that the "ignore whitespace" flag
be turned on. There were also a few comments that were corrected. Although
there are interface changes, there should be no answer or output changes to
any MOM6 configurations.

The commits in this PR include:

  Use GV%ke instead of G%ke everywhere in the MOM6 code to get the number of
layers in a configuration.  This required the addition of new vertical_grid_type
arguments to a number of subroutines, and some unused variables were deleted.
This is one of the final steps in a very long-term project to separate the
vertical and horizontal grid types.  All answers are bitwise identical, but
there are new (non-optional) arguments to 51 subroutines.
  Use the vertical extent from the verticalGrid_type argument GV instead of the
extent from the ocean_grid_type argument G to specify the vertical extent of
arrays in memory in array declarations.  There 18 subroutines where new
vertical_grid_type arguqments were needed, and some comments were corrected.  All
answers are bitwise identical, but there are new (non-optional) arguments to 18
subroutines.
  The MOM6 style guide clearly states that MOM6 uses a two space indent between
code levels, to enhance the readability of the MOM6 code. Continuation lines are
typically indented 4 or more spaces.  This commit corrects several hundred lines
that did not conform to this standard.  All answers are bitwise identical.
  Corrected additional cases where the line indent pattern does not match the
MOM6 standards, especially in some routines in MOM_open_boundary.F90,
MOM_diag_mediator.F90, and MOM_ice_shelf related code.  All answers are bitwise
identical.
  Corrected non-standard spacing around semicolons separating do loops or if
tests on a single line, following MOM6 code standards.  (If Marshall wins his
planned argument against allowing such constructs, this enforcement of standards
will help in getting rid of them.)  All answers are bitwise identical.
@codecov-io
Copy link

codecov-io commented Dec 4, 2020

Codecov Report

Merging #1268 (5c9b5fa) into dev/gfdl (d819ccf) will decrease coverage by 0.00%.
The diff coverage is 35.95%.

Impacted file tree graph

@@             Coverage Diff              @@
##           dev/gfdl    #1268      +/-   ##
============================================
- Coverage     45.89%   45.88%   -0.01%     
============================================
  Files           225      225              
  Lines         71406    71396      -10     
============================================
- Hits          32769    32763       -6     
+ Misses        38637    38633       -4     
Impacted Files Coverage Δ
config_src/solo_driver/MESO_surface_forcing.F90 0.00% <ø> (ø)
config_src/solo_driver/MOM_surface_forcing.F90 25.77% <0.00%> (ø)
config_src/solo_driver/user_surface_forcing.F90 0.00% <0.00%> (ø)
src/ALE/regrid_interp.F90 1.41% <0.00%> (ø)
src/core/MOM_PressureForce.F90 46.15% <ø> (ø)
src/core/MOM_boundary_update.F90 50.00% <0.00%> (+5.55%) ⬆️
src/core/MOM_continuity.F90 63.88% <ø> (ø)
src/core/MOM_density_integrals.F90 19.89% <0.00%> (ø)
src/core/MOM_open_boundary.F90 30.76% <ø> (ø)
src/diagnostics/MOM_PointAccel.F90 4.32% <0.00%> (ø)
... and 120 more

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 d819ccf...0697604. Read the comment docs.

  Added GV to the shared declaration in an openMP directive.  All answers are
bitwise identical.
adcroft and others added 4 commits January 4, 2021 12:06
  This added merge was done to reconcile two separate merges of dev/gfdl onto
the ke_from_GV branch.  It should have no effect except to clean up the git
history.
  Corrected the statement setting use_ice_shelf in initialize_MOM, which somehow
was not merged in correctly, presumably due to human error, when dev/gfdl was
merged into this branch.  All answers are bitwise identical.
@Hallberg-NOAA
Copy link
Collaborator Author

This PR is being tested with https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/11794.

  Added GV to the shared declaration in an openMP directive.  All answers are
bitwise identical.
  Added GV to the shared declaration in another openMP directive.  All answers
are bitwise identical.
@Hallberg-NOAA
Copy link
Collaborator Author

This PR passed the revised pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/11796.

Copy link
Collaborator

@adcroft adcroft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adcroft adcroft merged commit e68d31a into mom-ocean:dev/gfdl Jan 6, 2021
@Hallberg-NOAA Hallberg-NOAA deleted the ke_from_GV branch July 30, 2021 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants