Interfaces & Tools#
Zonda: ICON Grid & EXTPAR Interface#
Zonda is a web interface designed to facilitate the generation of External Parameter data (EXTPAR) on ICON triangular grids for research and on-demand simulations. This is realized as a two-step process:
In the frontend, the user specifies the domain(s) including the appropriate settings for the external parameter generation. Example configurations and an expert mode with additional choices are available to assist the user. As a result, the user gets a JSON code snippet which is required for the second step.
In the backend, the JSON code has to be pasted into a github issue. Then, the github CI triggers the generation of the ICON Grid and EXTPAR data.
Please note that the grids and EXTPAR data generated by Zonda are targeted at the NWP physics package.
Community Interface (ComIn)#
Code contributions from different researchers and institutions (“third-party code”) are usually not included in the main ICON code, but remain confined to project branches. In any case, they add specific switches and calls to ICON’s main loop, making the model code less readable. On the other hand, to keep the third-party code compatible with new versions of ICON additional maintenance is required. These problems are solved by providing a unified plugin interface: The ICON Community Interface ComIn. While the core model remains unchanged, third-party code can be run alongside ICON, even if it is implemented in a programming language other than Fortran. ComIn provides interfaces for Fortran, C, and Python.
The Community Interface (ComIn) organizes the data exchange and simulation events between the ICON model and “3rd party modules”. The concept can be logically divided into an Adapter Library and a Callback Register.
Adapter Library: It is included in both, the ICON model and the 3rd party module. It contains descriptive data structures, and regulates the access to existing and the creation of additional model variables.
Callback Register: Subroutines of the 3rd party module may be called at pre-defined events during the model simulation.
Documentation
User Guide
Publications
Examples
How to develop your own plugin
Setup instructions
Exercises
Programming a Rather Simple ComIn Python Plugin
Masking (Non-)Prognostic Cells
Implementing a Diagnostic Function as a ComIn Plugin
Memorandum of Understanding
Memorandum of Understanding (MoU) for the development and maintenance of the Community Interface (ComIn) for the ICON model system
Version 0.4 (as of November 21, 2025), translated from German
This Memorandum of Understanding defines the purpose, responsibilities, processes, and decision-making mechanisms of the governance structure of the Community Interface (ComIn) for the ICON model system. This Memorandum of Understanding is not a legally binding agreement. It does not establish any enforceable claims or obligations on the parties. The goal is to establish ComIn as a long-term stable and community-supported programming interface in order to enable the sustainable integration of scientific developments from the community into ICON.
ComIn
The ICON Community Interface (ComIn) was jointly designed and implemented by developers from the ICON partnership and users of the ICON model system (hereinafter referred to collectively as the “ComIn development team”) with input from the national ESM community. The aim of the development is to provide and further develop a reliable and stable programming interface (API) for ICON, which is made available to the community as the ComIn library. This is intended to decouple the developments of ICON and the interface and enable the community to use (scientific) program codes as so-called ComIn plug-ins via the interface in simulations with ICON. In this way, external developments for ICON can be carried out independently of direct cooperation with parts of the ICON partnership.
ComIn Development Team
The group of ComIn developers consists of participants in regular (preferably monthly) developer meetings and is essentially listed in the file AUTHORS.md. The ComIn development team (currently with participants from the DWD, DKRZ, DLR, and FZJ institutes) defines the releases of the community interface, organizes the implementation steps, and develops proposals for future changes. Suggestions and requests from the user community are welcome. The ComIn development team attempts to take these into account in further development within the scope of available resources and after assessing possible side effects and incompatibilities. Priorities and responsible developers are assigned for the necessary tasks. Decisions are made by mutual consensus. The development team decides on the inclusion of additional institutions.
ComIn Development
The development work of the ComIn development team extends to the ComIn library (including sample plug-ins and test programs). The ComIn development team has sole decision over the further development and releases of the ComIn library in accordance with the described decision rules. Changes to the ICON model code that are necessary due to adjustments to ComIn or that affect the functionalities of the ICON model system are discussed by the ComIn developers together with the ICON developers and, if necessary, implemented as prototypes so that a decision can be made. The final decision on adapting the ICON model code lies with ICON-C5. The ComIn development team will contribute suggestions and support their implementation. The distribution of ComIn together with ICON does not restrict the further distribution of ComIn by the ComIn development team, even in versions that differ from the ComIn versions in ICON releases.
Collaboration and Exchange
The ComIn development team is responsible for the maintenance, further development, and quality assurance of the ComIn library. Within the scope of its capabilities, the ICON partnership is committed to supporting this work, for example through code reviews, integration tests, or the provision of infrastructure for software development. For mutual information about planned developments, representatives of the ICON-C5 steering group are invited to the ComIn developer meetings. Likewise, representatives of the ComIn development team can be invited to C5 meetings and to the release planning of the ICON model system as needed. Decisions about the ComIn library are made by the ComIn development team. Decisions about changes to the ICON model code are made by ICON-C5. Mutual information and early coordination are intended to ensure that the interfaces remain stable and compatible in the long term.
Data Analysis & Remapping (CDO)#
CDO is a well know data anlysis tool developed by Max-Planck-Institute for Meteorology. CDO supports the ICON native horizontal grid so that ICON model output can be easily analysed.
Examples:
Horizontal interpolations can be done with a wide range of methods
Vertical interpolation from ICON (atm) vertical sigma hight coordinate with the
ap2ploperator:(optional) add CF-conform name for pressure with
ncatted -O -a standard_name,pres,o,c,"air_pressure" <input> <output> # using NCO
or
cdo -setattribute,pres@standard_name='air_pressure' <input> <output>
call the
ap2ploperator in this case for a remapping to the 500 hPa and 825 hPa levels
cdo ap2pl,50000,82500 <input> <output>
ICON forecast set with ecflow at ECMWF#
This suite provides an easy way to test ICON model physics. Short forecasts for January and July are performed and many plots are generated. References are the ICON or IFS analysis, a reference experiment and observations (CERES radiation, IMERG precipitation and WHOI ocean surface parameters). The tests are done on atos at ECMWF using an ecflow scheduler.
The following issues need to be considered:
apply for access to ECMWF computers and the ecflow server
compile ICON at ECMWF
ICON ECMWF scheduler code is part of the ICON repository here: schedulers/ecmwf. Key directories are suites (python ecflow setup), tasks and cases (namelists).
automatic transfer of plots to the DWD plot-catalog
More details are available here ICON at ECMWF: ecflow suite.