Repository navigation
Extend scenarios to 2150 - #157
Conversation
Documentation build overview
|
* Add u-dq819/trunk workflow as-is * Move ACCESS-ESM1.6 Python scripts into lib/python * Remove git_clone_scripts and install_scripts tasks * Set everything to true by default * Delete reference to GIT_SCRIPTS_REPO
d6ed894 to
c14e7ab
Compare
|
I ran the completed workflow twice: Run 7:
Run 8:
Both runs apparently succeeded, with identical output. Please check that the correct output was produced, including extensions to 2150 (or 2151 when needed). |
There was a problem hiding this comment.
Thanks @paul-leopardi, I've had a look through the code changes and had a few questions come up.
The main thing I saw is that extended outputs aren't being produced for the SO2 and CO2. Other than that I just had questions about some of the error handling and extension of the data used for the ozone and nitrogen, which are less of a priority to think about. (realised I'd misunderstood the code)
|
From Zulip: Martin Dix Paul Leopardi See e873115 for the fix. I then ran the workflow again. Run 9: Log: |
|
CO2 emissions look ok 
|
|
Aerosol emissions look ok 
|
|
Nitrogen is constant after 2100 as specified by https://wcrp-cmip.github.io/cmip7-guidance/docs/CMIP7/Experiment_set_up_and_Forcings/scen7-h-ext/ 
Solar is ok 
Volcanic correctly repeats the 2100 annual cycle for years following 2100 
|
|
I performed all the code changes listed above and then ran the workflow again. Run 13: Log: The run succeeded with output identical to |
|
I performed the code change at commit b92fa21 and then ran the workflow again. Run 14: Log: The run for all forcings other than ozone has succeeded with output identical to As at midnight, the ozone tasks are sitting in "held" status pending allocation. |
|
Comparing ozone data is difficult because the input is on pressure levels and the model data is on the native height levels. Comparison here uses a column total which is only approximate (used model level pressure data from year 2000 of the historical simulation). Comparing at 80S October to highlight the ozone hole. All the scenarios are quite similar with only weak recovery. 
After 2100 the ozone should repeat. This is correct. |
|
I performed the workflow change at commit 5b54f0f to switch on all the forcings and extensions and then ran the workflow again. Run 17: Log: The run for all forcings succeeded with output identical to Also, see https://github.com/ACCESS-NRI/access-esm1.6-configs/branches/active for the |
|
The extended GHGs to 2150, taken from the gen-scen7-*-87a06927 branches all look good: 
|
blimlim
left a comment
blimlim
left a comment
There was a problem hiding this comment.
Thanks @paul-leopardi for adding those changes and producing the GHG values. The code changes look good to me
3 participants
Closes #150
This PR extends ACCESS-ESM1.6 ScenarioMIP input forcing ancillaries from 2100 to 2150 across scenarios.
I used Google Antigravity with Claude and Google Gemini agents to generate and debug the workflow and Python code, and to synthesize a draft of the remainder of this comment.
Suite & Workflow Controls (
flow.cylc,rose-suite.conf):EXTEND_SMtoggle with granular per-forcing switches (EXTEND_SM_AEROSOL,EXTEND_SM_CO2,EXTEND_SM_GHG,EXTEND_SM_NITROGEN,EXTEND_SM_OZONE,EXTEND_SM_SOLAR,EXTEND_SM_VOLCANIC).2022_2150vs2022_2100) based on extension status.Python Generator Enhancements (
esm1p6_ancil):tile_constant_years()and tiling to 2151.iris.FUTURE.datum_support = Trueacross ozone, AMIP, and common modules to suppress NetCDF datumFutureWarnings.