-
Notifications
You must be signed in to change notification settings - Fork 25
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
refactor buildnml to use the CIME-CCS python based namelist generation capabilities #263
refactor buildnml to use the CIME-CCS python based namelist generation capabilities #263
Conversation
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 is quite an extensive PR, but I see that it mostly is a restructuring of how the namelists are generated (through a python script instead of a shell script).
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.
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 builds on top of changes to #262. I was hoping to use #262 immediately for the Making Waves project and then
have this PR reviewed more extensively so that everyone was comfortable with it. It would be good to also understand why this PR is important to get regression testing working with the right comparison of BLOM output.
If you were okay with merging #262 - that would be great!
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 have now merged #262 so it should be available in master. I talked briefly with Jörg, but but I don't know when Mats will be around. Hopefully we can have a meeting soon and discuss the implications of this PR.
dcdadcd
to
8bade57
Compare
@mvertens - I tried to set up a NOINYOC run using a run script for noresm2.0.6, but based on the What I find is that the grid
|
@TomasTorsvik - we need to add the tn21 grid to ccs_config and also create a mesh for it. I'm happy to do that. |
@TomasTorsvik - you need to use noresm_develop_v7 in order to get the right proessor layout in blom. I was successfully able to do the following:
So I need to add the T62_tn21 and an accompanying test in blom. Should I add any other resolution? |
@mvertens - Thanks for the update, I will try your setup. We often use T62_tn21 for testing, so that would be nice to have. We also use TL319_tn14 for OMIP-2 runs. In addition to T62_tn14, those are the main ones used for OMIP-type runs. |
@TomasTorsvik - thanks so much for confirming this! |
I think this may be a topic that we should discuss in a wider NorESM forum, although in this case it affects an OMIP-type run. My view for noresm development would be to use the same defaults as CESM, until at some point we need to tune the model, |
@matsbn @TomasTorsvik @jmaerz - I was wondering if we could move forwards with merging this tag now given that we have a release branch. I have made progress with the tnx2v1 grid - but it turns out that cice6 does not support that resolution - so getting that in will be more involved than I had expected. As a result - I would like to keep that out of this PR. |
Just as another note - I need to create a new noresm v8 code base so that we can start new coupled model simulations and I'd like to use blom with the new namelist changes as part of that. I would also use this as a new step in migrating the new code from @jmaerz into the nuopc code. |
Dear @mvertens , could you elaborate a bit on what you mean with this migration step of the extended nitrogen cycle? Is there a chance to test, whether the current |
@jmaerz - thanks for laying out a plan. I am confused as to when this PR could then get merged into master. Are you saying that you would like to have all of your PRs merged to master (i.e. #268 and #269) BEFORE we bring in this PR? Maybe a quick chat would be very helpful at this point. Would you have time this afternoon? |
I would have time, yes. However. I fear I am not exactly the right person to decide the steps. My point is that I would like to avoid double work with all the merging processes. My take from the last BLOM/NorESM development meeting with @matsbn was that with the new release branch (#267), we can break CMIP6 backwards compatibility when it comes to scientific results, however, being still able to run NorESM with the MCT coupler was some wish/requirement that @matsbn suggested (if I got it right - please correct me, if I am wrong). My comment is NOT affecting the merging of this PR into As a brief information: thus far, from the iHAMOCC point of view, any developments in |
@jmaerz - thanks for your clarifications. I would definitely expect the new release branch to run with mct - but not necessarily the changes going into master (at least they would not be routinely tested). Sorry if my comment was confusing about the extended nitrogen cycle. I'd like to migrate the changes you needed to put into the mct cap and the mct coupler for your changes to the extended nitrogen cycle into the blom nuopc cap and cmeps. I would view a good starting point for that as being master once this PR is accepted. |
I am also happy to defer the #264 PR until after we get your changes migrated into the NUOPC cap and CMEPS. |
I tried this PR using NorESM2.0.6 (tag release-noresm2.0.6). I got the following error during case.setup:
Other CIME modules seem to load fine using NorESM2.0.6. Do you think it is possible to overcome this issue @mvertens? |
@matsbn - thanks for trying this out. Yes - I can find a way around this I think. |
@matsbn - I'm pushing things back but its not quite working yet. I'll let you know when I have things working. |
Great that you are having a look at this! |
I have gotten it working in terms of the namelist generation and build - but for some reason I submit it to the queue and it starts up and then immediately dies. No log file or anything. I'd like to duplicate exactly what you did. |
@matsbn - I have pushed a fixes back that now enables buildnml work with the older version of CIME that is in the release code with blom replaced by this 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.
I get bit-identical results when testing the NOIIAOC20TR compset in NorESM2.0.6 and ensuring that the number of CICE cores match. This is for both BLOM_VCOORD options (isopycnic, hybrid). The only difference is that bromoform is enabled by default compared to the BLOM master I compared against. Maybe that is intentional, but leave it to @TomasTorsvik , @JorgSchwinger and @jmaerz to comment on that.
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 we can merge this PR now.
If everyone agrees, I can do the merging.
@TomasTorsvik @jmaerz @Mats - thanks all for your careful review of this PR. I think that it will make new regression testing much easier moving forwards. |
This PR refactors the namelist generation in BLOM to use the python based capabilities in CIME. This is the way that CICE, all CDEPS components, CMEPS, WW3DEV and POP generate their namelists. CAM and CTSM still use an older perl based scripting with the intention of moving away from that in the future.
config[]
that is introduced in the new buildnml. Entries in this xml are of the following forms:for real variables:
for file based variables:
Note that
<input_pathname>abs</input_pathname>
is used to create theBuildconf/blom.input_data_list
entries.for character variables:
Testing:
Used the following create_newcase command out of this code sandbox and a code sandbox that had the previous BLOM namelist generation:
./create_newcase --case <CASENAME> --compset 2000_SATM_SLND_SICE_BLOM%ECO_SROF_SGLC_SWAV_SESP --res T62_tn14 --run-unsupported --project <PROJECT> --mach betzy
For the following different grids verified that the sorted namelists were the same
For tnx1v4 verified that the sorted namelists were the same: