CLWRF tracer gases are not used in RRTMG shortwave code

[weiwangncar]

Describe the bug
CLWRF tracer gases are not used in RRTMG shortwave code

The code to use CLWRF tracer gases was added to the model in 2013. The option is available to a few radiation options: RRTM lw, CAM lw and sw, RRTMG lw. The option is activated by adding a compile option -DCLWRFGHG to configure.wrf file on the ARCH_LOCAL line.

A question posted to the original contributor, Jesus Fernandez, is if this is intentional?

[dudhia]

The easiest fix is to duplicate the longwave call to CAMgases. This keeps them from relying on each other.

…

On Fri, Dec 10, 2021 at 11:17 AM weiwangncar ***@***.***> wrote: *Describe the bug* CLWRF tracer gases are not used in RRTMG shortwave code The code to use CLWRF tracer gases was added to the model in 2013. The option is available to a few radiation options: RRTM lw, CAM lw and sw, RRTMG lw. The option is activated by adding a compile option -DCLWRFGHG to configure.wrf file on the ARCH_LOCAL line. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1597>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77F2KS6XGXQTD4WNILDUQI733ANCNFSM5JZXRUJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[weiwangncar]

Comment from Jesus Fernandez of Instituto de Fisica de Cantabria CSIC-UC, Santander, Spain: I'd say it is intentional, but not ideal. If I remember correctly, GHG variation was started by us in U. Cantabria, where Lluis Fita modified the CAM radiation code (thus, the CAMtr naming of the GHG files), which included both SW and LW. This procedure was ported to RRTM in UNSW (Australia), which only handled LW radiation and was typically used in combination with the Dudhia SW scheme. I guess this moved to the LW component of RRTMG when this scheme appeared.

