Repository navigation
merge noresm cmeps1.1.57_noresm_v0 - #690
Conversation
add BLOM specific settings and update to cmeps0.14.32
new dms flux computation capability in mediator
addition of atm_ncpl for ww3dev testing
new flds to cmeps from ww3 for auxiliary averaged otuput Description of changes Introduction of new fields from ww3dev that can be used for time averaged auxiliary output. Specific notes WW3dev does not have the capability to do time averaged output. By sending these 2d fields to CMEPS and adding them as options to auxiliary output - analysis can be done on time averaged output from ww3dev without needing to introduce new changes in ww3 for time averaged output. Contributors other than yourself, if any: CMEPS Issues Fixed: Are changes expected to change answers? bfb Any User Interface Changes (namelist or namelist defaults changes)? New auxiliary output fields introduced in nuopc.runconfig. Testing performed Verified that the new fields were indeed sent from ww3 and gave reasonable results. Test was SMS_Ld10.T62_wtn14nw.WW3test.betzy_intel.
…queried by ww3dev
make histaux_wav2med_file1_enabled an ALLCOMPS attribute
… auxiliary file output
…itions New auxiliary file for input from ww3dev
billsacks
left a comment
There was a problem hiding this comment.
Thanks a lot for all of these fixes and enhancements! I have a variety of comments, some trivial and some slightly less trivial. For the less trivial ones, it may be easiest if we talk this through. It will be great to get these CMEPS versions synced up!!
| write_histaux_l2x1yrg = .false. | ||
| if (lndAccum2glc_cnt > 0) then | ||
| call NUOPC_CompAttributeGet(gcomp, name="histaux_l2x1yrg", value=cvalue, & | ||
| isPresent=isPresent, isSet=isSet, rc=rc) | ||
| if (ChkErr(rc,__LINE__,u_FILE_u)) return | ||
| if (isPresent .and. isSet) then | ||
| read(cvalue,*) write_histaux_l2x1yrg | ||
| end if | ||
| end if |
There was a problem hiding this comment.
Is there a reason this retrieval of write_histaux_l2x1yrg was moved outside the do_avg conditional block? If I'm reading the code right, it looks like it's only used inside that block. Not a big deal, though....
|
@alperaltuntas - I have gone through this pretty carefully and talked to @mvertens about it. You're welcome to review it if you want, but we feel that you don't have to. So I'm removing you as a requested reviewer, but you can re-add yourself if you want us to wait for your review. |
billsacks
left a comment
There was a problem hiding this comment.
Thanks a lot for addressing my comments, @mvertens . I'm happy with nearly everything you've done. I do have a few new comments based on your changes... some of them may be things that are actually correct but I want to double-check with you.
Beyond that, the one remaining thing to discuss is the logic around irrigation in med_phases_prep_rof_mod.
billsacks
left a comment
There was a problem hiding this comment.
This looks good now! As I discussed with @mvertens , I'll open an issue related to the irrigation change - that doesn't need to hold up this PR.
The remaining to do is rerunning the prealpha tests. I'd like to see a full run of the CESM prealphas on both derecho and izumi with all compilers. @mvertens - it sounded like you're planning to at least run the derecho intel tests. Maybe a good plan could be for you to run those, and then we can ask Chris to run prealphas on the other compilers and on izumi just to confirm there are no issues before merging. (I want to be a little more conservative than usual given how close we are to release.)
|
@DeniseWorthen - would you like to look at this or run any testing on it before it's merged? |
|
@billsacks Thanks, except for the ocean albedo changes I don't think anything would touch UFS, and from my reading of the code even that should be fine. Let me run a couple of quick tests just to verify. |
|
Thanks a lot for your quick reply @DeniseWorthen ! |
|
@billsacks This appears fine for us; thanks for checking. |
|
Thanks for confirming @DeniseWorthen ! |
|
@billsacks - I ran the cesm prealpha tests for both intel and gnu and compared to cesm3_0_alpha10a. I think the diffs are expected. |
|
Awesome, @mvertens - thank you very much! I looked at the two tests with diffs - ERS_Ly7.f09_g17_gris4.T1850Gg.derecho_intel and SMS_D_Ld2.f19_g17.X.derecho_intel.drv-water_tracers--drv-glc_avg_frequently. I have confirmed that your tests are bit-for-bit when comparing against cesm3_0_alpha10c, which confirms for me that the diffs are just coming from your update to the latest CMEPS (which changes answers for some cases), not from changes in your branch. So this looks great to me. I'll check in with @fischer-ncar about whether he wants to run the remaining pre-alphas (derecho-nvhpc, izumi) before we merge this. |
|
Out of an abundance of caution, I decided to go ahead and run the remaining prealpha tests on this PR:
|
Description of changes
Merge changes from noresm cmeps1.1.57_noresm_v0 back to ESCOMP
Specific notes
In particular, this has enthalpy computation changes in the mediator that would occur for NorESM if CAM computed the enthalpy. However, although these hooks are in CMEPS - the computation of enthalpy in CAM has not been brought over to the main development branch yet.
In addition if the nuopc.config variable
histaux_l2x1yrg = .true.thenif there is ocn2glc_coupling then the following mediator auxiliary file will be created:
trim(case_name),'.cpl',trim(inst_tag),'.hx.lnd2glc.',trim(nexttime_str),'.nc'if there is lnd2glc_coupling then the following mediator auxiliary file will be created:
trim(case_name),'.cpl',trim(inst_tag),'.hx.lnd2glc.',trim(nexttime_str),'.nc'Also - this PR might potentially interfere with PR #683
Contributors other than yourself, if any: None
CMEPS Issues Fixed: None
Are changes expected to change answers? bfb
Any User Interface Changes (namelist or namelist defaults changes)?
Testing performed
Ran prealpha-intel using cesm3_0_alpha10a sandbox with this PR and compared to cesm3_0_alpha10a -
intel failures:
gnu failures: