Atmosphere/dt rampup #3
Open
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
When building MPAS as a dycore, certain constants in the `mpas_constants` module are
imported from the `physconst` module, which is a part of CAM/CAM-SIMA. However,
multiple issues arise if the precision of those constants differs from MPAS.
For example, building MPAS in single precision mode with CAM-SIMA fails due to
multiple occurrences of type mismatch between actual and dummy arguments.
mpas_geometry_utils.F:885:157:
885 | call mpas_log_write('$r', MPAS_LOG_ERR, realArgs=(/mpas_triangle_signed_area_sphere(a,b,c,sphereRadius) - pii/2.0_RKIND*sphereRadius*sphereRadius/))
| 1
Error: Type mismatch in argument 'realargs' at (1); passed REAL(8) to REAL(4)
Here, `pii` is declared by CAM-SIMA to be double precision, and it causes unintended
floating-point promotion in the expression.
The solution is to ensure that constants in the `mpas_constants` module are declared
at the native precision of MPAS.
In the `mpas_constants` module, enforce `implicit none` at the module level so it applies everywhere within. It is also a best practice in Fortran.
…e level of `mpas_constants` A blanket `use` statement imports all public entities from that module. For the case here, it causes namespace pollution at the module level of `mpas_constants`. Also, it is difficult to tell where the imported entities come from. Therefore, `use` statements should always include the `only` option. It is also a best practice in Fortran.
It is a best practice in Fortran to always specify the accessibility of module variables (as well as procedures). For the case here, `RKIND` is imported from `mpas_kind_types`. Due to the lack of accessibility attributes, other modules that `use mpas_constants` also have access to `RKIND`. Therefore, avoid causing unexpected namespace pollution to other modules by specifying explicit accessibility attributes.
Several instances of trailing spaces have been removed, and a blank line has been added above the `contains` statement in the `mpas_constants` module for consistency with other MPAS modules.
…elop (PR MPAS-Dev#1282) When building MPAS-A as a dynamical core in CAM/CAM-SIMA, certain constants in the mpas_constants module are imported from the physconst module, which is a part of CAM/CAM-SIMA. However, multiple issues arise if the precision of those constants differs from MPAS-A. For example, building MPAS-A in single precision mode with CAM-SIMA fails due to multiple occurrences of type mismatch between actual and dummy arguments. mpas_geometry_utils.F:885:157: 885 | call mpas_log_write('$r', MPAS_LOG_ERR, realArgs=(/mpas_triangle_signed_area_sphere(a,b,c,sphereRadius) - pii/2.0_RKIND*sphereRadius*sphereRadius/)) | 1 Error: Type mismatch in argument 'realargs' at (1); passed REAL(8) to REAL(4) Here, pii is declared by CAM-SIMA to be double precision, and it causes unintended floating-point promotion in the expression. The solution is to ensure that constants in the mpas_constants module are declared at the native precision of MPAS-A. Note that CAM does not support running MPAS-A in single precision mode at all, so the above build error cannot be reproduced. In addition, some best practices of modern Fortran have been implemented. For stand-alone MPAS-A, the compiled executables stay bitwise identical, with or without the changes in this merge. No further tests are needed. For CAM/CAM-SIMA, it generates bitwise identical model results, with or without this merge. Additionally for CAM-SIMA, its regression tests all pass, indicating identical model results to the previous baseline. * staging/dycore-with-native-constant-precision: Clean up whitespaces in the `mpas_constants` module Specify the accessibility of module variables in `mpas_constants` Only `use` needed variables to avoid namespace pollution at the module level of `mpas_constants` Enforce `implicit none` at the module level of `mpas_constants` Declare constants at the native precision of MPAS
…-SIMA When MPAS is used as a dynamical core in a host model (e.g., CAM/CAM-SIMA), the following transformations are performed for each namelist group and option name: 1. Leading "config_" is removed recursively from the name. Case-insensitive. 2. Leading "mpas_" is removed recursively from the name. Case-insensitive. 3. Prepend "mpas_" to the name. By doing so, it is now easier to distinguish MPAS namelist groups and options from host model ones. Additionally, the possibility of name collisions with host model ones is also resolved once and for all. Note that only namelist I/O is affected. Internally, MPAS still refers to its namelist options by their original names due to compatibility reasons. For stand-alone MPAS, its namelist groups and options keep their original names as in the registry.
…ev#1285) When MPAS-A is used as a dynamical core in a host model (e.g., CAM/CAM-SIMA), it needs to share the namelist file with other model components. As a result, MPAS-A namelist groups and options may not be easily recognizable at first sight. The solution, which is implemented by this merge, is to add a unique identifier to all MPAS-A namelist group and option names. The following transformations are performed for each MPAS-A namelist group and option name: - Leading 'config_' is removed recursively from the name. Case-insensitive. - Leading 'mpas_' is removed recursively from the name. Case-insensitive. - Prepend 'mpas_' to the name. By doing so, it is now easier to distinguish MPAS-A namelist groups and options from host model ones. The possibility of name collisions with host model ones is also resolved once and for all. Note that only namelist I/O is affected. Internally, MPAS-A still refers to its namelist options by their original names. Compared to the implementation in CAM, this merge applies the "name mangling" logic in an algorithmic and predictable way. It works automatically even if there are additions, modifications, or deletions to MPAS-A namelist groups and options. The "name mangling" logic is entirely guarded behind the MPAS_CAM_DYCORE macro. For stand-alone MPAS-A, its namelist groups and options keep their original names as in the registry. For CAM, it is not affected by this merge because it does not use the code generation functionality of MPAS-A for namelist reading at all. For CAM-SIMA, the Fortran include files generated by the parse utility stay the same. Its regression tests all pass, indicating identical model results to the previous baseline. * staging/dycore-prefix-namelist: Prefix all namelist group and option names for MPAS dycore in CAM/CAM-SIMA
…config_dt_init (new) to config_dt
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.
The title above should be a 1 line short summary of the pull request (i.e. what the project the PR represents is intended to do).
Enter a description of this PR. This should include why this PR was created, and what it does.
Testing and relations to other Pull Requests should be added as subsequent comments.
See the below examples for more information.
MPAS-Dev/MPAS#930
MPAS-Dev/MPAS#931