Make CO2 a function of year instead of a single constant#1173
Make CO2 a function of year instead of a single constant#1173weiwangncar wants to merge 2 commits into
Conversation
|
@weiwangncar I appreciate that we may be trying to mirror changes from the WRF versions of |
|
@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. |
|
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. |
|
@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. |
|
The annual increments are small (0.5%), and the steps would hardly be noticeable in my view. We have not needed interpolation in WRF. |
|
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. |
|
@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. |
|
I still think that we should consider PR 1071 since it also includes N2O and CH4 and is user driven. |
|
@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. |
|
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:
***@***.***>
|
|
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. |
|
I am reviewing this PR along with PR #1071. Using a year-dependent function for CO2 instead of a single constant seems reasonable to me, especially for long-term simulations. Aligning this change with WRF also seems beneficial. Thank you, @weiwangncar, for creating a function in the Related to this PR, I have a couple of questions for @dudhia and @weiwangncar:
Does this refer to
Thank you! |
|
The table year-dependent CO2 is based on observed values for past years and official climate scenarios for future values. The function form is a close fit for past CO2 growth and extrapolates it for the future. Fixed values would not be advised unless the user is knowledgable of what value is best for the year simulated. In regional climate simulations of multiple decades, a scenario-based changing value would be best, but in WRF we have also used a fixed higher future value. |
|
@jihyeonjang Here are my replies to your questions: 1. Yes, the GHG table option will need additional code to read and interpolate the GHG data and ghg_input controls it. 2. I'd agree with you that a time-varying CO2 is ok for the time being, though the limitation is that the other GHG won't get updated. 3. The CO2 function in this PR will only change by the year, while the GHG in the table option is interpolated in time. Though one may argue that the year to year change of the value isn't too huge. 4. What is your argument for allowing users to edit the GHG values? If there is a consensus we can certainly do it. It will at least allow users to change other GHG values. Though it is not for everyone, it can be useful for someone who uses it with a good intention. |
|
Thank you, @dudhia and @weiwangncar! It seems the GHG table option would be better for users. I will take a look at the GHG table option in WRF and see how much work it will take to add it to MPAS. Thanks! |
This commit was modified from PR MPAS-Dev#1173 by weiwangncar for making a function of year (time) for co2 concentration, following what's done in WRFv4.2. This commit moves shared longwave and shortwave radiation subroutines or functions into a new utility module (mpas_atmphys_radiation_utils). Subroutines and functions needed to compute constants or arrays for longwave and shortwave schemes are moved in this module. In particular, the co2 estimate function has been moved there.
jihyeonjang
left a comment
jihyeonjang
left a comment
There was a problem hiding this comment.
A follow-up PR (#1457) has been opened based on this work. This PR can be closed.
5 participants
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.