IS-ENES3 Planning¶
List any ideas here under a heading and we will organise the information later
Data Processing and Workflow (Mick Carter)¶
google>ESMValTool is "a community diagnostic and performance metrics tool for routine evaluation of Earth system models in CMIP." It is being developed on top of Iris http://scitools.org.uk/ which was considered in IS-ENES23 but was not open source at that stage. The team at the Met Office that develops Iris is supporting ESMValTool on very slim resources and both projects would benefit from being funded to work together to accelerate development.
Further, as we move to larger ensemble members and more and more data for our MIPS, there is a need to integrate such tools into a structured workflow. This will allow us to exploit the many degrees of parallelism available in climate data to the full. The development of ESMValTool based suites driven by Cylc would bring a new degree of automation to our community. We could even consider using Rose on top of Cylc to provide configuration management as a demonstrator.
Finding partners who want to engage and adopt the tools is just as important and providing the support and should also be properly funded in the project. It does not need all partners to be an effective demonstrator but we need deeper engagement that was achieved in NA3/WP4 of IS-ENES2 to be effective. We have to have a real interest and commitment in the tool rather than just a desire to have a slice of the money in the WP.
Sébastien Denvil may be interested in using Cylc at IPSL for data processing. We could seek to fund both the development and the Cylc support of the development.
Comments:- (Paco) I support Mick's idea to use Cylc as a workflow manager for ESMValTool. BSC, as a main developer of ESMValTool, has already identified the need for such a development to speed up the processing by distributing the jobs taking into account their dependencies (or lack of). Besides, ESMValTool would hugely benefit from the implementation of a provenance (propagation of the metadata through the different diagnostics to provide a result that is reproducible) solution and from the investigation of porting some of the most expensive diagnostics to use other architectures (e.g. GPU cards on Power nodes), of which the BSC has found that speed-ups of two orders of magnitude can be achieved.
- (Paco) The BSC is considering workflow managers for data processing. However, we are investigating the use of both Cylc and ECFLOW to try to make the most of each workflow manager.
User driven development of XIOS and supported adoption (Mick Carter)¶
XIOS is a tool that is gaining momentum in the community. If it were better resourced, it may be possible to have development activities that are prioritised by the community which would encourage further adoption. Also, if we were to get funding for adoption (rather than just funding support) then the user engagement would be accelerated and be more effective. The Met Office plan to use XIOS for LFRic and possibly wider and could better invest in longer-term requirements if both us and the XIOS team were funded to think more strategically for the long term. For example, higher performance parallel read support for initial conditions would be beneficial in the longer term.
The potential for the XIOS to provide a coupling solution and what this means for OASIS should be explored. For example, could this be an opportunity for us to do some governance via a definition of a common interface standard?
Is this best suited to IS-ENES3, ESiWACE2 and/or EPECC.
Comments:- (Bryan) We're in the process of developing extensions to XIOS and the UM to support ensemble diagnostics on the fly. I'm pretty sure that it will be pretty bespoke, but an IS-ENES3 objective could also be to make that more generic, so ensemble diagnostics on the fly could become more easy for all. There are issues around MPI and ensemble member stability, but these should be resolvable on this timescale.
- (Paco) BSC is installing XIOS2 in IFS at ECMWF. This is done directly in the IFS repository instead of EC-Earth or OpenIFS so that the performance can be compared with ECMWF's I/O server. This also means that both OpenIFS and EC-Earth will inherit the benefits. Once it is installed, the possibility of performing diagnostics on the fly will be evaluated.
User evaluation of YAXT (Mick Carter)¶
IS-ENES2 showed YAXT to be a high performance and flexible tool for data exchange of unstructured grids (coupler comparison work led by Sophie). I think It does not yet have the same level of community interest as XIOS but certainly has potential. The Met Office would be interested in evaluation and would also encourage the OASIS and XIOS team to evaluate if there could be any shared code between YAXT and OASIS and/or XIOS. Is this best suited to IS-ENES3, ESiWACE2 and/or EPECC.
Comments:- (your name) your comment
Core support for ES-DOC (Bryan Lawrence)¶
ES-DOC is currently unfunded ... we should be ensuring that it remains funded under IS-ENES3
Comments:- (your name) your comment
Better support for OASIS use of ESMF (Mick Carter)¶
OASIS priorities should be defined by the new OASIS governance structure, but OASIS does not stand alone and relies on ESMF for the calculation of the weights file. It would be good to have a single support structure for OASIS and the things it depends upon, if this is considered a priority.
Comments:- (Sophie Valcke) please see "OASIS3-MCT support and development" below
On-going Cylc support post ESiWACE funding (Mick Carter)¶
Although Cylc uptake outside the usual suspects has been slow, there is clearly interest (EC-EARTH, IPSL, CMCC). Funding of support and effort to adopt to better encourage community adoption is preferred.
Comments:- (your name) your comment
OASIS3-MCT support and development (Sophie Valcke)¶
A user survey is currently going on to define OASIS3-MCT priority developments to be proposed as IS-ENES3 tasks. These will be reviewed by OASIS Advisory Board and finally proposed by OASIS developers (planned date is around November 15th)
Extension of IS-ENES2 coupling benchmarks (Sophie Valcke)¶
All partners involved in the IS-ENES2 coupling benchmarks (Met Office, STFC, U Manchester, Cerfacs) are interested in pursuing the effort in IS-ENES3. Details still need to be discussed.
Computational performance analyses (Paco Doblas-Reyes)¶
With the increase of model complexity and the advent of new architectures, computational performance is proposed to be continued in ISENES-3. Although this aspect is partially covered by POP, and ESiWACE includes it for high-resolution configurations, there is little that POP does currently to suggests ways out of the bottlenecks identified and other configurations are not systematically investigates. Besides, not many weather and climate models have been analysed yet by POP. Computational performance analysis could include all current models and take into account bottlenecks for ESMs too (e.g. chemistry modules might be a particularly relevant aspect of the model performance). Tools, methodologies and training to users could be broaden to cover.
Develop a strong European framework for ESGF (Paco Doblas-Reyes)¶
ESGF is a key infrastructure for the community but due to the complexity is hard to attract new users and, therefore, publish new data, particularly if they are not part of a CMIP exercise. The BSC went through a very long and painful process to install an ESGF data node from scratch. Imagine what the situation could be in an institution without the technical expertise available at the BSC. IS-ENES3 could lead a thorough strategy for the ESGF development and, more importantly, maintenance.
Support for Grand Challenges (Bjorn Stevens, Reinhard Budich)¶
As we all know, WCRP is supporting the Grand Challenges.
Scientifically we think support for European contributions to the Grand Challenges would help better highlight the scientific contributions we wish to make. The Grand Challenges are helping to define the shape of organised activities like CMIPx among other things, and keep the science, rather than the organisational or administrative aspects in the forefront of our case. In this context, for instance, MPI-M could imagine to have support in the centers to perform transpose AMIP experiments in coordination with EUREC4A in support of the Clouds and Climate Sensitivity GC, or something to be specified in the context of the carbon feedback GC. But we also have interests in decadal prediction and sea-level GC. In any case, it is very well conceivable to use ESGF technology and software to support GC activities.
New Software Engineering Concepts (Bjorn Stevens, Reinhard Budich)¶
We think the ENES could be a platform for exploring new software engineering concepts. Pilot projects that explore code granularity using several models to identify patterns that might allow them to be adapted to more hierarchical computing environments would seem to fit in the frame of ENES. Alternative programming models should be considered, also expressed in different languages. I/O will remain a chronic problem that requires continual attention. One new aspect here is the increasing need to develop new programming/data models that blur the distinction between bytes in core and bytes on disk. This also links, in a not completely direct way, to server side processing, although here we see progress with things like JUPYTER Notebooks. Substantial work has also been done by CERFACS, MPI-M in the context of EUDAT on a system named GEF , which is ready to be used by the community, but needs support in terms of proliferation and example use cases. DKRZ is ready to play a big part in this.
Finally we think the ENES should continue to support the development of common code libraries for aspects of the models where we do not intend to disagree in how they are formulated. Here things like forward operators, radiative transfer, orbit calculations, time-keeping and event handling, I/O, are good examples. We would be eager to continue support for the radiation libraries and the forward operators.
Exchangeability of GRIB and CF Conventions (Luis Kornblueh, Reinhard Budich)¶
Intro¶
Two data formats are used in the meteorological and climate community, based upon GRIB (NWP) and CF (ESM). Both are hard to map to each other. In the Copernicus framework, ECMWF is working to remedy this situation partly, see e.g. here. But in light of many attempts to provide data format agnostic metadata descriptions it would be a big step forward for linking the NWP and ESM community as well as associated researchers by a generic metadata model joining the metadata model of both groups and allow for a clean implementation in different file formats.
Proposed Work¶
- Establish a common working group of the WMO and CF communities to propose a common meta data model which is expected to be a superset of both existing metadata models.
- Add the missing features of the 'other' metadata model in the one missing the feature.
- Implement the mapping of the generic metadata model to the specific implementations necessary for the two existing file formats: Grib ed.X (tables) and netCDF (CF-Convention)
Another topic here (Your name)¶