LINK TO NEW ALADIN WEB
Lampe ALADIN
 ALADIN Consortium
 ALADIN Documents
 ALADIN Model

The ALADIN system

The scientific contents The configurations Cycles and phasing The external tools The exchange of applications in the ALADIN's world The verification project

 

ALADIN was entirely built on the notion of compatibility with its « mother » system, IFS/ARPEGE.

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). Currently, the IFS/ARPEGE cycle 20 exists, as well as the ALADIN cycle 10, the latter being phased with cycle 20 of ARPEGE. The difference of 10 between the numbers simply reflects the fact that the ALADIN project was launched roughly four years after IFS/ARPEGE. The help of ECMWF staff in solving these complex problems is gratefully acknowledged here.