OLR computations
Tue, Jan 15, 20191 Location 1 : ecRad CodeDir
/home/sergio/IR_NIR_VIS_UV_RTcodes/ECRAD_ECMWF_version_of_flux/ecRad/create_ecrad_inputSergio
See eg driverrtperatonc.m
2 Location 2 : RRTM TwoSlab Code
/home/sergio/IR_NIR_VIS_UV_RTcodes/RRTM/v3.3/rrtm_lw/Clouds_Flux_Rates
See eg clusterrunrrtm.m
3 Reference for ecRad
"A Flexible and Efficient Radiation Scheme for the ECMWF Model", R. Hogan and A. Bozzo, July 2018, JAMES, https://doi.org/10.1029/2018MS001364
4 Overview of Flux Calcs
Our simple yet accurate representation for clouds, namely the TwoSlab method, has been demonstrated to show that it can statistically reproduce AIRS observations for all channels/under all cloud conditions. This method represents clouds as slabs, and so when computing fluxes will have large derivatives at cloud edges, making it unsuitable for use in GCMs where atmospheric heating rates are better behaved.
Still, it's simplicity meant the idea could be quickly implemented into the RRTM flux computation code, and during the October 2018 AIRS STM, we showed that it could produce fluxes that agreed quite well with CERES measurements, though there was a negative bias (ie it was usually too low by about 10 W/m2 at all latitudes).
Marco Matricardi (ECMWF) suggested that I try the ecRad flux solver that has been recently implemented by Robin Hogan at ECMWF. He has supplied the code to me, and after some work on the Makefile (namely to point to the netcdf directories), I have got it to run (ps I also found a couple of bugs since all I need is LW fluxes, and opting for this caused the SW solver to get rather upset).
The supplied code has three flux solvers :
- McICA which is the older Monte Carlo Indpt Column Approximation representation used for overlapping clouds, rewritten as the McRad code
- Tripleclouds which is more accurate
- SPARTACUS (Speedy Algorithm for Radiative Transfer through Cloud
Sides) which is lower but has 3D cloud effects
The speed reduction means choice (3) is not being used in the IFS code, but can be used as a research tool
5 Comparions of ecRad versus RRTM 2Slab calculations
I have run the code in TripleClouds mode, for eg a granule (12150 profiles) or a day's worth of stats (about 20000 profiles). It runs very fast (partly because it is written in OpenMP).
I have also written a RRTM TwoSlab wrapper so it dumped the rtp file onto many processors. The "clusterrunrrtm.m" code in ECRADECMWFversionofflux/ecRad/createecradinputSergio/ can be run either in "as is" mode where the 2Slab clouds in the rtp file are left unchanged (probably from the (P)eak position) or can be changed to a (C)entroid position, which even in radiance space is closer to other scattering RTA cloud models
The comparisons indicate that RRTM 2S (P)eak produces OLR that are also smaller than ecRad (similar to what I said about CERES above). While RRTM 2S (C)entroid OLR that are much closer to ecRad.
Figures 1 and 2 shows the OLR comparisons for about 20000 random daily profiles saved in /asl/rtp/rtpairicradv6/random/2017/eraairicradday001random.rtp
Figure 1 shows the comparisons when the 2Slab clouds are (P)eak mode before being run through the RRTM wrapper. There is definitely a bias offset between ecRad in 2Slab fluxes run in this mode. The left panel shows the individual OLR calculations, with the colorbar being BT1231; the right panel shows the calculations in the top panel (and differences in the bottom panel) as a function of latitude.
Figure 1: Comparison between ecRad and 2Slab RRTM when the clouds are in (P)eak position. One notices about a 5 W/m2 bias between the two
Figure 2 shows the comparisons when the 2Slab clouds are (C)entroid mode before being run through the RRTM wrapper. Compared to the previous figure, there is a noticeable improvement in the difference, especially near the equator.
Figure 2: Comparison between ecRad and 2Slab RRTM when the clouds are in (C)entroid position. One notices about a smaller biae between the two calcs in this case
6 OLR Rates
I ran ecRad for 15 years of AIRS (note 2006,2012,2015 are totally missing) stashed in /asl/rtp/rtpairicradv6/random/20XY/eraairicraddayABCrandom.rtp; It took about 12 hours on N processors. After that I read in each OLR file and averaged over our standard 40 equal area latbins. From this I was able to (a) compare to CERES (b) compare to RRTM 2slab (P)eak and (c) compare OLR rates.
Note that (a) I have run bith constannt (380 ppm) and a time varying CO2 and (b) I have not re-run the individual rtp files to change the 2Slab clouds from (P)eak to (C)entroid.
In any case, the results demonstrate that (a) the ecRad calcs are much closer to CERES products than 2Slab RRTM (P)eak, as seen in Figure 3.
Figure 3: Comparison between ecRad (CO2 fixed at 380 ppm) and 2Slab RRTM (P) with time varying CO2, and CERES L3 product. Clearly ecRad is superior to the 2Slab (P) calculations.
Further Figure 4 shows the OLR rates from CERES and from ecRad. Note that I have not shown the "raw" 2SLab RRTM (P)eak rates since they are significantly different at the tropics, for example -1 W/m2/yr in the tropics. The linearly varying CO2 rates are slightly less than th const CO2 rates, as expected (if a doubling of CO2 reduces clear sky OLR by 4 W/m2, then one would expect an increase of 2.2 ppmv/yr to reduce OLR by about 0.022 W/m2/yr)
Figure 4: Comparison between ecRad (CO2 fixed at 380 ppm) and CERES L3 rates. They are in reasonable agreement (within error bars) except at the equatorial region. The two panels are (L) constant CO2 (R) linearly varying CO2, and differ from each other by a small amount, see accompanying text.
7 Conclusions
(a) The (C)entroid TwoSlabs are statistically closer to CERES obs than the (P)eak TwoSLabs. Though I will state in terms of BT1231, the (P) clouds are closer tto AIRS observations than are the (C)entroid slabs … (b) OLR rates using ERA clouds and ecRad are closer to CERES than (P)eak 2Slab clouds. (c) Time permitting I will rerun ecRad with varying CO2, and perhaps TwoSlab RRTM fluxes at (C)entroid