-
Notifications
You must be signed in to change notification settings - Fork 12
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 namelist reading and early initialization of MPAS dynamical core #248
Implement namelist reading and early initialization of MPAS dynamical core #248
Conversation
The history of time manager has diverged a lot between CAM and CAM-SIMA. Manually backport `get_stop_date` and `get_run_duration` subroutines to time manager for MPAS.
This module manages the life cycle (i.e., initialization, running, and finalization) of MPAS as a dynamical core within CAM-SIMA.
`dyn_readnl` calls appropriate MPAS subdriver APIs to: 1. Read MPAS namelist from supplied path. 2. Perform early initialization of MPAS dynamical core.
MPAS subdriver is built and included in `libmpas.a` static library.
Also fix a bug in `_copy2_as_needed`. Previously, if `dst` is a directory and `os.path.join(dst, os.path.basename(src))` is a file, the file will be copied again unconditionally. In this case, checks should be performed first.
I believe the @gdicker1 @kuanchihwang Would it be worth committing the script used to generate |
It's ugly and quick, so I wonder if the script is "ready" for CAM-SIMA. Give me a few to get it into somewhere on GitHub so I can link it for others to judge. |
Some of the additions in this PR are generic (in that they are not MPAS-A dycore-specific); for example, the new routines in @nusbaume I'm not sure if there's anything covering this in the CAM development workflow or coding standards pages, but is it preferable to make separate PRs in cases like this? |
Here it is! Turns out I had it in a repo already: https://github.com/gdicker1/TranslateXML_MPAStoCAMSIMA |
That seems more than clean enough to me. As a question to all, would it make sense to commit that script to, e.g., somewhere in the CAM-SIMA repo like |
If `NDEBUG` macro is defined (i.e., release builds), debug prints are disabled.
Introduce `printer` optional argument to `dyn_mpas_debug_print` subroutine. If `printer` is not supplied, the MPI master rank will print. Otherwise, the designated MPI rank will print instead.
... In accordance with the spirit of OOP.
I personally think it's fine to bring in code that is not strictly MPAS-specific in an MPAS PR, just as long as the PR itself is not too large (this one is a good size, for example). Also I'd be happy to have the registry translation script live inside CAM-SIMA, especially since it seems pretty SIMA-specific (i.e. I assume it won't be used elsewhere?). We discussed it in a meeting today and decided that having it sit somewhere under Finally, I just wanted to let you know that I have finally started my review of this PR and should get any comments I have posted here soon. Thanks! |
As a broader comment/question, should we consider "namespacing" the MPAS-A dycore namelist options somehow? For example, right now in this PR we have this namelist group:
One of the variables in this group does have the "mpas" substring, but for others, there's nothing that indicates that these apply to the MPAS-A dycore. I believe @gdicker1's script substituted I completely appreciate the desire to use MPAS-A's native namelist reading routines; but that does come at the cost of namelist variable and namelist group names in CAM-SIMA that aren't obviously tied to the MPAS-A dycore. At a minimum, I think it would be good to:
|
Avoid double negation in expression.
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.
Nice work! I have a couple of potentially significant requests, but everything else will hopefully be minor. Of course please let me know if you have any questions or concerns with any of my comments. Thanks!
Note that the operation is idempotent due to the optional capturing group `(mpas_)?` in regexp.
After some investigations, I think we can have the best of both worlds. Hopefully 8669b0e can address your comments. All MPAS namelist groups are now prefixed by
So it will not to be confused with others. |
About bringing the "MPAS registry -> CAM-SIMA namelist definition" conversion script, I think it should be in another PR. |
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.
This PR looks good to me now, thanks @kuanchihwang! I had one last request about adding a comment header to namelist_definition_mpas_dycore.xml
, and a general comment about the possible future risk of a namelist collision (although I think for now the chances are low).
Also it's totally fine with me if you want to save the addition of the registry translation script for another PR.
@@ -4,7 +4,7 @@ | |||
<entry id="config_time_integration"> | |||
<type>char*256</type> | |||
<category>mpas</category> | |||
<group>nhyd_model</group> | |||
<group>mpas_nhyd_model</group> |
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.
Labeling the group name should definitely help! However, during the actual namelist generation step there is still a chance of a name collision as the current workflow is for the user to only include the namelist variable name in the user_nl_cam
file. So long term it might be good to find some way to add an mpas
string to each MPAS-A namelist variable as well.
That all being said, I think the general odds of a collision are low as the namelist variable strings would have to match exactly, so I don't think this concern should hold up the PR. Plus if we do run into a name collision then we can always fix that particular name then.
I have created an Issue to track this and follow-up later: #252 |
This PR implements namelist reading (
dyn_readnl
) and early initialization of MPAS dynamical core. A new MPAS subdriver module (dyn_mpas_subdriver
) is introduced, which will oversee the life cycle (i.e., initialization, running, and finalization) of MPAS as a dynamical core within CAM-SIMA.Credits to Dylan Dickerson (@gdicker1) for authoring
namelist_definition_mpas_dycore.xml
.Implementation notes:
Test steps:
Observe the following log entries in
atm.log.<job-id>.<date>-<time>
: