Why are you using ECHAM5 and not ECHAM6?
The version reference is slightly misleading and there would be no scientific merit in the update.
We still refer to ECHAM5, since this was the basemodel version we used when we started the EMAC (=ECHAM/MESSy) development a long time ago. Over time, all physics subroutines of the original ECHAM5 have been refactored (i.e. re-implmented) as individual MESSy submodels. Furthermore, they all have been continuously developed and are no longer used as the “original” version. In particular, we also incorporated the PSrad radiation scheme from ECHAM6 (and earlier versions of ICON!) as alternative to the E5rad radiation scheme into our RAD submodel. This is relevant since the radiation scheme is probably the most important difference between ECHAM5 and ECHAM6. As a consequence, at the current state only the spectral transform dynamical core, the flux-form semi-Lagrangian large scale advection scheme, and the nudging routines for Newtonian relaxation are remaining from ECHAM5 (which are essentially identical in ECHAM6). See also the LICENCE/Citation rules on our web-page for this.
In summary, we keep saying EMAC to be ECHAM5/MESSy to indicate the roots from where we started, among other reasons to give the credits to those who, over decades, developed ECHAM5 and its predecessors. The model physics in EMAC (i.e. the MESSy submodels), however, has been further developed since then.
Why are you using ECHAM and not ICON?
Actually we do use ICON! More precisely we started long time ago the development of ICON/MESSy and we already had a near-ready implementation, just to be evaluated and published. However, the problem is that the ICON code still changes very quickly without the MESSy consortium being in a position to participate in fundamental design decisions. In other words, we spent way to much time updating our own developments between ICON version, which, however, was necessary to avoid using outdated code and, rightly so, being asked “Why do you use such an old ICON version?”.
In January 2024, the ICON-ComIn (Commmuniy Interface) was released (with MESSy core developers in the ComIn development team!). Thus we decided to stop the ICON/MESSy implementation and rather invest our resources into the further development of MESSy towards becoming an ICON-ComIn plugin (yet keeping its functionality in EMAC and MECO(n)!). So to say we are currently developing ICON-ComIn/MESSy, or, in MESSy terminology, working to incorporate ICON-ComIn as a new basemodel (besides ECHAM, COSMO, the DWARF, etc). The development on the MESSy side is almost complete, ComIn is approaching its first stable release, so we are in good shape. Still, we do want to release only a well evaluated ICON-ComIn/MESSy Chemistry Climate Model, and the process of evaluation is still onging.
When will you be using ICON?
As soon as ICON-ComIn/MESSy has been evaluated, see above. Moreover, it needs to be shown that it is capable of producing “better” results than EMAC (and MECO(n)). Note that speed is not the main purpose!
Why are you using L90 if you are focusing on the troposphere?
The troposhere is not isolated but dynamics and chemical processes in the troposphere largely depend on what is going on in the stratosphere (e.g. stratosphere-to-troposhere exchange of ozone). The literature is full of papers showing all kinds of aspects.
There is also a practical reason: using the same model setup, in particular the same resolution for different studies, means the results are directly comparable and the workload for parameter optimisation etc is reduced.
Why are you (still) using T42?
Simulating the chemical processes in a Chemistry Climate Model (CCM) is very demanding with respect to computational ressources. Compared to an Atmospheric General Circulation Model (AGCM), in our CCM we have at least an order of magnitude more prognostic variables, namely typically between 250 and 3000 (or more) tracers representing the species of the chemical composition of the atmosphere. Thus, tracer transport is more “expensive”, but even more important is that the system of ordinary differential equations (ODE) describing the chemical kinetics (i.e. the chemical reaction mechanism) is very stiff and the corresponding solvers require a large fraction of the overall computational power. Thus, if we want to simulate comparable time spans with CCMs as with AGCMS with comparable computational ressources, namely typically decades to centuries, we have to sacrifice a bit of model resolution for the ability to simulate detailed chemical processes.