Make CO2 a function of year instead of a single constant

[weiwangncar]

This PR makes CO2 a function of the year following what's done in WRF since v4.2, instead of using a single constant of 379, which is valid for 2005. The value for the year is approximately the same as what's observed. For example, for 2020, the observed and computed value is about 414.

[mgduda]

@weiwangncar I appreciate that we may be trying to mirror changes from the WRF versions of module_ra_rrtmg_lw.F and module_ra_rrtmg_sw.F, but just in case any possibilities come to mind, I think it would be better if we didn't need to define the CO2 function identically in two separate places. Is there any possibility of a shared function, co2_concentration(year) or similar that would define:

co2 = (280. + 90.*exp(0.02*(year-2000)))*1.e-6

[weiwangncar]

@mgduda This can certainly be done. Does it matter which module the function will reside in?

[mgduda]

@mgduda This can certainly be done. Does it matter which module the function will reside in?

I suppose it would be ideal if neither SW nor LW "owned" the function, since it would be used by both and there doesn't seem to be a precedent for one of the modules (SW or LW) depending on the other. Would it make sense to have a new "radiation utils" module? That would eliminate significant build dependencies, too. If not, then maybe the function could go in the LW module (assuming CO2 is more relevant there)?

In any case, we should probably get @ldfowler58's input.

[ldfowler58]

Is there a reference for this equation. I find it a little curious that CO2 changes on January 1st every year? As Michael and I talked about last week, is it just a step function? Thanks.

[weiwangncar]

@ldfowler58 Jimy came up with this equation. Yes, it would be changed every year. We could do a linear interpolation like what CAM and ghg_input = 1 in WRF does so that CO2 would vary smoothly in time.
@dudhia Comment?

[dudhia]

The annual increments are small (0.5%), and the steps would hardly be noticeable in my view. We have not needed interpolation in WRF.

[ldfowler58]

PR 1071 does exactly what you are planning to do, but in a more complete manner. I think that we should go that route after I review the PR.

[weiwangncar]

@mgduda @ldfowler58 Based on some discussion I had with Michael, the co2 equation is now added to the model via a function call. Because the function can deal with fractional years, that capability is added to the function. This will smooth out the change of co2 from one day to the next, and from one year to the next.

[ldfowler58]

I still think that we should consider PR 1071 since it also includes N2O and CH4 and is user driven.

[weiwangncar]

@ldfowler58 While solution proposed in this PR isn't perfect, it offers a way to update CO2 for long simulations. PR1071 isn't general either. It lets user set values for the four gases in the namelist, but it won't change during the simulations. Again it is probably not ideal for long simulations.

[dudhia]

At some point the GHG table option which is now default in WRF could be added.

…

On Tue, Jun 18, 2024 at 9:37 AM weiwangncar ***@***.***> wrote: @ldfowler58 <https://github.com/ldfowler58> While solution proposed in this PR isn't perfect, it offers a way to update CO2 for long simulations. PR1071 isn't general either. It lets user set values for the four gases in the namelist, but it won't change during the simulations. Again it is probably not ideal for long simulations. — Reply to this email directly, view it on GitHub <#1173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77APOP4QQ2ZBYFNXYODZIBH2BAVCNFSM6AAAAABIOCZZAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZWGQYDIMRTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ldfowler58]

In all fairness to users, I also think that we should review "related" PRs in the order that they have been submitted. I really suggest to review the GHG PR first and then to review your PR.