I think we should get the run going as discussed in the stand-up (or the two runs, with/without the new N dep). Then the next step should be any updates to the stashc and the diag table - particularly now Spencer has noted that there may be challenges with the extra diagnostics that Matt has noted.
Thanks for the background.
IMHO, I think it is too late to be debugging source code for a particular diagnostic, unless we find out this is a critical variable for a priority opportunity.
This does raise a new question though, are there other variables have were similarly switched off?
@matthew.chamberlain this is a good question. I believe we will be in the best position to answer once we do a full review of the outputs as Rachel noted in her reply. It might take us a couple of weeks to get there.
Meeting minutes from today’s meeting. Please correct/amend. Particularly to @lachlanswhyborn @paulleopardi @manodeep where I missed some details.
Note: @inh599 or @RachelLaw @tiloz
@MartinDix: nitrogen deposition change is in. What would we expect to change? Would be good to follow up with @inh599 or @RachelLaw @tiloz [please provide guidance here!]
I’ve made a few plots comparing the old and new nitrogen deposition runs.
Ndep.pdf (164.6 KB)
Slide 1: the pattern of GPP differences doesn’t look that similar to the pattern of nitrogen deposition change
Slide 2: NEE is still stable and averaging to approximately zero
Slide 3: the mineral nitrogen pool might be showing some influence from the change in N deposition, e.g. the SE of the USA for pft 1 (EGNL). The timeseries for that region shows a mean difference but not a trend.
Slide 4: this is also the mineral nitrogen pool for the C3 crop (left) and C4 crop (right) averaged but without considering land fraction. Here there is an initial adjustment over the first 10-20 years but I assume this is due to the changes we made to some of the parameters for the crop pfts, rather than any change in N deposition.
So seems like no changes that would concern us and the old nitrogen case can probably be stopped.
Minutes from today’s meeting, please correct/amend.
The current sea level trend is 6e-6 m / year. Is it worth returning lprec to reduce this?
Does the absolute value of sea level (eta_global) matter or do people only care about relative changes? Should (can?) we reset it to zero before starting the official piControl?
Still a mystery what’s happening with the salt mass, Sea level and salt · Issue #232 · ACCESS-NRI/access-esm1.6-configs · GitHub
For some applications, total sea level is important.
Agreed that the salt trend is a mystery …
Not sure it is relevant, but we had a “mysterious” global salinity decrease suddenly appearing in the glacial ESM1.5 run, and we did not find the issue.
Some updated timeseries plots from the extended spin up - the latest section (November with new Nitrogen deposition) is in green. means/trends over the last 100/200 years of the November section also included.
Ocean diagnostics: full ocean temperature and salinity, surface temperature and salinity.
Atmospheric diagnostics: surface air temperature, precipitation, TOA energy balance and TOA albedo
Overall - while the simulation is still cooling, this is at a very minor rate. Global salinity is decreasing (due to both a small net creation of water from ice points and the loss of salt mass discussed above).
Selected ocean BGC fields inspected (not shown) also appear relatively stable in the latest section.
Land carbon diagnostics: GPP and NBP (which needs to be ~0 in an equilibrated spin up)
Heterotrophic respiration in the latest section of the spin up has a trend at around 2E-4 Pg/yr (against a mean of 40 Pg/yr) - this is much closer to zero than any previous phase of the spin up, indicating that the slow timescale land carbon pools are now in better balance with photosynthetic production [i.e. good news]
OctB Atmosphere Evaluation_1.pptx (11.9 MB)
OctB Atmosphere Evaluation_2.pptx (13.4 MB)
For those who don’t have access to the NESP sharepoint, here are some evaluation plots for the October B run, including @DeepashreeDutta 's analysis.
Tagging @cbull who was interested in looking at these!
A quick, first look at the latest (December) concentration-driven PI-control. This December section of spinup includes all (?) CMIP7 forcings and modifications to the requested outputs.
As of 5/1/2026 we have 233 years of the December spinup (red) now complete and … overall … nothing jumps out as a concern (at least in the broad-scale ocean metrics). Broad-scale ocean biogeochemistry is also stable compared to the earlier sections. Possibly a very slight warming (ozone?) compared to the earlier section of spinup.
For completeness - the CMIP7 solar constant and CABLE3 went in at year 0, ocean albedo at year 1000 (Australian PFTs at around 1300), nitrogen deposition at ~2200, and ozone at ~2700
We also have an esm-picontrol run going. It has completed ~250 years. Also looking good so far. For comparison temp and salinity below. Averaging might be different, so small differences in comparison to Ian’s plots. Similar results as expected.
ocean temperature
SST
ocean salinity
SSS
And here some results for the carbon cycle. Land and ocean net cfluxes are close to zero and look stable. 20year averages shown below.
ocean net cflux
land net cflux
CO2 concentrations
Some small adjustments in the global mean CO2 concentrations, but looking stable.
We want a first release of ACCESS-ESM1.6 configurations soon. It would be good to clarify which configurations we need or want in that release. Things to consider is the timing of the release with respect to proposed papers as well as what the proposed papers would need to be released. Although, at this stage, it is worth being ambitious with the goal and drop some configurations later if we need to. We will have subsequent releases where we can include other configurations.
I’m having a first go at a list with priority but happy for inputs from others:
Priority 0:
- release-preindustrial+concentrations
- release-preindustrial+emissions
- release-1pctCO2
- release-1pctCO2-rad
- release-1pctCO2-bgc
- release-flat10
- release-4xCO2+concentrations
As far as I know, we want to start production runs for these configurations soon, which means they are ready for release soon.
Priority 1:
- release-historical+concentrations
- release-historical+emissions
I know we want the historical simulations soon as well but there are issues with some forcings from the data providers. This means the timing on these configurations is uncertain.
Priority 2:
- release-amip
I’m not sure how much demand there is for an AMIP configuration outside testing, so I’ve put it at the lowest priority for now.
Any feedback on this list is welcome!
update to 12/1/2026 for the global ocean metrics - note that in these I’ve added the ESM-emissions control in as the black line. mean/trend numbers are from the concentration driven run
global atmospheric metrics (including NBP) are also stable in the concentration driven run.
Ocean air-sea CO2 flux now stable near 0.
Black = August run
Grey = November run
Blue = December run
The numbers at the bottom are the averages of air-sea co2 flux over the last 200 years of each of the different runs.
I’m running a historical test with CN only but it has crashed after ~50 years. I tried to just restart but is has crashed again and the error messages are ones I don’t recognise. Segmentation fault … There are also non-conservation warnings but I don’t know if they are usual or not. Please can someone (@MartinDix , @spencerwong ? )check whether this is a ‘known’ crash?
The run directory is /g/data/p66/rml599/historical/test-hist-CN
Given a simple restart didn’t work, does that mean I need to perturb the restart?
Hi @RachelLaw, the atmosphere log file in /scratch/p66/rml599/access-esm/work/test-hist-CN-test-hist-CN-3e80d641/atmosphere/atm.fort6.pe0 says that the solver failed to converge in the last step:
==============================================
initial Absolute Norm : 1.698745391462614E+057
GCR( 2 ) failed to converge in 50
iterations.
Final Absolute Norm : 1.049173348711135E+046
I think it’s worth perturbing the restart to see if it gets around it.




























