-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update components for v0.3.0 #118
Comments
Has CESM upgraded to CICE6.5? If not we might need to get it from upstream to get C-grid support #39 |
Yes, this is the version used in the development branch of CESM: https://github.com/ESCOMP/CICE/releases/tag/cice6_5_0_20240222 |
Re: dependencies / spack
That's only 3 commits behind the current main, one of which is irrelevant to us, but the other two fix bugs relevant for us. One is the calendar cice patch and the other is a bug in PIO implementation for CESMCOUPLED. |
Here is a summary of the changes from the previous CESM version we used and the latest one: CICE: 6.4.1_20230620 -> 6.5.0_20240222 The following OM3 external libraries are also updated in CESM: parallelio: 2.5.10 -> 2.6.2 Note that for FMS the git repository was changed and CESM is no longer using an official release. Instead, it's using a fork, probably because of some extensive patches. Let me know if all these are okay, or if we need some newer/different version. Regarding FMS, I'll investigate what are the changes introduced in the fork. |
I'll start updating the Spack environment next week, so this will probably have to wait.
Let's then use the current main for CICE. |
Yes! Fixed now. |
I updated the comment to reflect this better. It's really confusing when people add their own versioning to their forks 😢 |
ACCESS-OM2 performance was 1.5% better with https://forum.access-hive.org.au/t/testing-spack-model-component-builds-for-access-om2/1567/11 See also ACCESS-NRI/ACCESS-OM2#30 |
We haven't tested this, as we did not use 2.5.2 and instead started with 2.5.9. |
I think you might have said yesterday, but is doing a 0.3.0 config tag stuck on something ? |
I need to finish updating the configurations. Working on this, but today gadi hasn't been behaving very well... 😢 |
Yes its being a bit flakey! |
Do we know why yet? A couple of people from our group have reported to NCI, but have not had helpful responses. NCI didn't acknowledge or seem to know that it is a system-wide problem. |
Not sure if it is because someone is using login node doing something... |
I've tagged the OM3 codebase. Now waiting to get all the required changes into the configs. |
Considering that the configurations are all in different states of development, I'm not sure we should tag a new release for each of them. |
How about tagging for MOM6-CICE6 only? What is the downside to tagging the release? (I guess tagging a not-working point in history is useless) |
Assuming the configuration as tagged works, there's no downside, specially because all of them are not yet considered to be "stable" (version < 1.0). I guess the question I'm asking here is if it's really useful to tag all the configurations. My original plan was to tag simultaneously both the codebase and all the configurations, so that it was clear that version X of a given configuration worked with version X of OM3. Now that it was decided to decouple this, there's no need to tag the configurations when tagging the OM3 codebase. |
Whats happening with https://github.com/COSIMA/MOM6-CICE6-WW3/tree/1deg_jra55do_ryf ? Did we intentionally not update the binary? Or forget ? |
IIRC, that configuration was quite behind the IAF one and required some more extensive changes to work with the latest exec. But maybe I'm wrong? |
I think we can close this as completed. @micaeljtoliveira points out - the configs are constantly being updated, and you can now tell which binary they were tested / working with from the path in config.yaml, so adding the version to configurations doesn't add any information |
Okay, closing this then. Note that once the NRI release team is ready to deploy the OM3 configurations, you should tag them, so it's clear what is to be deployed. |
This issue is to plan and track the progress of updating the OM3 components to newer versions.
Before starting this, it would be good to tag the codebase and the configurations. It's not strictly necessary, but it's good practice to do it before adding changes that will most likely break backward compatibility.
So here is a first attempt at the list of tasks:
Do a release of the officially supported configurations (MOM6-CICE6 and MOM6-CICE6-WW3).The text was updated successfully, but these errors were encountered: