Add LILAC cap #32
Draft
Add LILAC cap #32
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
I needed this on my mac because 'use mpi' doesn't work there (I think we'd need to '#include <mpif.h>', but it's more robust to just use shr_mpi_mod).
Updates to NUOPC cap Main purpose is updates to NUOPC cap. Also a fix for PIO2. Most changes are from Mariana Vertenstein, brought to master by Bill Sacks. These changes are documented in #30 Testing: mosart test suite (cheyenne & izumi), in the context of a CTSM checkout (ESCOMP/CTSM#939). Baseline comparisons done against ctsm1.0.dev085.
billsacks
added a commit
to ESCOMP/CTSM
that referenced
this pull request
Jul 1, 2020
I'm not ready to bring the mosart branch in, and it's not needed yet because we're not yet running LILAC with MOSART. I have opened a PR for it to bring in later: ESCOMP/MOSART#32
billsacks
added a commit
to ESCOMP/CTSM
that referenced
this pull request
Jul 2, 2020
This change is important in the short-term, at least, because I'm not ready to bring the mosart lilac_cap branch to master, so we're pointing to a version of mosart that doesn't have the necessary changes - see ESCOMP/MOSART#32. Once those MOSART changes are on MOSART's master branch, then we should change buildlib back to using the MOSART source code rather than stub rof. We may want to do this conditionally, depending on whether rof coupling is actually wanted in the given run. (I at first thought that we could let the cime build build mosart for us, but then realized that the current mechanism is needed because lilac depends on the mosart code; also, mosart is not built during the --sharedlib build phase.) Note: I have NOT given careful thought to the changes in lilac_mod.F90: It seems right to put this rof-related code inside a conditional, but I haven't done a careful analysis to determine if that's correct.
|
See ESCOMP/CTSM@a1b038683 . These changes were needed to build / run lilac without mosart. Once we want to support mosart in lilac, we'll need to add some of those deleted lines back in buildlib, possibly conditionally. (I think the rest of the changes in that commit can remain as is, but see the commit log message for details.) |
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.
At some point we need to bring this branch in to MOSART's main branch, so that we can run LILAC with MOSART. However, I'm not quite ready to do so, for a few reasons:
I haven't reviewed these changes
We don't have any tests in place that exercise this new cap
From a very quick look, I noticed that the
buildlibchanges will need to be revised: we no longer use an environment variable to indicate that we're using LILAC, but instead use an xml variable defined in CTSM'sconfig_component.xml. So we should query that XML variable, but do so in a way that, if the variable isn't found, then we proceed assuming that we're NOT using LILAC (so that this works in a case that includes MOSART without CTSM - e.g., with a data land model).So for now I'm opening a PR so that we remember to bring this in at some point, but as far as I'm concerned, this can remain open for a while.
cc @mvertens @ekluzek