Skip to content
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

Make sure SSP dataset files change at 2015-01-01 rather than 2016 #1213

Open
ekluzek opened this issue Nov 12, 2020 · 1 comment
Open

Make sure SSP dataset files change at 2015-01-01 rather than 2016 #1213

ekluzek opened this issue Nov 12, 2020 · 1 comment
Assignees
Labels
enhancement new capability or improved behavior of existing capability

Comments

@ekluzek
Copy link
Collaborator

ekluzek commented Nov 12, 2020

When setting up some datasets for SMYLE I concatenated historical datasets with SSP datasets. I used 2016 as the year to transition to keep the historical period as long as possible. Keith Lindsay would like me to use 2015 rather than 2016. So some of these datasets will need to be changed. Ones to look at are: ndep, presaero, CO2, pop-dens.

@ekluzek ekluzek added enhancement new capability or improved behavior of existing capability next this should get some attention in the next week or two. Normally each Thursday SE meeting. labels Nov 12, 2020
@ekluzek ekluzek self-assigned this Nov 12, 2020
@ekluzek
Copy link
Collaborator Author

ekluzek commented Nov 12, 2020

Here's an email from Keith on this:

"When CESM2 generated SSP forcing is concatenated to CESM2 generated historical foring, I think it is inevitable that there will be a jump at the transition date. I think this jump is unavoidable because the historical forcing used the mean of 3 ensemble means, while the SSP forcing used a single ensemble member.

I took a look at the file
.
.
.

The more I think about it, the more I'm in favor of 2015-01-01 as the date of the transition. As far as I'm aware, the primary motivation for having concatenated history files is to make it easier to do hist+ssp experiments in a single case, not having a separate experiment for the ssp portion. If that's the case, then I think it makes sense for an experiment using the concatenated forcing to resemble separate hist and ssp experiments as much as possible. When we do separate hist and ssp experiments, there is a jump at 2015-01-01. So it seems to me that putting the jump at 2015-01-01 in the concatenated forcing makes sense.

Note that for monthly data, like ndep, the last hist forcing in 2014 is at 2014-12-16 and the first ssp forcing in 2015 is at 2015-01-16. datm, or shr_stream would interpolate between them. So the jump gets spread from 2014-12-16 to 2015-01-16. So the forcing in the last half of Dec 2014 and the first half of Jan 2015 differs from the forcing in separate runs. I think you could avoid these difference by adding forcing in the concatenated forcing at 2014-12-31 from the hist forcing and at 2015-01-01 from the ssp forcing, but I'm inclined to think that this is overkill.

So I propose using mid-month historical forcing up to the end of 2014 and mid-month ssp forcing from the beginning of 2015.

aerodep_clm_SSP370_b.e21.BWSSP370cmip6.f09_g17.CMIP6-SSP3-7.0-WACCM.001_1849-2101_monthly_0.9x1.25_c201103.nc
in the directory
/glade/p/cesmdata/cseg/inputdata/atm/cam/chem/trop_mozart_aero/aero

Based on this file's history attribute, it looks like you truncated the SSP forcing to 2016--2101 and concatenated that to the historical forcing, generating the concatenated dataset. It looks like this ends up using the historical forcing to 2016-01-01, and the SSP forcing after that date. So the jump is at 2016-01-01. I would have expected the jump to occur at 2015-01-01, the branch date between the historical and SSP experiments.

When I created the merged ndep and CO2 datasets that I am using in the ocean/ice initial condition generating experiments, I put the historical-to-SSP transition date at 2015-01-01. I was thinking that I could use the aerodep file that you created in my experiments, but I'm inclined to not do that because of the difference in construction.

I'm assuming, but didn't verify, that you used a similar approach when you constructed the concatenated ndep forcing file used by CLM/CTSM.

There might be some benefit in the land and ocean ndep datasets being created similarly, as I'm expecting they will be used in the SMYLE coupled runs. If we do want them to be similarly created, then either I can recreate the ocean ndep file in the manner in which you created the land ndep file, or vice versa."

@billsacks billsacks removed the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Nov 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement new capability or improved behavior of existing capability
Projects
None yet
Development

No branches or pull requests

2 participants