@RachelLaw Could you (or @alexnorton) run the carbon conservation script over (any) of the existing runs, applying it to two months’ output. That should show up if there’s a problem in the STASHC (but does assume that the model is actually conserving).
Actually you don’t even need to do that - just comparing the output and restarts for a December month would show up if the CNP-pools are the same surely?
@inh599 - that was a good suggestion. I have checked the leaf carbon pool from December (confirming it is timestamped with Jan 1 00:00) and it is the same as the leaf carbon pool in the restart file from the same time. This was from an emissions-driven historical case.
This guidance documents on grids may be of use @RachelLaw @rbeucher
I think we are mostly following it already
We talked in the NESP project meeting today about whether to approximate monthly mean CNP pools by interpolating between end of month values and setting up a run to test this. I remembered that I had tried an amip test with monthly output of pools (naively just changing ITIM=20 to ITIM=3 in the STASHC file). I no longer have the original output but it did run for a few years and I have got output for the leaf carbon pool (though not with a correct timestamp). This figure shows example output from one month and one pft (evergreen broadleaf). Top left is the February mean (using ITIM=20), bottom left is the average of the end of Jan and end of Feb output. Top right is the absolute difference (gC/m2) and bottom right is the difference as a fraction, so less than 3%.
Some results from testing nitrogen deposition 2.0 (current runs have been with v1.2). Martin ran a 100 year control run. These plots are GPP (carbon uptake by photosynthesis). The left plot is the difference in 50 year mean between running with Ndep2.0 and Ndep1.2 (the last 50 years of the run). To give an idea of whether the differences are likely related to the change in Ndep, the right plot is the difference between two 50 year periods from the run with Ndep1.2. Given the differences are comparable in magnitude and spatial extent, it looks like any difference due to the change in Ndep is in the noise.
It looks like the ocean carbon fluxes that we put into the atmosphere in an emissions-driven run do not account for land fraction. I’ve described the issue here: Ocean co2 flux applied in atmosphere without accounting for land fraction? · Issue #208 · ACCESS-NRI/UM7.
In practice, this doesn’t change the total flux into the atmosphere by very much, but when fluxes are close to zero in a control run, it can change the sign. If this is a bug, then it would be nice to sort it out now as it would impact all emissions-driven simulations (though likely not seriously).
Good news - we’ve finally got some progress on our EMD submission and have some grid numbers allocated. So far, it is the 3 atmosphere horizontal sub-grids and the atmosphere and land vertical grid. I’ve put the grid numbers into the spreadsheet (first column on HGrid_Subgrids and Vertical Grid sheets) here: EMD_Model_Template_v1.0.xlsx. The numbers weren’t allocated in the order that I put in the issues so I’ve been careful matching them.
Next step is to use the gNNN and vNNN numbers to put issues in the atmosphere and land grids. I also need to start the process applying for gNNN numbers for the ocean sub-grid.
Do you mean GitHub issues to add this to the grid file metadata?
We should also add this grid information to the global metadata that is added to the output files. See Integration with data specifications · Issue #313 · ACCESS-NRI/access-esm1.6-configs · GitHub
@Aidan - what I meant by ‘next step’ is following the sequence here: Submission Guide. So far we’ve managed ‘stage 1’ for the atmosphere grids and ‘stage 2’ for the vertical part of the atmosphere and land grids. I tried to do ‘stage 2’ for the horizontal atmosphere grid, but the issue submission has pull down menus for the gNNN numbers that you want to use - but our numbers (g114,g115,g116) aren’t showing up in the pull down menu (yet?). While I wait to see if they appear in the next few days, I need to start ‘stage 1’ for the ocean.
Once we have everything registered, then, yes I assume it will need to go into the metadata for the output, at least post-cmorisation.
Latest results from an emissions-driven historical test run that includes a new input for forest ‘thinning’. The run still has just ~15 years to complete. Benchmarked against GCB 2024 (whole historical period) and the ‘corrected’ budget from Friedlingstein et al. (2025) (1959 onwards), as well as Rachel’s earlier test esm-hist runs (‘no thinning’ = hist-mar26-02-hist-mar26-02-1c87d12c; ‘no thinning + 40PgC’ = esmhist-mar26-40-esmhist-mar26-35-5ce10e54). It shows improvement in capturing the historical land carbon budget, in particular the land-use change component post-1959, a result of the additional harvested wood products from the forest thinning. The last 15 years will be critical though.
Results here: /scratch/p66/ajn563/access-esm/archive/esmhist-thinbioh-20-dev-historical+emissions-63d1e9c1/
Preliminary analysis of the latest emissions-driven pi-control is looking positive. This is the case with fixed ocean carbon flux and ndep2.0. Previous run (red) had atmospheric CO2 drifting upwards, new one (black) appears to have a slight drift down initially but then closer to the earlier run. It will be interesting to see how then next 100 years tracks.
150 year mean land carbon flux is -0.0047 PgC/y, ocean carbon flux is -0.0036 PgC/y.
As mentioned at this morning’s stand-up, we have been mapping out the ACCESS-ESM1.6 model description paper. As well as documenting the science updates for the model, it will be good to document the infrastructure updates. In our current draft we have proposed subsection / subsubsections:
Model infrastructure and computational performance
We will also need to describe how we have processed the forcings for use with ACCESS (@paulleopardi, @MartinDix ?). This is currently sitting as a subsection under ‘CMIP7 experiments completed and planned’. In Chloe’s paper for CMIP6 ACCESS submissions, each forcing was described in a separate block of text. I wondered if this time, we could provide summary information in a table, following a grouping of forcings as in the Dunne et al., 2020 paper, Table 2.
If you are able to help with any of this (whether or not I’ve suggested your name in this message), please contact @tiloz for an invitation to edit the paper in Overleaf.
I am making these name changes to configuration branch now to match CMIP7 names:
| Old Name | New Name |
|---|---|
| dev-historical+concentrations | dev-historical |
| dev-historical+emissions | dev-esm-historical |
| dev-preindustrial+concentrations | dev-piControl |
| dev-preindustrial+emissions | dev-esm-piControl |
| dev-flat10 | dev-esm-flat10 |
| dev-0p5xCO2+concentrations | dev-abrupt-0p5xCO2 |
| dev-2xCO2+concentrations | dev-abrupt-2xCO2 |
| dev-4xCO2+concentrations | dev-abrupt-4xCO2 |
dev-1pctCO2 names are unchanged
After this morning, you will need to use the new names when cloning configurations.
I think with the way we normally use this repository you won’t need to rename existing branches in a local copy of the repository.
However if you do, here are the commands (in this example, dev-historical+concentrations is renamed to dev-historical :
git branch -m dev-historical+concentrations dev-historical
git fetch origin
git branch -u origin/dev-historical dev-historical
git remote set-head origin -a
@anton - At Tuesday’s stand-up there was also talk of making release- branches. Will these be additional to the dev- ones or replace them?
These will be additional. The release- branches are a bit more tightly controlled and ensure a couple of things:
/g/data/vk83/prerelease (so it’s clearer to ACCESS-NRI we need to keep them long term)release- branches will trigger versions to be created. Versioning will increment the major version for (prognostic) answer changes and the minor version for non-answer changing changes. So the initial release would be version 1.0, then if a change is made to improve something but the model gives the same answer, then its version 1.1. If the answers change, it would be version 2.0.(edit, the concept being the dev- branches are merged into release- at appropriate times)
Hi Rachel, I will describe the CMIP7 forcings processing for ACCESS-ESM1.6 and will also refer to a more detailed online document, whose location is yet to be determined, but could be an ACCESS-NRI GitHub repository.
Final stage of the model registration submitted: [EMD] Stage 4: Model (source_id): [do not edit] · Issue #544 · WCRP-CMIP/Essential-Model-Documentation. Just need to wait for it to be reviewed and then we will have our model source_id for preparing datasets for publication.
For anyone wanting to look at ILAMB results for ESM1.6 esm-historical, you can:
I haven’t discussed the process to add other ILAMB results with Yuvraj and Gavin, but asking here is probably the simplest for now.
Thanks for the new ILAMB results. I think a few things still need to be sorted out with the ACCESS-ESM1.6 results first. See my post here: Early ACCESS-ESM1.6 ILAMB Evaluation Pipeline Using ACCESS-MOPPy - #2 by alexnorton
