Add four new joint histograms to the MODIS simulator
Four new joint histogram diagnostics are computed and added to the MODIS simulator (shown in attached slide2). The diagnostics include : 1&2) “CLLIQMODIS” and “CLDICEMODIS” : cloud-fraction joint histograms partitioned by cloud-top pressure (CTP) vs. cloud optical thickness (COT) for liquid-topped clouds and ice-topped clouds, respectively 3) “LWPRLMODIS” : LWP vs. cloud particle size (CER) histogram for liquid-topped clouds 4) “IWPRIMODIS” : IWP vs. CER histogram for ice-topped clouds
The joint histograms match the MODIS observational dataset described by Pincus et al. 2023.
Also, the CER edges of the histogram bins have been changed slightly from their original versions. Three changes are : (1) The lower bound of the smallest CER bin for liquid-topped clouds has been changed from 0 microns to 4 microns (2) One of the CER bin edges has been changed from 13 microns to 12.5 microns (3) The lower bound of the smallest CER bin for ice-topped clouds has been changed from 0 microns to 5 microns
This causes minor changes in the MODIS joint histograms (“CLRLMODIS” and “CLRIMODIS”) with CER as a dimension (shown in attached slide1). No other variables are affected by the code modifications.
File changes: cosp2/Cosp.cmake cosp2/local/cosp.F90 cam/cospsimulator_intr.F90 Add cosp_config.F90 and modis_simulator.F90 into cosp2/local MODISdiag_jointhist.pdf
[NBFB]
PR Preview Action v1.4.7
:---:
:rocket: Deployed preview to https://E3SM-Project.github.io/E3SM/pr-preview/pr-6407/
on branch gh-pages at 2024-06-05 20:55 UTC
@wlin7 please review.
@wlin7 will test again.
@rljacob , this PR add new variables, also cause two existing diagnostics variables to differ. But the affected two variables (CLRLMODIS and CLRIMODIS) are not among the requested output for v3.LR simulation campaign. Sounds safe to have this on master (though standard tests not exactly reproducing eam.h0). We may also add it to v3.0.1 milestone, as it enhances the COSP diagnostics suite.
@singhbalwinder can you merge this to next today?
Merged with next.
I also labeled it NBFB as @wlin7 mentioned above that it may cause NBFB for two diagnostic variables.
To any of our tests output those variables?
I am not sure. We have some COSP tests, so it might cause NBFB answers for those tests.
I see the following COSP test failing on next Chrysalis:
ERS_Ln9.ne4pg2_ne4pg2.FRCE-MMF1.chrysalis_intel.eam-cosp_nhtfrq9
SMS_D_Ln5.ne4pg2_oQU480.F2010.chrysalis_intel.eam-cosplite_nhtfrq5
The RMS diffs are in the following variables for the ERS COSP test:
cosp_reffice
cosp_reffice_bnds
cosp_reffliq
cosp_reffliq_bnds
CLRIMODIS
The RMS diffs are in the following variables for the SMS COSP-lite test:
cosp_reffice
cosp_reffice_bnds
cosp_reffliq
cosp_reffliq_bnds
CLRIMODIS
CLRLMODIS
Does that look right? Should I go ahead and merge it and ask to bless these tests?
@zyuying please see above
Yes, @singhbalwinder . Those diffs are expected as described in the PR message and the comment above. The bin center and bounds for cosp_ref### and _bnd are updated, causing existing variables CLRIMODIS and CLRLMODIS to also differ.
Other tests (e.g., prodt tests) that report diffs in eam.h# files are due to the changes in these four coordinate variables:
cosp_reffice , cosp_reffice_bnds, cosp_reffliq, cosp_reffliq_bnds, even when the actual COSP cloud fields are not output.
@singhbalwinder, the diffs are expected as mentioned in the description of this PR. @wlin7, thanks for your explanation. Please go ahead to merge it. Thanks.
Thank you both for verifying. Merged to master.
Issued bless requests for Chrysalis and pm-cpu next branch for the following tests:
ERS_Ln9.ne4pg2_ne4pg2.FRCE-MMF1.<machine>_<compiler>.eam-cosp_nhtfrq9
SMS_D_Ln5.ne4pg2_oQU480.F2010.<machine>_<compiler>.eam-cosplite_nhtfrq5
Anything with "wcprod" testmod will have COSP output in it and needs to be blessed. Thats the entire prod suit and a few more cases in integration.
I have asked for the following blesses as well:
Chrysalis integration: SMS_D_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.chrysalis_intel.allactive-wcprod SMS_D_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCLSSP370.chrysalis_intel.allactive-wcprodssp
Anvil prod: SMS_Ld1.ne30pg2_EC30to60E2r2.WCYCL1850-4xCO2.anvil_intel.allactive-wcprod SMS_Ld1.ne30pg2_EC30to60E2r2.WCYCLSSP585.anvil_intel.allactive-wcprodssp
PM-CPU Prod: SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.F20TR.pm-cpu_intel.eam-wcprod_F20TR SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850-1pctCO2.pm-cpu_intel.allactive-wcprod_1850_1pctCO2 SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850-4xCO2.pm-cpu_intel.allactive-wcprod_1850_4xCO2 SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.pm-cpu_intel.allactive-wcprod_1850 SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCLSSP370.pm-cpu_intel.allactive-wcprodssp SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCLSSP585.pm-cpu_intel.allactive-wcprodssp SMS_Ld1_PS.northamericax4v1pg2_WC14to60E2r3.WCYCL1850.pm-cpu_intel.allactive-wcprodrrm_1850 SMS_Ln5.ne30pg2_r05_IcoswISC30E3r5.F2010.pm-cpu_intel.eam-wcprod_F2010
Chrysalis prod: SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.F20TR.chrysalis_intel.eam-wcprod_F20TR SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850-1pctCO2.chrysalis_intel.allactive-wcprod_1850_1pctCO2 SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850-4xCO2.chrysalis_intel.allactive-wcprod_1850_4xCO2 SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.chrysalis_intel.allactive-wcprod_1850 SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCLSSP370.chrysalis_intel.allactive-wcprodssp SMS_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCLSSP585.chrysalis_intel.allactive-wcprodssp SMS_Ld1_PS.northamericax4v1pg2_WC14to60E2r3.WCYCL1850.chrysalis_intel.allactive-wcprodrrm_1850 SMS_Ln5.ne30pg2_r05_IcoswISC30E3r5.F2010.chrysalis_intel.eam-wcprod_F2010
PM-CPU integration: SMS_D_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.pm-cpu_intel.allactive-wcprod SMS_D_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCLSSP370.pm-cpu_intel.allactive-wcprodssp
Is there a plan to push these additional diagnostics upstream to the COSP2 repo? Are these consistent with MODIS retrieval products? I'm a little worried that keeping our own copies of these source files around for too long will expose us to getting behind COSP development/bug fixes and will tend to isolate us from that community a bit.