I think there is a need to define the forcings in a consistent way across all physics schemes. E.g. there are also inconsistencies with the NoahMP CO2 levels (SantanderMetGroup/WRF4G#30), which may affect evapotranspiration through stomatal resistance.

This PR only updated the static files with the GHG concentrations, though. No changes were done to the code. Maybe this discussion should be moved to a new issue.

[weiwangncar]

@dudhia @jesusff We are looking into this because we are thinking of using the tracer gas data for all WRF runs since the datasets have historical values, and it should be better than using a single constant for all cases. Like Jimy said, we could move similar code from RRTMG lw to RRTMG sw to enhance the capability.

Currently, the data is interpolated for every radiation step. I'd say we probably could change that to once every day. I'd also prefer to add this as a namelist option rather than compile option. Comments?

[davegill]

@weiwangncar @dudhia @jesusff

1. This should definitely be designed as a namelist option. Hard-coding options should be reserved for particularly hard situations (ARW vs NMM core, model vs DA). This is clearly a run-time decision.
2. The amount of time spent to interpolate half a dozen values is inconsequential, particularly for a radiation scheme. There is no need to change the existing interpolation strategy. Is the entire "array" of data in memory? We would not want to be reading and bcasting data at each radiation step.
3. If the code is moved to RRTMG sw, then does the code go into ALL of the family of RRTMGs, such as fast and Korea?

[weiwangncar]

@davegill Regarding item 2, the code reads the data every time, and from the radiation routine (no broadcasting needed), but the time is indeed negligible. I just think it is not necessary. This option is added to RRTMG fast, so we probably should correct that option. But the KIM RRTMG may not be modified - it doesn't use it currently.

[davegill]

@weiwangncar
Just like with other lookup tables, we should read this whole table in at one time, and broadcast it at one time. It is a few hundred lines long, with < 10 gasses. This is small compared to other lookup tables.

[weiwangncar]

@jesusff Are files CAMtr_volume_mixing_ratio.A2 and CAMtr_volume_mixing_ratio.A1B used? If so when would they be used?

[jesusff]

Hi,

even if the effect will arguably be much smaller for SW than for the LW, I agree that a consistent forcing should be used. I'd also be happy to see it converted into a namelist option, rather than having to recompile the model to activate it. For climate simulation, variable GHG is important even for evaluation runs nested into reanalysis (https://doi.org/10.1038/s41467-018-03527-y) and its use has been adopted in the latest CORDEX protocol (https://cordex.org/wp-content/uploads/2021/05/CORDEX-CMIP6_exp_design_RCM.pdf). For consistency, I think it would also be useful for shorter, past case studies, since the GHG concentrations are usually hard coded into the different parameterizations with values according to the levels at the time of developing or updating the code, which can be quite different from the values during a particular case study.
Regarding the update times, it can be even coarser than daily. Note that there is a seasonal cycle in the concentrations which is not captured by the annual values in CAMtr_volume_mixing_ratio, so the interpolation is more a matter of having a smooth evolution, than of missing a particular sub-yearly variability.

@weiwangncar A2 and A1B files correspond to the GHG scenarios used in the IPCC AR3 and AR4. They are quite old now (proposed in 2000), and unlikely to be used today for any simulation. They could be used to try to reproduce older runs, though. Although they were packed into older WRF releases, so they could be removed from current releases if this is why you are raising the question. I would say RCPs (AR5) and SSPs (AR6) will be the ones used.

Finally, we could take the opportunity to change the name of the input file to remove the CAM mention, which is misleading. Or leave it to the user, with an option such as:

variable_ghg = .true.
variable_ghg_file = 'GHG_volume_mixing_ratio.SSP370'

or like sst_update:

ghg_update = .true.
ghg_input = 'GHG_volume_mixing_ratio.SSP370'

Although this naming would be climate-oriented and maybe misleading for other uses, where the variability of GHG is not the important aspect, but the specific fixed values used. Maybe:

ghg_from_file = .true.
ghg_file = 'GHG_volume_mixing_ratio.SSP370'

What would happen when this option is set to false? Back to hard-coded values in the different parameterizations?

[LluisFB]

Thanks @jesusff for noticing me about this.
Files were called 'CAM_tr_...' because we initially introduced it to be use only for CAM radiation scheme, but of course it does not make sense.
We introduced the -DCLWRFGHG as a way to allow people to run the model without the modification, just in case we introduced an error. But if now is going to be use for all radiative options, of course it does not make sense at all that the same names are maintained. Files are read once and kept in memory at the first time step and linearly temporally interpolated at each time step step that the radiation scheme is called.
I am wondering if this is going to be a standard procedure for all radiation schemes, would not make sense to introduce a new subroutine were all the GHG gases are interpolated and passed to the module_radiation_driver as new input values to be used for all radiation schemes? Would it be too difficult?
Remember that these are global mean values. Also there are not (as far i know) the correspondent files for AR6-SSP scenarios yet prepared. I look up on the CMIP/IPCC sources and I had difficulties to understand which CFC-xx have to be added to come up with the CFC-11 and CFC-12 evolution. I see that with WRF4.3.1 there are some new concentration files, but are they for all the possible combinations [escenario]-[ssp]?
I do not understand why there is a need to remove the A1B, A2
Happy to help if needed

[jesusff]

@LluisFB I prepared some of the SSP concentrations that are now available (#1553). Not all combinations, but just the more standard ones and including those to be used in CORDEX. The code producing these new files is here https://github.com/SantanderMetGroup/wrf-ghg-files and could be used to generate other files.

[dudhia]

For now, we just want to make it the default in the radiation schemes that already have it plus RRTMG SW. This is probably as much as we can do for this release, Jimy

…

On Mon, Dec 13, 2021 at 5:55 AM Jesus Fernandez ***@***.***> wrote: @LluisFB <https://github.com/LluisFB> I prepared some of the SSP concentrations that are now available. Not all combinations, but just the more standard ones and including those to be used in CORDEX. The code producing these new files is here https://github.com/SantanderMetGroup/wrf-ghg-files and could be used to generate other files. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1597 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77FDRIPSNSKNIDSERATUQXUNTANCNFSM5JZXRUJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dudhia]

We also likely will only update the input once per day to save calculations.

…

On Mon, Dec 13, 2021 at 9:18 AM Jimy Dudhia ***@***.***> wrote: For now, we just want to make it the default in the radiation schemes that already have it plus RRTMG SW. This is probably as much as we can do for this release, Jimy On Mon, Dec 13, 2021 at 5:55 AM Jesus Fernandez ***@***.***> wrote: > @LluisFB <https://github.com/LluisFB> I prepared some of the SSP > concentrations that are now available. Not all combinations, but just the > more standard ones and including those to be used in CORDEX. The code > producing these new files is here > https://github.com/SantanderMetGroup/wrf-ghg-files and could be used to > generate other files. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1597 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEIZ77FDRIPSNSKNIDSERATUQXUNTANCNFSM5JZXRUJA> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > >

[LluisFB]

And I guess there is no neither time to code the generic time-interpolation subroutine as a way to prepare the code for a further extension to the other schemes.

Following @jesusff suggestions about the seasonality, I found there is also a vertical profile of the CO2 concentrations, see for example:
https://acp.copernicus.org/articles/11/2455/2011/acp-11-2455-2011.pdf

but this is even further beyond...

[dudhia]

We find that RRTMG probably accounts for the majority of users, or they can be persuaded to use this. These days we emphasize suites and RRTMG is in all ours, I believe.

…

On Mon, Dec 13, 2021 at 11:12 AM LluisFB ***@***.***> wrote: And I guess there is no neither time to code the generic time-interpolation subroutine as a way to prepare the code for a further extension to the other schemes. Following @jesusff <https://github.com/jesusff> suggestions about the seasonality, I found there is also a vertical profile of the CO2 concentrations, see for example: https://acp.copernicus.org/articles/11/2455/2011/acp-11-2455-2011.pdf but this is even further beyond... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1597 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77CHF3Z4M42LHGBRZF3UQYZQHANCNFSM5JZXRUJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[weiwangncar]

@jesusff @LluisFB Please see the latest PR#1625 for updating this option from compile one to a runtime one. In order for these files to be used by historical cases, we need the data to reflect that. But I noticed that the data in files *.RCP4.5/6/8.5 begin to diverge from year 2006. Do we have data to fill years from 2006 up to now? Is the data from SSP files more up to date?

[jesusff]

Yes, SSPs are more up to date. The period based on historical data reaches 2014 in SSP. An intermediate pathway (e.g. SSP245) could be used as default for past runs since there is no much difference among scenarios in the 2015-2021 period.

[weiwangncar]

@jesusff Thank you very much. I checked the SPP files, the values for all 5 gases are the same up to year 2014. For 2015, only ch4 is slightly different, but all 5 gases are the same again for 2016. They become different from 2017 onward. Are you sure it is not typo in the 2015/ch4 data?

Just wanted to confirm again that if a user wants to simulate the weather for today (Jan 2022), the data from *.SPP245 is ok to use. Also how often will the data be updated in the future?

[jesusff]

Hi Wei, yes, historical values are up to 2014. I just checked the original source of my files and it is true that there is only a slight change in the 6th significant digit in 2015 for CH4, and then diverge more clearly from 2017 on. There is an interactive tool to explore the concentrations. E.g. for methane: https://greenhousegases.science.unimelb.edu.au/#!/ghg?ghg=30&mode=yearly-gmnhsh.

Note also that this change of a few ppb along a decade or or so by changing the future scenario is much smaller than e.g. the 50 ppb difference between the global mean concentration and hemispheric values (see the comparison in the second plot in the above interactive tool). For the sake of simplicity for the users and backward compatibility with the RCP files, I used the global mean. Yearly hemispheric or even monthly latitudinal data could be considered by more advanced users. Interpolation for monthly data would not work out of the box, though, since only years are supposed to be read from the first column of these files at the moment.

These data are collected as input for CMIP experiments with a frequency of about 7 years. We should expect in short an update to be used by CMIP7 with historical data up to 2021 or so. Note also that despite being "historical", the values might differ slightly for common years, as they do for instance between RCPs ans SSPs before 2005.

[jesusff]

For CO2 there are more recent historical estimates from NOAA (ftp://ftp.cmdl.noaa.gov/ccg/co2/trends/co2_annmean_gl.txt , https://www.co2.earth/annual-co2). They are within 2 ppm of any of the SSP scenarios for the period 2015-2020.