High Resolution Numerical Weather Prediction Project
Website of the ALADIN Consortium
Article published on 11 April 2008
last modification on 2 December 2015

by Patricia

This important operation is completed twice a year to "phase" the ALADIN code with its "mother" code ARPEGE (see history of cycles and phasing team and some statistics on phasing effort).

The ALADIN code is following the ARPEGE one in its permanent evolution (see history of ALADIN cycles). This is due mainly to the technical evolution of calculating machines (CDC, CRAY 2, CRAY C90, FUJITSU, NEC...) which imposes a new adaptation of the code to the new machine properties.

The evolution of the number of observations over the world dictates also a code development if one wants to take new observations into account.

In addition to these two external constraints, code must contain the newest coding rules if one wants to have a permanent portable one, ...

Code optimization, as bugs correction, compas bugs correction, computation time and memory winning, ... is also another constraint.

And of course, the evolution of the code is also imposed by the new developments (a development usually involves another one !).

Phasing is centralized in Toulouse since a very close co-operation between ALADIN and ARPEGE scientists is required for this crucial exercise. The stays are usually 6 weeks long, costs may be supported by Météo-France. Deported validation of cycles are accepted as contributions to phasing exercises exceptionally, for technical options that cannot be validated in Toulouse.

A Phasers’ guide defines the rules of these phasings :

  • The code can be modified for the above-mentioned purposes by a limited number of known developers or phasers to avoid complexity and misunderstanding consequences. Thus, ALADIN code can be touched only by GMAP team, ALADIN partners, some SCEM teams (COMPAS) and of course persons who come to GMAP for training.
  • The software validation after modification is an absolute must. The phaser or developers must intensively validate its work. After the entire merge of modifications, all the system configurations must be tested and validated. And before using the new software for operational purpose, a double suite is strongly recommended.
  • So a phaser must keep in mind that he has to respect all coding rules, to check all interactions with the remaining code at each step. He must also phase his scripts and namelists and keep himself informed about all what is being performed into the whole code at the same time.

A Phasing roadmap summarizes the phasing general rules on source code and draws phasing roadmap of actions.