PreWarmWorld will demonstrate prototype components as the first steps of a blueprint (initial design choices) to enable further development of the ICON model as well as refinement of the blueprint, and its successive implementation at finer levels of granularity.

For an effective and scalable further development, the blueprint will have to consider how to best encapsulate components shared by communities of practice (like model physics, ocean dynamics, matter transport), in ways that take the best advantage of computational paradigms, memory access patterns, and externals (such as related or linked software developments, i.e., data-assimilation).

Furthermore, there has to be an in-depth analysis regarding appropriate and sustainable programming paradigms for the implementation phase. So far, no vendor-independent standard to address heterogeneous hardware architectures of upcoming exascale systems exists. Because of the long life cycle of codes like ICON and their large code size, repeated rewrites of the whole code for any upcoming system is highly expensive and error-prone and must be avoided. All of these arguments call for a modular and flexible codebase.

Constructs to express parallelism are making their way directly into the language standards of Fortran and C/C++, and are being implemented in the compilers. However, none of them is ready for exascale parallel applications. The performance of ICON is mainly limited by memory bandwidth. Hence a key feature for performance is a proper memory layout and management especially on heterogeneous architectures, which often leads to different data structures and code paths. For this reason, Domain-Specific Languages (DSL) have been successfully introduced in several scientific disciplines. Theoretically, they offer a proper way of abstraction from the underlying hardware, while allowing for improved readability within the domain they are used in. Similarly to DSLs, libraries can serve the same need: Kokkos is a promising candidate for that from outside of our scientific domain.

The future design of ICON has to consider and leverage these approaches as much as possible. The design should be flexible enough to rewrite parts of the code, based on the language or library which is most appropriate for the problem (which can differ for different parts of the code) and underlying hardware at hand. The general approach could be described as a blend of revolutionary and evolutionary development: Individual components will be rewritten using novel (“revolutionary”) methods while still maintaining a fully functional model thus providing a smooth (“evolutionary”) path to a next-generation storm and ocean eddy-resolving ICON model.

Back to top