What technical advancements do we need for CMIP7?

[hb326]

There are several possibilities around right now to propose technical advancements of ESMValTool to different funding agencies. While we do have a long-term vision where we think the development of ESMValTool should go (you can find it here), there might be some ideas from all of you, what you would need in preparation for CMIP7. Note, these are indeed technical advancements that we are looking for here, not science advancements.
So, what advancements/changes/updates would you need to optimize your analyses of CMIP7 simulations?

Thanks all for thinking about this and providing your suggestions here!
@ESMValGroup/technical-lead-development-team, @ESMValGroup/scientific-lead-development-team, @ESMValGroup/userengagementteam, @ESMValGroup/esmvaltool-developmentteam

[bettina-gier]

I think before proposing additional technical advancements for funding agencies, it would be vital to know what is already promised within other projects and on the to-do list. The roadmap on the website is outdated and says it is under revision, do we want to collect promises in already funded projects there again or find some ways, potentially in this community repository where it is easier for people to just drop a message "Hey project xy is funded with some contributions to ESMValTool. It is promised/planned to incorporate these abc additional features"? Apologies if this already exists somewhere I'm unaware of.

But for example, at Uni Bremen we just got the next phase of the TRR181 project funded, in which we promise diagnostic and corresponding feature additions (or testing) for high-resolution and native model data. This will include adding capability to read data on HEALPix grids and since data provided by other groups in the project will likely be formatted as zarr data in intake catalogues, this will also have to be implemented. (I think Bouwe wanted to collaborate with me on the intake part.)

[hb326]

While it would definitely be nice to know what is included in all kinds of projects already, at this point we really only would like to brainstorm on what would be needed for ESMValTool to be valuable for CMIP7 analyses. If people suggest "reading HEALPix grids" then it is great because we know that we are already on the right track with our development.

[alistairsellar]

Thanks @hb326 and @bettina-gier for kicking this off. I'll add some suggestions:

• Clearly support for the new ESGF interface (intake STAC?) will be critical. Benefit for CMIP: this will enable ESMValTool users to actually use CMIP7 data.
• Along the lines of @bettina-gier's thinking, support for other cloud-native datasets / formats. Benefit for CMIP: allow combination of CMIP data with more datasets that will add value to the climate change analysis.
• User support and training targeted at CMIP users. Benefit for CMIP: more users can do more powerful analysis of CMIP data.
• In-flight pre-processing of model data (e.g. spatial or temporal aggregation) while a simulation is running, to reduce the volume of data that needs to be archived. Benefit for CMIP: reduce the energy cost of CMIP simulations and/or enable more valuable analysis for a given archive cost - particularly important for high resolution models.
• Caching of pre-processed data from one ESMValTool invocation as input to another, to enable more efficient monitoring of ongoing simulations (avoiding repetition of calculation on every monitoring cycle). Benefit for CMIP: reduce the repeated cost of pre-processing the same data, and increase the coverage of monitoring, identifying problems earlier and thus saving compute cost.

[sloosvel]

Some suggestions from BSC:

• As @alistairsellar has mentioned, the ability to use the pre-processed data from a previous ESMValTool run to as input to a new run.
• More pre-processors for ocean data operations (rotating velocities, computing transports along different sections). Benefit for CMIP: write more efficient diagnostics, as the data that inputs the diagnostic will have been pre-processed instead of having to load the full dataset as input.
• Move the generation of current monitoring plots to the pre-processor. Benefit for CMIP: Generate on-the-fly plots for monitor runs, reducing the amount of data that needs to be saved and loaded into the diagnostics.

[bouweandela]

Here are a few more ideas:

• Develop a community fixes package based on Xarray (we can convert to Iris using the ncdata package). Ideally, this package should have a strong link with the CMIP errata service. There have been many scattered and overlapping fixes developments over the years, e.g. xMIP, CIS, PMP, Freva, iris_helpers, ESMValCore fixes, ESMValTool CMORizers, obs4MIPs CMOR scripts. It would be much more efficient to share the development of these fixes.
• Better user and contributor support: better documentation (our documentation remains inaccessible because it is poorly structured), we should be more responsive to bug reports, feature requests, and contributions, the community meetings need to be organized regularly, etc.
• Support more diverse input data sources: e.g. intake-esgf, intake-esm, STAC, xcube, ..
• Computational performance improvements of the preprocessor functions and the way they are run, better integration with the existing software ecosystem: e.g. add support for temporal aggregations using flox (preferably through Iris), ensure we are able to run every recipe on the distributed scheduler, and efficiently utilize the available hardware already when we load the datasets.

