Minutes from today’s standup, please correct/amend.
A reminder that next week you are in @MartinDix @spencerwong’s capable hands.
Minutes from today’s standup, please correct/amend.
A reminder that next week you are in @MartinDix @spencerwong’s capable hands.
I have added some labels to the issues in the config to make it easier to group and find related issues:
Please feel free to add others, or add labels where they’re missing.
Hope that is helpful.
Minutes from today’s standup, please correct/amend
Hi Spencer, I’m trying to reproduce the preparation of a restart file from the picontrol run, so I can also do some amip tests. With the command module use ~access/modules, I get an ERROR: Directory '/g/data/access/projects/access/modules' not found. What am I missing?
~access resolves to a subdirectory of /g/data/access
$ readlink -f ~access
/g/data/access/projects/access
It was put in place to support legacy usage
I suspect changing to
module use /g/data/access/modules
should at least give you a new and more informative error.
Thanks Aidan. Unfortunately that gives the same error. The directory /g/data/access/ does not exist for me. Is there some NCI project or permission I need first to see that directory?
Yes. You need to join the access project
Minutes from today’s standup, please correct/amend
@MartinDix and @lachlanswhyborn please fill in the bits I missed.
Just have a quick update on the payu calendar issue. To load the working version it’s necessary to specify:
module use /g/data/vk83/prerelease/modules
module load payu/dev
At the CMIP7 Leadership meeting on Friday, Tilo has reiterated our goal is to have the final spin-up started in a couple of weeks. This means putting the remaining developments into the code before that date.
Accordingly, I propose to run this Tuesday’s standup differently. The idea would be to review all the proposed developments (Coordinating development threads for next phase of control experiment) and decide how to bundle developments together in new versions and what testing would be required for each step. We will also want to decide or highlight if there is anything that may need to be dropped.
The aim is for everyone to leave the standup with a clear understanding of their tasks for next week or 2.
This means there might be less time to discuss any individual issue.
Hi everyone,
after discussing with Chris, we got organised on how to run the stand-up tomorrow.
First, we will use the list in this spreadsheet. It’s a copy of the table on the forum with our development ideas but we think it will be easier to use in a spreadsheet form.
If you know of any development that is being worked on but is not listed, please add it before the meeting if possible.
What we want to get from the meeting:
Minutes from today’s standup, please correct/amend. Most importantly, the table we revised and discussed is now here (re-ordered in terms of sequencing and priority).
Items to consider following up on:
Cooling in spin-up item currently missing a coordinator, perhaps @inh599 might ?Do reach out if further coordination on timing or the implementation of the above threads is needed to meet the upcoming deadline.
Hi everyone, I’m just adding a summary of the water balance work done with @MartinDix and @inh599. It would be helpful to discuss how we’d like to proceed, and if we would like to implement any changes.
The following shows the total water mass and rates of change for several test simulations during the investigation.
The blue line is where we began (after the CICE masking fix), with a loss of ~1e7kg/s.
A bug in the river scheme was found, where runoff on inland basin points was erroneously being set to 0. A fix from UM7.7 was backported with the orange line as the result. We get an accumulation of water at ~5.3e6kg/s.
A unit error was found in the runoff adjustment used to compensate for outflow on inland basin points. A proposed fix was to reroute the inland basin outflow directly to the river outflow during the river step, rather than passing it back and forth with the rest of the atmosphere code. The result is in green, which showed a much larger accumulation of ~4.8e7kg/s.
The UM doesn’t conserve water and appears to add ~5-6e7kg/s. The UM reports the error in its water conservation once per day. We’ve attempted to compensate for this error by subtracting it from the next days river outflow. The result is shown in the red line, and we end up almost exactly back at our starting point.
The UM and CICE use a latent heat of evaporation parameter of 2.501e6kg/s, while MOM uses 2.500e6kg/s. As the evaporation flux is converted back and forth between a watermass and an energy during the coupling, this leads to a loss of water (~6.3e6kg/s from testing). Additionally, the river scheme appears to use inconsistent areas when regridding the runoff, which leads to a loss of ~1.4e6kg/s. Trying to adjust for these gives the purple line, with an error of ~1.9e6 kg/s.
This remaining error is on a similar order to errors inherent in the coupling. E.g. comparing the evaporation flux on either side of the coupler, there appears to be an error of ~4.5e6kg/s
It would be great to discuss whether we would like to add any of the above changes. I’m not sure about the climate effects they could have, though the biggest change - compensating for the UM error - essentially reproduces the effects of the previous bugs.
There are already rough versions of the code for each change, and so if we’d like to add them I think we could get PRs ready within a few days for each change.
It’s also worth noting, these test runs have been fairly short and the error rate can vary quite a lot. Previous runs of the base configuration in the blue line with a different restart only showed half the rate of loss. It’s unclear whether the proposed changes reduce the variation or not.
@spencerwong - thanks for the post.
The comment about the coupler not conserving reminds me that many years we seemed to be seeing something similar for the ocean carbon flux. The global mean calculated on the ocean grid was different from that calculated on the atmosphere grid. My vague memory is that the difference was small but with a global mean close to zero, it was enough to change the sign of the flux. Other things distracted us and we never chased this up.
Thanks @spencerwong and others - amazing story!
My view (not ever having worked with this code) is that if we know there are bugs and can fix them (e.g. 1,2,3 above) then it is worth doing so. It’s less clear to me whether we should target exact balance, or how balanced will be good enough for our purposes…
Minutes from today’s standup, please correct/amend.
Most importantly, the forward protocol/checklist we discussed is now here, it now has pictures! Please get in touch if any part of the forward plan is unclear.
We’ve merged the cice5 work into the dev-preindustrial+concentrations branches, shall we go ahead and make similar updates to the other configurations?
@spencerwong suggests these branches :
dev-1pctCO2, dev-4xCO2+concentrations, and dev-preindustrial+emissions
We think this mostly impacts @tiloz ?
Thanks Anton. Yes, that would be great. I can then start test runs with those updated configurations as well.
Cheers,
Tilo
@anton it might be better to wait until tomorrow to get a new pin up started (before 2PM?)
We just need one more change from @dougiesquire to update the mom5 grid file format - ill email soon to organise a time to start the spin-up ![]()