Hi, Many people said they didn’t have time to digest the ACCESS-NRI work plan and give feedback at the COSIMA meeting this morning. Below are the relevant parts to COSIMA.
We still have a couple of weeks to give feedback on whether this aligns with COSIMA’s priorities.
I suggest we put together a list of suggested changes, and vote on the order of them below.
I have two comments:
Hi, some additional points from me:
instructions/support for common perturbation experiments performed in our community (freshwater fluxes, atmospheric forcing) + playing around with the bathymetry/grid/different vertical coordinate (given that MOM6 has different options)
communicating/informing the community to help with the transition from OM2 to OM3: What is different? >> Model configuration (MOM5 vs MOM6), workflows re running/analysing the model
regional modelling: are there any plans to develop nesting capabilities?
I’m with Julia and Adele on that one: it is only logical to add the OM3-8 km alpha release as one of the priorities, since is what people were more interested according to the polls.
The jupyter instructions for setting up a regional model domain on NUOPC would be very helpful!
I second this and reiterate (for prosperity) my comment from this morning: it would be fantastic to have ACCESS-NRI support for the COSIMA Recipes written into the workplan. In particular:
This is our plan for the September COSIMA hackathon, but help before, or in Melbourne, or after would also be amazing.
Thanks @adele-morrison, I’ve highlighted this internally again. You said you could send a specific list of recipes that students/community folks are having a hard time with?
Thanks @cbull! Main ones I’m aware of that have been problematic for students recently due to the lack of intake conversion are:
- The COSIMA recipes are not ready to be ported. There’s heaps of intake conversion/bug fixing to do. And even if they reach the stage they can be ported, they are quite organic in the sense that bugs and fixes are found constantly, as well as new recipes coming up, etc. How would the porting work? Everytime there is a change would it be immediately incorporated to the ESMtools, or would the later be lagging behind?
We had a meeting with @CharlesTurner and @marc.white yesterday and discussed a few ongoing challenges. The conversion to intake is mostly complete, but getting the pull requests reviewed has been tougher than expected. The intake conversion itself is largely a technical step — and that part is done for most recipes.
However, during the conversion process, people uncovered bugs or realised that some workflows could be improved. That’s slowed things down significantly, and it’s become harder to distinguish between what’s a technical task and what’s a scientific one. Ideally, the porting process should preserve the original outputs when moving from the COSIMA cookbook to intake.
Another issue we’re facing is the incomplete transition away from hh5. Some recipes are still relying on data located in temporary or legacy folders on hh5, which is far from ideal and adds further friction to the process.
Because of the overlap between conversion and content fixes, it’s been unclear what to prioritise. We’ve made a few pragmatic decisions and have started merging converted recipes, even if some scientific issues are still unresolved. We’re happy to help and make sure the recipes remain functional for both MOM5 and MOM6.
There’s also been some confusion around what it means to bring COSIMA-recipes into ESMValTool. As you know, ESMValTool is primarily aimed at CMIP evaluation. Its strengths lie in semi-standardised outputs, a wide range of observational products, and a powerful pre-processor that streamlines CMIP model evaluation. The broader ESMValTool community — largely from the ESM world — has been calling for more ocean diagnostics, and the plan at ACCESS-NRI is to help fill that gap using the insights from COSIMA-recipes.
We’ve been careful in our work plan to use language that acknowledges the foundational work of the COSIMA community. Our goal isn’t just to port recipes, but to build on that legacy within a more standardised framework. The hope is that this transition leads to more robust and reusable ocean diagnostics.
That said, we’re not yet in a position to directly use raw model outputs (e.g. OM2, OM3) in ESMValTool. We’re actively working on this, but it depends on some upstream progress — particularly around standardising outputs and improving the flexibility of CF/CMOR conversions.
