ALADIN was entirely built on the notion of compatibility with its « mother » system, IFS/ARPEGE.
- The latter, a joint development between the European Centre for Medium-Range Weather Forecasts (ECMWF) and Météo-France , was only meant to consider global Numerical Weather Prediction applications ;
- hence the idea, for ALADIN, to complement the IFS/ARPEGE project with a limited area model (LAM) version, while keeping the differences between the two softwares as small as possible.
It was, therefore, absolutely necessary to copy the organization of the code from one system to the other. The key words for this organization are :
- integration (all applications are developed and maintained inside a single software piece) ;
- flexibility (as many options as possible available on simple manipulations of unformated input files) ;
- modularity (one function = one single piece of code) ;
- and generality (as few restricting assumptions as feasible, both for the science and for its algorithmic transcription).
Furthermore, the duality between ARPEGE (global with the possibility of variable resolution) and ALADIN (LAM), sharing the same grid-point dynamics and physics, is a formidable advantage for tackling the NWP challenges of the coming years at high resolution. For example, inside the two projects, advanced (variational) data-assimilation aspects have mostly been tackled in the global framework, while high-resolution aspects (non-hydrostatism) were explored in the LAM framework, always keeping open the possibility of transfer from one side to the other.
The strict application of the integration-flexibility-modularity-generality (IFMG) rule inside the ALADIN part of the work is now a rather well-established practice. Of course, the compatibility with IFS/ARPEGE complicates matters. There are, for instance, four types of ALADIN routine :
- those common with IFS/ARPEGE (e.g. physics or grid-point dynamics) ;
- those duplicating the scientific functions of one IFS/ARPEGE routine in the LAM framework (e.g. spectral computations) ;
- those duplicating the controlling functions of one identically named IFS/ARPEGE routine (e.g. organization of one time step) ;
- and those specific to ALADIN (e.g. coupling with larger-scale information).
This complexity is especially penalizing for the crucial maintenance process, which is copied from the IFS/ARPEGE one, i.e. it is organized around « cycles » (fully validated releases every six to nine months). The help of ECMWF staff in solving these complex problems is gratefully acknowledged her