[bettina-gier]

Good call on fixing what's there, and not just adding more noodles to the spaghetti.

[schlunma]

On data sources: I just got a newsletter from DKRZ about https://gems.dkrz.de/. Might be relevant here, I didn't check in detail though.

[valeriupredoi]

eugh, GEMS are annoying 😖

[bouweandela]

Looks like more data we could support trough intake(-esm).

[bouweandela]

@axel-lauer mentioned at the workshop that finding and loading data can be slow when searching/loading thousands of files (on a Lustre filesystem). It would be nice to improve this.

[rswamina]

Potential ideas for user engagement activities that need funding:

1. Tutorial development focused on new data sets/new technical develpments/standard diagnostics (REF or REF++ type diagnostics).
2. Tutorial updates/version compatibility with ESMValTool and ESMValCore.
3. Regular training or ESMValTool clinic type sessions.
4. Community engagement - monthly meetings, individual team meetings, monitoring disucssions and issues for feedback/questions from community.
5. Liaising with modeling groups to identify needs for new science diagnostics?

[katjaweigel]

From exchange with modelling groups in projects, I'd say there is often not that much: "Needs for new science diagnostics?" - Modelling groups often have a lot of diagnostics, but these work only for their own model. So the need would rather be to make the diagnostics available for cmorized data/ any model where ESMValTool can read native data. However, there is often not much support from the model groups on this: I think they often prefer other model groups to use their code (to maybe also get co-authorship on papers) not to include their diagnostics in ESMValTool, at least not if it brings any work with it.
The other ideas I like a lot, I think the whole user engagement is really important, because (potential) users often don't really know what the ESMValTool is/can do. Some random comments I got in this direction in the last months:

• Is the ESMValTool only developed in Bremen?
• Yes, there is a recipe, which can do what I need, but it uses really old CMIP5 data

[StefanHagemann]

5. Actually, currently ESMVal tool is seen as tool for the evaluation of data from global ESMs. However, in the regional climate modelling community, there are also thougts on using a common evaluation software. Within the CLM community, currently the Hereon EVASuite is used, which works but its usability can certainly be improved. There are potential options to align with the Freva system, or alternatively the ESMval tool was mentioned on the recent CLM assembly in the end of October. If features of the EVaSuite would be included in ESMVal it may certainly extend the list of potential users to the regional climate modelling community.

[rswamina]

Proposed identification and porting of NCL diagnostics relevant for continued CMIP evaluation with CMIP7 and targeted towards IPCC AR7. The Issue #1057 lists these diagnostics.

[rbeucher]

[like] Romain Beucher reacted to your message:

…

________________________________ From: katjaweigel ***@***.***> Sent: Wednesday, November 20, 2024 9:31:28 AM To: ESMValGroup/Community ***@***.***> Cc: Romain Beucher ***@***.***>; Team mention ***@***.***> Subject: Re: [ESMValGroup/Community] What technical advancements do we need for CMIP7? (Discussion #187) From exchange with modelling groups in projects, I'd say there is often not that much: "Needs for new science diagnostics?" - Modelling groups often have a lot of diagnostics, but this work only for their own model. So the need would rather be to make the diagnostics available for cmorized data/ any model where ESMValTool can read native data. However, there is not much support from the model groups on this: I think they often prefer other model groups to use their code (to maybe also get co-author ship on papers) not to include their diagnostics in ESMValTool, at least not if it brings any work with it. — Reply to this email directly, view it on GitHub<#187 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA4CVFTLWJUA6MSSBH4HR432BRJHBAVCNFSM6AAAAABO7DLBSWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZRHE4TSNI>. You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>