-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2018 and 2018-PD use-cases for NEON single point #1363
Comments
As noted in the CDEPS issue if ESCOMP/CDEPS#76 happens first this could be handled with specific settings in the use-case or in the NEON user-mod directories. Also the 2018_control use-case should just set CO2 to the constant value for 2018 as is done for 2000. |
Because NEON both uses a combination of a compset and user-mod directory (which itself points to a use-case), I don't think we should create a NEON specific compset, but we should have a NEON specific build-namelist use-case to use in place of the SSP3-7.0 use-case. |
This came up again in a discussion with @wwieder. I had forgotten about this issue, but suggested that we implement what's suggested here. |
This also goes with the CDEPS issue: ESCOMP/CDEPS#75 |
Another part of this is that we distinguish these with compset names to pick the right use-cases. So I suggest the compset aliases be: I20181PtClm51Bgc There actually is an existing IHist1PtClm51Bgc, so perhaps that's how we should distinguish these. |
I think from our conversation we're just using the I2000 and IHIST cases
that are modified with usermods / run_neon to the right time ranges.
FWIW, I don't understand the 'Pd' part of these names, I think it's for
present day?
…On Tue, Oct 25, 2022 at 2:56 PM Erik Kluzek ***@***.***> wrote:
Another part of this is that we distinguish these with compset names to
pick the right use-cases. So I suggest the compset aliases be:
I20181PtClm51Bgc
I2018Pd1PtClm51Bgc
There actually is an existing IHist1PtClm51Bgc, so perhaps that's how we
should distinguish these.
—
Reply to this email directly, view it on GitHub
<#1363 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB5IWJBWNTV4ZYYYPAZNA3DWFBCRLANCNFSM435BCMDQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes, I put that out just before our conversation. So I can do without adding compsets and use the existing ones. Technically, with that I don't need to setup use-cases, but I think it's good to define these use-cases as it's more clear than the SSP use-cases. The start year will be based on the 2018 that's needed for NEON, but the general use case will be useful for other single point sites. All single point sites start somewhere more recent than 1850 and they only need to go until current present-day rather than 2100. Setting up a use-case for this kind of usage allows us to document why we are using SSP data. And yes Pd is for Present-Day, the reason for using that is that present day keeps moving forward in time, if you use a fixed year 2022, you have to change the name each year. But, if you use PD you can still use the same name, as you advance it's meaning. It's OK to advance the meaning of the name, but it's disruptive to have the name itself change in time. |
We need to add some 2018 and transient single point compsets to be used with NEON. We need 2018 since that's the start of the NEON data and when spinups will be done. We also need something to do transient cases (with transient ndep, presaero, pop-dens, urbantv, and CO2) . Since for most of this we don't have data past 2015, we will use a SSP-RCP scenario and just have the start year be 2018. Since SMYLE is using SSP3-7.0 we'll use that here as well.
So that we don't have to increment the end point each year, we'll use to signal "Pd" for Present-Day, and the last year will be incremented when new NEON data is available for the next year.
As new data comes into the system the future scenario data will be replaced with historical data. But, that likely will happen on different time-lines for the different data streams.
Doing this will also require adding similar menu options for PRESAERO and CO2 in CDEPS. For CTSM this will mean adding a use case for 2018_control and 2018-Pd_transient. This will set the start year for the streams to be 2018. The end year could be the Pd year, and taxalgo of limit to make sure it doesn't wind back. You could also leave it at 2100, in case someone wanted to move forward, but since the Pd year will be managed it might make the most sense to use it.
@wwieder @jedwards4b @danicalombardozzi
The text was updated successfully, but these errors were encountered: