Fix an error in COSP 1.4 MODIS simulator

[wlin7]

This update fixes an error in the calculation of NIR reflectance that affects cloud fields derived from MODIS simulator. As a tentative arrangement, the fixes are only effective when the CPP directive
-DAPPLY_POST_DECK_BUGFIXES is applied to CAM_CONFIG_OPTS, which can be specified in compsets of interest in components/cam/cie_config/config_components.xml.

The impact is generally small.

Modified: components/cam/src/physics/cosp/MODIS_simulator/modis_simulator.F90

[non-BFB] for COSP-MODIS simulator diagnostics output when the CPP directive is defined
[BFB] all else

[singhbalwinder]

merged to next

[singhbalwinder]

@wlin7 : Do you think it will be NBFB for COSP tests? I see a failed test on CDASH and was wondering if this PR broke that test.

[singhbalwinder]

I talked with @wlin7 offline and we found out that the following diagnostic variables are causing the COSP test to break:

CLHMODIS CLIMODIS CLMMODIS CLMODIS CLTMODIS IWPMODIS LWPMODIS PCTMODIS REFFCLIMODIS REFFCLWMODIS TAUILOGMODIS TAUIMODIS TAUTLOGMODIS TAUTMODIS

@PeterCaldwell , @golaz and @rljacob : Is it okay to merge this NBFB PR?

[rljacob]

This may have to wait until post v1. The CMIP6 runs are all being done with COSP output (and without this fix) and v1 should give the same values.

[rljacob]

@wlin7 please open an issue that describes the problem this PR fixes.

[wlin7]

@rljacob , the issue #2113 has been created to describe this.

Since the bulk of the CMIP6 simulations are yet to be completed, it is very meaningful, as long as still possible, to include this fix for V1 simulations.

Only the diagnostic COSP MODIS output are affected and a pair of test simulations show the impact is limited.

[rljacob]

Its up to @golaz

[singhbalwinder]

Thanks @rljacob and @wlin7 . This PR is already merged to next and breaking a test. Should I revert it back until we hear back from @golaz ?

[golaz]

Since the low-res DECK simulations are already 1/3 done, I don't think we can change this mid-course. The report states that "the impact is generally small", so does it mean we can still do useful science with the COSP MODIS simulator output?

[zyuying]

@golaz This is the bug in the released COSP. It was recently found by the COSP MODIS simulator developer. He just notified COSP users of the bug in the simulator code and sent the patch on Feb 1st. The error affects all MODIS simulator variables only when clouds with both liquid and ice visible from space. It was suggested by them to either update the COSP with the patch or submit to CMIP6/CFMIP3 with affected diagnostics omitted without the patch. Based on their suggestion, I would suggest we deal with this until post v1.

[wlin7]

Hi @golaz , @zyuying , The "generally small impact" was based on the contrast of two 15- month simulations, and it could still be small over longer term simulation. But given the developer's suggestion, they would consider all data unusable without patch.

COSP MODIS is useful for a number of cloud diagnostics, like the variables @singhbalwinder listed. It can still be very meaningful (and likely more than sufficient) for any practical interest of analyzing MODIS simulator output if 2/3 of each DESK simulations have good MODIS output. There will definitely be inconvenience switching the code base in the middle of the run, though.

[singhbalwinder]

Reverted from next. This PR is now a Post V1 candidate.

[wlin7]

Hi @singhbalwinder , @rljacob ,

We now want to apply the known bug fixes (such as this one, and a radiation imbalance fix in clm, which involves multiple files and is in branch bishtgautam/lnd/radiation-fix).

The idea is to apply these fixes in high-res coupled runs using 1950 compsets, because they are expensive to run ( and to avoid re-run). A flag must be implemented to switch the modified codes on and off.

If using a single namelist variable, e.g., apply_post_deck_bugfixes, because it needs to be used by multiple model components, I initially thought of adding it to infodata in cime, just like the gustiness parameter 'gust_fac'. But whether it works may depend on PE settings.

The simplest I can think of is to use CPP macro like -DAPPLY_POST_DECK_BUGFIXES. It can be added to components/cam[clm]/cime_config/config_component.xml in CAM_CONFIG_OPTS and CLM_CONFIG_OPTS for atm and lnd, respectively, for certain compsets (e.g., 1950_CAM5%CMIP6-HR_CLM45).

Other than the above, the flag can be implemented as namelist variable for atm and lnd components separately, and pass it down the code flow to the destination routines.

Your opinions on these are much appreciated.

[wlin7]

@singhbalwinder , just like PR #2202 , the CPP directive APPLY_POST_DECK_BUGFIXES have been added to this PR, and putting back the codes before the fix. The two pieces of codes are controlled by the CPP directive which will be set separately for selected compsets.

[wlin7]

@rljacob , @bishtgautam , I ran into merge conflict for this PR, just like when merging #2124. This PR was previously merged to next but then reverted for post V1. The codes are now further updated with CPP directive.

Revert the revert than merge does not work this time. Can you please help with this? Thanks.

[rljacob]

Another approach would be to rebase this branch. Then you can just merge without a revert-revert.

[singhbalwinder]

I have resolved the conflict and merged this PR to next.