Hi @spencerwong , I assume I should rebase the development
branch to include the changes from wombatlite-sinking
(Branches · ACCESS-NRI/GFDL-generic-tracers · GitHub)?
I think so!
The latest GFDL-generic-tracers
development
branch tag is dev_2025.01.0
. It contains the following commits: Commits · ACCESS-NRI/GFDL-generic-tracers · GitHub
Stand up minutes here, please correct as appropriate.
Update: @micael @manodeep from ACCESS-NRI (the rapidly expanding software transformation team) are looking into improving running performance of ESM 1.6 and we need your input!
They are intending to see if the (this order): compiler choice (ifort to ifx), compiler flags and load balancing could improve performance of ESM 1.6. This is a non-trivial task (perhaps a few months of effort) and we are looking to understanding when this work is best completed. Key point: the optimised settings will likely break bitwise reproducibility. So, this work is best completed before we start production runs.
Hence, @pearseb @RachelLaw @inh599 @MartinDix (others?) can you please give some estimates of when you expect to be doing your long runs? The interest here is just a rough estimate, something like the following text would be really helpful:
@username. Feb. x years. Mar: y years. Apr. z years. May. n years etc. Bitwise repro’ is required after xx date.
Feel free to pop questions in the chat here, we’ll also discuss at the next standup.
As some ESM users cannot see the “atmos” version of this chat this query is duplicated here.
The aim has always been to start production runs from about July. That probably means having a mostly settled configuration by the end of March (optimistic?) and then only making minor changes as we spin-up over 2-3 months in the 2nd quarter of this year.
Hi @RachelLaw , thanks for clarifying the timeline. I think we can do most of the work over the next couple of months, which would work nicely with your plans. @manodeep and I will start attending the weekly stand-up and keep you informed of our progress.
Hi everyone, I just have a couple updates on configurations and executables.
A development AMIP configuration is available here. A couple of things to note:
- The configuration is based on the COE AMIP configuration for ESM1.5, and uses the 1978 restart from AM-09. Land use change also uses the CMIP6
cableCMIP6_LC_1850-2015.nc
file. - It’s currently using the executable from PR 28-23 but this can be easily swapped.
- It uses the same
cable.nml
file as thedev-preindustrial+concentrations
configuration. Let me know if this should be changed.
@manodeep and @micael this config might be useful in case you need to look at the performance of just the atmosphere component.
There are also a new set of executables which have @pearseb’s bug fixes for WOMBAR-lite in PR 31-3. These use the CICE branch with iceberg fluxes and the head of the esm1.6 development branch for the UM at the time of building.
Let me know if you have any questions about using these or any suggestions!
Just adding a note on new the new payu version and netCDF conversion:
Payu version 1.1.6 has just been released on Gadi, and this version will be picked up by default with:
module use /g/data/vk83/modules
module load payu
This shouldn’t impact how you checkout and run ESM1.6 configurations, however it will affect the names of the UM history files. The new payu conda environment uses the latest version of um2nc
, which adds more date information into the file names.
E.g. aiihca.paa1jan
and aiihca.pea1jan
become aiihca.pa-010101_mon.nc
and aiihca.pe-010101_dai.nc
. The netCDF directory has also been renamed from NetCDF
to netCDF
.
This might impact any post-processing scripts/notebooks that are already set up. If it’s easier to stick to the older naming scheme, you can tell the conversion to use the older versions of payu and um2nc by editing the UM_conversion_job.sh
script.
If you replace:
module use /g/data/vk83/modules
module load payu
with
module use /g/data/vk83/modules
module load payu/1.1.5
The older naming scheme will be used. Note that this will skip other updates to um2nc
such as properly naming CASA variables previously set to unknown_variable
.
Let me know if you have any questions or run into any problems!
Cheers,
Spencer
Meeting minutes are now up, please correct/amend.
@inh599 - is there are a github issue for the runoff balance stuff you are looking at?
The 2d field in mom is just called runoff - if you need a hand changing the output frequency let us know. There is also a global scalar (total_ocean_river
) but it’s only saved monthly by default
There are some notes here about the overall OM2 water balance - ACCESS-OM2 water balance - Google Docs (Note it talks about a correction flux which shouldn’t be needed in coupled models, so ignore that).
@anton Found this message - thanks.
I suspect that total_ocean_river
will be sufficient for what we need at this point in time - this variable will give us early vision of whether the salinity restoring factor needs recalibrating @dhb599 @MartinDix.
We may look at the monthly 2d fields at a later date - since the geographical distribution feeds into the iceberg parameterisation - but my guess is that this is less likely to be affected.
Nice - the frozen runoff should be in the licefw
field, although it does depend on the specific of the implmenetation a bit
Meeting minutes are now up, please correct and amend as required.
Meeting minutes are now up, please correct and amend as required.
Hi everyone, just a quick note on the development configurations for ESM1.6.
The pre-industrial and AMIP configurations on the github repository have been updated to include the new Cable pft_params.nml
and soil.nml
namelists.
To run the configurations, it will be necessary to use the prerelease version of payu as it contains some required driver changes. The prerelease version of payu can be loaded with:
module use /g/data/vk83/prerelease
module load payu
When using an older release version of payu (e.g. 1.1.6
) rather than the prerelease version, it will fail to read the config.yaml
file, producing the following error:
Traceback (most recent call last):
File "/g/data/vk83/apps/base_conda/envs/payu-1.1.6/bin/payu-run", line 10, in <module>
sys.exit(runscript())
File "/g/data/vk83/apps/base_conda/envs/payu-1.1.6/lib/python3.10/site-packages/payu/subcommands/run_cmd.py", line 123, in runscript
expt = Experiment(lab, reproduce=run_args.reproduce, force=run_args.force)
File "/g/data/vk83/apps/base_conda/envs/payu-1.1.6/lib/python3.10/site-packages/payu/experiment.py", line 96, in __init__
self.init_models()
File "/g/data/vk83/apps/base_conda/envs/payu-1.1.6/lib/python3.10/site-packages/payu/experiment.py", line 165, in init_models
ModelType = model_index[m_config['model']]
KeyError: 'access-esm1.6'
just to clarify @spencerwong - the LUH3 based restart is not part of this yet?