major refactor stream of stream usage#376
Conversation
…mode specific streams
…d_stream_usage' into feature/refactor_stream_usage
…t field pointers to nans
…ams' into feature/refactor_stream_usage
…efactor_stream_usage
…al_streams' into feature/refactor_stream_usage
|
Just flagging this, as we'll want to test with CTSM when we update our submodules, @ekluzek. |
|
|
@fischer-ncar - can you please add one more test, with baseline comparisons: |
|
Here's the prealpha test results I have so far. I'm still running the extra tests that @billsacks wanted me to run. The above tests all failed with no comp_calss for rof. Then there was a couple of small answer changes. |
|
Here's the three other tests that @billsacks wanted me to do. |
|
I had a look at test SMS_Ld40.TL319_t232.C_JRA.derecho_intel
which has a compset
longname: 2000_DATM%JRA-1p5-2023_SLND_DICE%SSMI_MOM6_DROF%JRA-1p5-2023_SGLC_SWAV_SESP
the DROF part of that is
DROF%JRA-1p5-2023
and I don't see a description for JRA-1p5-2023 in the config_component.xml
file. The error message is a bit misleading I think.
I confirmed that adding a description for JRA-1p5-2023 solves the problem.
…On Thu, Jan 22, 2026 at 4:57 PM fischer-ncar ***@***.***> wrote:
*fischer-ncar* left a comment (ESCOMP/CDEPS#376)
<#376 (comment)>
Here's the three other tests that @billsacks
<https://github.com/billsacks> wanted me to do.
PASS SMS_D_Ld2.T62_t232.G.derecho_gnu RUN time=351
FAIL SMS_D_Ld5.f10_f10_mg37.ISSP245Clm60BgcCropCrujra.derecho_intel.clm-datm_rcp45_anom_forc BASELINE cesm3_0_alpha08b: DIFF
lndExp_Sa_co2prog (lndExp_nx,lndExp_ny,time) t_index = 1 1
456 456 ( 1, 1, 1) ( 1, 1, 1) ( 1, 1, 1) ( 1, 1, 1)
456 3.999488830566406E+02 3.999488830566406E+02 4.0E+02 3.999488830566406E+02 1.0E+00 3.999488830566406E+02
456 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00
456 ( 1, 1, 1) ( 1, 1, 1)
avg abs field values: 3.999488830566406E+02 rms diff: 4.0E+02 avg rel diff(npos): 1.0E+00
0.000000000000000E+00 avg decimal digits(ndif): 0.0 worst: 0.0
RMS lndExp_Sa_co2prog 3.9995E+02 NORMALIZED 2.0000E+00
FAIL ERS_Ld5.TL319_t232.G_IAF.derecho_intel.cice-default CREATE_NEWCASE
ERROR: grid alias TL319_t232 not valid for compset 2000_DATM%IAF_SLND_CICE_MOM6_DROF%IAF_SGLC_SWAV_SESP
—
Reply to this email directly, view it on GitHub
<#376 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABOXUGAXZRTJUACCEWBZUUL4IFIVZAVCNFSM6AAAAACRMTMMLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBXGE2TIOBTGE>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
--
Jim Edwards
STAND UP FOR SCIENCE
CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO
|
|
@fischer-ncar - thanks a lot for this testing report! And @jedwards4b - thanks for your input. I have just pushed a commit that restores the JRA-1p5-2023 mode for DROF that I think should fix the issues with G_JRA and C_JRA compsets. (@mvertens - I assume your removal of that mode for DROF was accidental? As far as I can tell the mode should still work but it looks like it was accidentally removed from DROF's config_component... but please let us know if there was a reason why you removed it.) @fischer-ncar - can you please retry the failed tests with this latest version? The changes in lndExp_Sa_o3 and lndExp_Sa_co2prog are expected based on changes from #373 (but are expected not to feedback to cause any other differences in typical configurations). For the failing G_IAF case, can you instead try @fischer-ncar - I have poked around in Have you run the extra tests noted in #376 (comment) - the ones under (1), (2), and the additional DTEST and E1850TEST test, in addition to the more recent additions that I copied at the bottom of that comment? Thanks again for all of your testing of this! |
|
@billsacks - the removal of JRA-1p5-2023 was a mistake that I made in trying to sync the changes between the PR to NorESMHub and ESCOMP. @jedwards4b - thanks for suggesting the fix. @fischer-ncar - thanks for all of your testing. |
|
@billsacks I missed those tests, I'll run them now. |
|
All of the tests with the missing JRA-1p5-2023 have passed. So all of the prealpha tests are now good. For the extra tests @billsacks wanted me to do, the following passed. Of the tests that passed, two of the tests failed to generate complete baselines, which is not an issue with this PR. This test passed, with expected answer difference caused by #373. Then this test failed with a missing grid alias. I believe I've run all of the extra tests. |
|
@fischer-ncar - thanks a lot for this additional testing. I have looked back at the tests you ran compared with what I asked for in various places, and it looks like you have gotten everything - thank you! Regarding the failures in your most recent set:
So, from the CESM side, I feel like this testing now looks good! @NickSzapiro-NOAA - is this good to go at this point from the UFS perspective? @jedwards4b - do you want to look at this before it's merged or should we remove you as a reviewer? @mvertens - is there anything else you can think of before this is merged? |
What component added this test to the test list? I don't see it in testlist_mom.xml, but the Nevermind -- I dug around a little bit and found it in the CICE testlist, but it has been recently replaced with a |
|
Thanks for that extra info, @mnlevy1981 . My motivation for running G_IAF for this PR is that I wanted to make sure that the |
|
I don't think IAF is going away, but If I remember right, we intentionally prevented CORE forcing from running on the |
|
Thanks for this additional information, @mnlevy1981 . This makes sense. If |
@NickSzapiro-NOAA - I just wanted to add: from discussion with @mvertens , we're not able to work on the UFS ERA5 issue because it's not part of this repository, so just checking whether you're okay with this PR other than that issue. |
Yes. All UFS RTs passed except for datm_cdeps_lnd_era5_intel. @uturuncoglu is author of that test and was involved here. I will say that I'm not so clear on what's needed on UFS side, but it seems that we can follow on there. Thanks for asking |
* Standardise jra55do datamode with other updates to CDEPS (ESCOMP#376)
| if (associated(Faxa_swvdr)) Faxa_swvdr(:) = strm_Faxa_swdn(:)*strm_Faxa_swvdr(:) | ||
| if (associated(Faxa_swndr)) Faxa_swndr(:) = strm_Faxa_swdn(:)*strm_Faxa_swndr(:) | ||
| if (associated(Faxa_swvdf)) Faxa_swvdf(:) = strm_Faxa_swdn(:)*strm_Faxa_swvdf(:) | ||
| if (associated(Faxa_swndf)) Faxa_swndf(:) = strm_Faxa_swdn(:)*strm_Faxa_swndf(:) |
There was a problem hiding this comment.
Can this be deleted? Values are overwritten below in convert J/m^2 to W/m^2 , no?
It's confusing that code treats, say, same term strm_Faxa_swvdr as albedo then radiative flux
There was a problem hiding this comment.
@NickSzapiro-NOAA When I was implementing ERA5 for HAFS, I had a discussion with ECMWF and those variables (Faxa_swvdr) initially storing the coefficients not the exact heat flux in the bands. So, I decided to go with this implementation to calculate shortwave flux in bands. Now we have some issues with it in UFS Coastal and made some changes in the ERA5 data mode. We are testing with CICE coupled configuration at this point and I am plaining to create minor PR in CDEPS side to bering those changes to UFS WM. So, we will clean this implementation soon. Let me know what you think?
There was a problem hiding this comment.
ok, I didn't know if I was just confused. Thanks for explaining @uturuncoglu
8 participants
Description of changes
Major refactor of stream usage
Specific notes
All data mode files across the data components(except for
datm_datamode_gefs_mod.F90anddice_datamode_cplhist_mod.F90) now have explicit setting of streams rather than using the implicit copy used bydfields. Copies that used to be done implicitly using the naming convention assumed by dfields arenow done explictly. This makes it clear what export fields are direct copies and what export fields are
derived fields that have no corresponding stream field.
In each datamode module - there are now two sections in the module variable list:
export (and sometimes import) state pointersandstream pointer.The following changes have been made throughout the code:
character(*) => character(len=*),trim(subname) => subname(the latter is done since parameters, e.g.subname, don't need trim functions)The following new routines have been introduced or deleted:
drof_datamode_cplhist_mod.F90) to support this addition.docn_datamode_copyall_mod.F90anddocn_datamode_iaf_mod.F90into a new filedocn_datamode_sstdata_mod.F90. The two filesdocn_datamode_copyall_mod.F90anddocn_datamode_iaf_mod.F90were effectively the same and two different datamodes are not needed since in both cases prescribed SST data was read in. (In addition, docn_datamode_iaf_mod.F90` set pointers to importState data which was never used and not needed).NOTE: This PR also provides a new mapfile algorithm as a new option for mapping the streams input to the component model resolution. The new scheme does not have a default but is enabled via adding the following in the appropriate user_nl_XXX_streams where the user needs to fill in the entries in <> below:
<stream_name>:mapalgo = "mapfile:
As an example:
rof.ryf8485_jra:mapalgo="mapfile:/cluster/shared/noresm/inputdata/cpl/cpl6/map_JRA025_to_tnx1v4_e1000r300_170928.nc". This new capability enables a significant speedup in stand-alone ocean simulations. See NorESMhub/BLOM#686 (comment).NOTE*:
Contributors other than yourself, if any: None
CDEPS Issues Fixed: #377
Are there dependencies on other component PRs (if so list):
Are changes expected to change answers (bfb, different to roundoff, more substantial):
Any User Interface Changes (namelist or namelist defaults changes):
Testing performed (will describe the noresm testing here)
Hashes used for testing: noresm3_0_beta09 plus this CDEPS branch