-
Notifications
You must be signed in to change notification settings - Fork 14
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
Implement finalization and various enhancements for MPAS dynamical core #327
base: development
Are you sure you want to change the base?
Implement finalization and various enhancements for MPAS dynamical core #327
Conversation
Additional comments:Note to reviewers: It might be easier to review the PR commit by commit. The commit messages provide the context and rationale behind each set of changes. You should be able to run analytic cases currently supported by CAM-SIMA (e.g., You are also encouraged to test MPAS dynamical core in single precision mode. From the following benchmarks, MPAS dynamical core in single precision mode is ~40% faster and uses ~25% less memory than in double precision mode. A reference CAM run with the same configuration is also provided for completeness. |
cd464ea
to
90fc72a
Compare
* Adjust wording and keep code comments up-to-date * Concentrate all calls to `mark_as_initialized` in one place * Fix up code style inconsistencies
Also fix variable rank information.
Relax restrictions on mixed precision between MPAS dynamical core and its input data.
`get_variable_pointer` also works for accessing MPAS configuration. It has built-in error checking so no need to do it manually.
Comply with CAM(-SIMA) coding standards. However, kind and length parameters are exempt from this rule. They are better at module level.
It is now possible to run CAM-SIMA with MPAS dynamical core in single precision mode. It can be enabled by defining the `SINGLE_PRECISION` macro in `CPPFLAGS`.
Protect these variables from being modified externally.
Manipulating source code by running `sed` commands during building is neither elegant nor obvious. Downstream modifications like these are better achieved and communicated through patches. This is also the standard practice in open source software.
These patches are applied before building.
This Python script generates the XML namelist definition file of MPAS dynamical core from MPAS registry. Optionally, if an XML schema is provided, the generated file can also be validated for correctness.
From now on, it can be generated automatically from MPAS registry.
Add MPAS initial files for running analytic cases.
90fc72a
to
e36fcdb
Compare
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 @kuanchihwang! I just have a few questions and some very minor requests, mostly to move some remaining module-level use
statements to their respective subroutines. Of course if any of my requests are problematic just let me know. Thanks!
# Uncomment below for single precision mode support. There is currently no corresponding option in CIME to enable this. | ||
# export CPPFLAGS += -DSINGLE_PRECISION |
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.
Not worth trying to resolve in this PR, but I believe we could make the use of single precision an option in the CAM_CONFIG_OPTS
variable in the CIME env_build.xml
file, where then the CAM-SIMA configuration system can set an environment variable that this Makefile then queries to set the relevant CPP Flag (or alternatively we could just add it directly to the full CAM-SIMA Makefile). This would provide a way for the average user to change the precision used in their own simulation without having to modify any source files.
Does this sound reasonable to you? If so then we should make a Github issue to remind us to implement it in a later PR.
@for file in *.patch; do \ | ||
if git apply --check -p2 "$${file}"; then \ | ||
echo "Applying $${file}"; \ | ||
git apply -p2 "$${file}"; \ | ||
fi; \ |
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.
Do you have any sense what the medium or long-term maintainability of this method will be? For example, will we need to create new patch files every time we update the MPAS submodule in CAM-SIMA, or are the targeted files rarely ever modified?
I don't think it matters for this PR, but if you think that it could require an abnormal amount of work to maintain then it might be worth opening a Github issue so we can remember to try and figure out alternative methods in the future.
default='Namelist.xml', | ||
type=str, | ||
required=False, | ||
help='XML namelist definition file.', |
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.
I might specify that this is a CAM-SIMA namelist definition file here:
help='XML namelist definition file.', | |
help='XML CAM-SIMA namelist definition file.', |
INDENT_PER_LEVEL * 2 + 'MPAS dycore' + '\n' + | ||
'\n' + | ||
INDENT_PER_LEVEL * 2 + 'Note to developers/maintainers:' + '\n' + | ||
INDENT_PER_LEVEL * 2 + 'This file is auto-generated from MPAS registry. Do not edit directly.' + '\n' + |
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.
Minor grammar nit-pick:
INDENT_PER_LEVEL * 2 + 'This file is auto-generated from MPAS registry. Do not edit directly.' + '\n' + | |
INDENT_PER_LEVEL * 2 + 'This file is auto-generated from the MPAS registry. Do not edit directly.' + '\n' + |
use time_manager, only: get_step_size | ||
|
||
! Modules from CCPP. | ||
! Module(s) from CCPP. | ||
use ccpp_kinds, only: kind_phys |
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.
I believe this use
statement can be passed down to the subroutine scope as well (i.e. there don't appear to be any module-level variables that need it).
! Module(s) from CESM Share. | ||
use shr_kind_mod, only: kind_r8 => shr_kind_r8, & | ||
len_cx => shr_kind_cx | ||
! Module(s) from MPAS. | ||
use dyn_mpas_subdriver, only: kind_dyn_mpas => mpas_dynamical_core_real_kind |
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.
I think all of these can be moved to the subroutine scope as well.
! Module(s) from CESM Share. | ||
use shr_kind_mod, only: kind_r8 => shr_kind_r8, & | ||
len_cs => shr_kind_cs |
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.
I believe this use shr_kind_mod
statement can be moved to the subroutine scope.
call dyn_debug_print('ncells_global = ' // stringify([ncells_global])) | ||
call dyn_debug_print('nedges_global = ' // stringify([nedges_global])) | ||
call dyn_debug_print('nvertices_global = ' // stringify([nvertices_global])) | ||
call dyn_debug_print('nvertlevels = ' // stringify([nvertlevels])) | ||
call dyn_debug_print('ncells_max = ' // stringify([ncells_max])) | ||
call dyn_debug_print('nedges_max = ' // stringify([nedges_max])) | ||
call dyn_debug_print('sphere_radius = ' // stringify([sphere_radius])) |
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.
Should we provide debuging print outs for the local mesh dimensions as well?
! Quick hack for dumping variables from MPAS dynamical core. | ||
! Remove it once history and restart are wired up in CAM-SIMA. | ||
call dyn_variable_dump() |
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.
Just an FYI that CAM-SIMA does have history infrastructure now for any diagnostic variable that can be output instantaneously (i.e. doesn't need to be accumulated over multiple timesteps, like an average). You can find a description and user guide for this new history infrastructure in the official CAM-SIMA developer documentation here:
https://escomp.github.io/CAM-SIMA-docs/design/history/#capturing-history-output
We sadly don't have restart functionality enabled yet, but hopefully this can provide at least some guidance for how to start replacing this "hack" in the future.
use mpas_io_streams, only: mpas_createstream, mpas_closestream, mpas_streamaddfield, & | ||
mpas_readstream, mpas_writestream, mpas_writestreamatt | ||
! Module(s) from MPAS. | ||
use mpas_derived_types, only: core_type, domain_type | ||
use mpas_kind_types, only: rkind, r4kind, r8kind, strkind |
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.
I believe r4kind
and r8kind
can be moved to the subroutine scope (as they appear to only be used in dyn_mpas_check_variable_status
).
Tag name (required for release branches):
None
Originator(s):
kuanchihwang
Descriptions (include the issue title, and the keyword ['closes', 'fixes', 'resolves'] followed by the issue number):
This PR implements finalization for MPAS dynamical core.
This PR also implements various enhancements for MPAS dynamical core:
use
statements to the smallest scope possible.assets
directory.mpas_
. They are now easily distinguishable from CAM-SIMA ones. The possibility of name collisions with CAM-SIMA ones is also resolved once and for all.Describe any changes made to the build system:
Due to the slight reorganization of directory structure,
cime_config/buildlib
is updated with the new paths.Describe any changes made to the namelist:
The namelist options for running analytic cases with MPAS dynamical core are updated to match CAM.
List any changes to the defaults for the input datasets (e.g., boundary datasets):
The input files for running analytic cases with MPAS dynamical core are updated to match CAM. The supported resolutions are:
mpasa480
,mpasa120
,mpasa60
, andmpasa30
with 32 vertical layers.mpasa480
,mpasa120
, andmpasa60
with 58 vertical layers.mpasa480
,mpasa120
, andmpasa60
with 93 vertical layers.List all files eliminated and why:
None
List all files added and what they do:
A src/dynamics/mpas/assets/0001-Prefix-all-MPAS-namelist-group-and-option-names.patch
A src/dynamics/mpas/assets/0002-Disable-physics-for-MPAS-dycore-only-build.patch
A src/dynamics/mpas/assets/0003-Declare-constants-at-the-native-precision-of-MPAS.patch
A src/dynamics/mpas/assets/generate_namelist_definition.py
List all existing files that have been modified, and describe the changes:
M cime_config/buildlib
M cime_config/namelist_definition_cam.xml
M src/dynamics/mpas/driver/dyn_mpas_subdriver.F90
use
statements to the smallest scope possibleM src/dynamics/mpas/dyn_comp.F90
dyn_final
use
statements to the smallest scope possibleprotected
attribute to grid/mesh variablesM src/dynamics/mpas/dyn_coupling.F90
use
statements to the smallest scope possibleM src/dynamics/mpas/dyn_grid.F90
use
statements to the smallest scope possibleprotected
attribute to grid/mesh variablesM src/dynamics/mpas/namelist_definition_mpas_dycore.xml
M src/dynamics/mpas/stepon.F90
dyn_final
use
statements to the smallest scope possibleR src/dynamics/mpas/assets/Makefile.in.CESM
sed
commands fromMakefile
R src/dynamics/mpas/assets/Makefile
Regression tests:
New baseline for MPAS dynamical core.
No changes to other existing tests.