Report on the "ALADIN" current work and on its perspectives, Toulouse, 17/03/92.

I) Brief historical background :

• 16/11/90 : A. Lebeau, Director of Météo-France, makes an offer of collaboration in the field of NWP to his five Central and Eastern European Colleagues at the occasion of their visit in Paris and Toulouse.
• 27/11/90 : Formal letter of invitation.
• Period up to 10/01/91 :
  Positive response of all five Central and Eastern European Meteorological Services.
  Successful Météo-France application for a "MICECO-type" grant for the project.
• March 91 : R. Bubnova, D. Devenyi and V. Ivanovici spend a month in Paris for phase a). They conclude to the feasibility of the project.
  CHMI accepts to take in charge the coordinating duties between the Météo-France partners in the build-up of phase b).
  Météo-France decides to "free" three of its NWP staff of most of their other duties to participate in the Project, named at that time LAM-ARPEGE.
• 13-14/05/91 : The Working Group on LACE, meeting in Vienna, recommends "to join the LACE activities with those of the existing "LAM-ARPEGE" action". Subsequently Austria joins forces with the LAM-ARPEGE project.
• June/July 91 : Some decisions about the main ARPEGE project (affecting its evolution up to mid-92) require a revision of the scientific/technical schedule of LAM-ARPEGE. The consulted partners accept the change of emphasis on the early phase of the project and the induced constraints on its time-table.
• 2/09/91 : Start of phase b) on the first official day of the Météo-France new NWP structure in Toulouse (CNRM/GMAP-SCEM/COMPAS).
• 28/10/91 : The Project gets its final acronym ARPEGE-ALADIN (Aire Limitée Adaptation dynamique Développement InterNational)
• 19/02/92 : Among other technical decisions, the date for creation of the "Cycle 0" of the ARPEGE-ALADIN code library is chosen to be 02/05/92.

II) Current scientific and technical status :

This section broadly describes the various tasks that have been initiated and our immediate goals.

During fall 91, most of our efforts were directed towards the building of a common working methodology and towards the clearing up of some aspects of the spectral technique to be implemented in ARPEGE-ALADIN. As a result, a two-dimensional spectral barotropic model was written, tested and validated by comparison with the barotropic code included in our doubly-periodic cycle 0 of ARPEGE.

Then this barotropic code was immediately used for exploring several scientific and technical points. Namely, these were :

• the implementation of the HIRLAM double periodicisation and coupling scheme modified in such a way that coupling is treated very much like a normal tendency term instead of being the last operation within a time step. Extensive tests were done on more than 10 configurations of this technique. The most recent ones bear on the interaction between coupling and the semi-implicit scheme.
• the design and implementation of a "digital filter initialization scheme". Some problems in the diabatic version of the filter have been uncovered, but the limitations of the barotropic equations for simulating active diabatic forcing have also been met. The study goes on, but with a two- dimensional vertical plane model.
• a preliminary study of the impact of relaxing the unaliasing condition : the idea here is that it may be more important to handle orographic problems than to treat advection exactly in dynamical adaptation. This subject will be returned to in the full model.
• The technical solutions adopted for modifying the ARPEGE code will capitalize on the results of these preliminary studies. This is particularly true of what will become our first approach to coupling.

At this point, it should be mentioned that a significant part of the team has been devoted to a direct participation in the development and validation of the spherical ARPEGE model. Tasks endeavoured along this line included :

• completing the diagnostics of the vertical exchanges as seen through all sorts of horizontal means : closing of momentum and kinetic energy budgets, implementation of entropy budget and, currently, implementation of angular momentum budget.
• setting of a final, coherent treatment of mass sources and sinks in the continuity equation and related terms. ARPEGE has, indeed, the capability of accounting for loss of mass through precipitations and gain from surface evaporation.
• audit of the current status of the parameterization of moist convection, an everlasting problem of numerical weather prediction.

Finally, we come to the work done in direct connection with the early stages of the ARPEGE-ALADIN development. Here, we basically aim at producing a solid working environment suitable for future research and development in hydrostatic limited area modelling.

This includes a basic dynamical code working in rescaled cartesian geometry, a preliminary coupling scheme and a proper file preparation and conversion set of programs.

To be more definite :

• the data packing software of the ARPEGE file system is being revised. It will soon allow for the spectral representation suitable for ARPEGE-ALADIN. It was decided not to modify the GRIB code, but rather to use it as in the spherical ARPEGE : it is used only in the final encoding of rescaled data, the spectral coefficients having been separated into a packed and an unpacked subsets outside of GRIB.
  This particular task will provide another kind of information for the future organisation of work, as it is going on (slowly) away from Toulouse, in Vienna. Only the final phasing and implementation will be done in Toulouse in May.
• a version of the program preparing climatological data for a limited area is currently being written, after the original spherical code has been improved by one member of the team.
  On this occasion, a very general approach to the geographic grounding of ARPEGE-ALADIN has been defined, coded and documented. The domain of interest is defined by its corners and its representation by very few parameters. It can be rotated to the equator, projected according to any of the three canonical conformal projections. It has further been showed that the metric of a portion of sphere treated in spherical geometry is equivalent to the Mercator metric. The software indeed allows for a combination of the rotation to the Equator (HIRLAM approach) with the Mercator projection.
• a very general set of programs for initial and ultimately coupling data interpolation has been prepared. It can handle any kind of change in vertical levels distribution, any kind of change in the rotated and stretched geometry of ARPEGE on the sphere. It is currently going through the last validation tests. A documentation will be prepared. It will then be adapted to the ARPEGE-ALADIN geometry.
  We plan to make this piece of software the cornerstone of all data handling of the future ARPEGE applications, both on input and output.

· finally, extensive series of tests have been conducted in order to choose between the adaptation of the existing transforms (that is a fast transform followed by a normal, matrix-type one) or the implementation of a new organisation, chaining two fast transforms.
For vectors larger than 64, the second solution turns out to be more efficient. As a result, three routines from the main body of the scientific code of ARPEGE are currently being rewritten. The multitasking has been completely re-analysed in order to draw all the benefits of the new solution. The routines are coded, and the tests will soon begin.
This was the occasion to review the dynamical formulation of the model. A manuscript already exist, and the basic documentation paper is currently being prepared.

The next important task to be started soon is the implementation of the initial coupling scheme, most probably based on the HIRLAM technique (but as a beginning only). The work on this part is strongly dependent of the new organisation of ARPEGE prepared at ECMWF : this explains why we have not started the modifications yet.

To summarize, background projects are going on that will provide us very strong guide-lines for handling initialization, diagnostics, and soon semi-Lagrangian. Foreground tasks arrive at validation stage. We will soon be able to run a doubly-periodic cartesian model. In a short time, we will also have files suitable for running a limited area model. The coupling is in an intermediate stage : it will be returned to below.

III) Planning of the next steps :

Based on the current version of ARPEGE, but with substantial rewriting of three out of the eight main scientific routines, we will soon have a doubly-periodic cartesian model. The file environment for a coupled model will be ready more or less at the same time, in May.

As soon as the main characteristics of the new ARPEGE organisation will be reasonably fixed, the work on a coupling scheme will begin. A first scheme will be implemented, but with the idea that some very different ideas should remain testable within the constraints (rather stringent ones, by the way) imposed by the ARPEGE framework.

During the summer, all our modifications will be ported into the final, validated, new version of the spherical ARPEGE. It includes some improvements that may turn out to be important for a future operational application of the project : an internal input/output scheme working on CRAY Y-MP machines allows the model to run independently of the memory size available. A reasonably optimized organisation of the semi-Lagrangian calculations will enable us to start working on the subject. We will also benefit from all the development done on physical parameterizations, diagnostics, etc.

During the fall 1992, we will refine and validate the basic ARPEGE-ALADIN code. It will be possible, once this version exists, to finalize some of the impending projects. The initialization scheme will be implemented. A two-dimensional (vertical plane) version will be designed and used in a careful scientific validation programme of the model over steep orography.

This will involve revisiting of unaliasing versus orography fitting, a task made easier by the use of a semi-Lagrangian scheme. Whole parts of the ARPEGE software will have to be adapted to the limited area framework : diagnostics, post-processing, embedded barotropic model, linear and adjoint models, etc.

It should be clear, however, that this will not make ARPEGE-ALADIN a "simple" version of ARPEGE. Because of substantial recoding, ARPEGE-ALADIN will be in a quite distinct library, following its own, independent, maintenance programme.

There are two strong points where compatibility should be maintained at all costs. The first one is the file system. Communication between ARPEGE and ARPEGE-ALADIN is essential for obvious reasons (the one providing initial and boundary values to the other). Coherence in a file system, is, furthermore, essential in insuring a long life-time to such a software.

The other point takes into account the fact that practically all scientific calculations are performed in ARPEGE in the grid-point set of routines. The spectral technique is just necessary for computing derivatives and solving the second order equation resulting from semi-implicit. The grid-point computation set of routines is thus an important part of the code (in volume) that we must keep as strictly compatible as possible with the spherical ARPEGE. This is necessary to mutual validation, transfer of improvements in parameterisations and diagnostics and (less often but still possible) in the dynamics, linear and adjoint maintenance with all the opportunities involved behind this in the fields of data assimilation and predictability. A small, widespread team will not be able to face this maintenance (which is essential for the physical parameterisations, for example) if it has to take care of too many differences in the two models at each stage, especially if the differences lie in nasty little modifications, difficult to document.

It is during this period that some clear and well defined policy concerning the maintenance of ARPEGE-ALADIN will have to be decided.

A minimal coordination with the spherical ARPEGE continuation will have to be taken into account. It will be necessary to choose a location for a reference library, to decide a protocol for changes and their validation and probably to weigh on longer term decisions : opportunity of splitting the library into smaller, dedicated ones (one for physics, one for optimal interpolation), to jump from NOS-VE SCU to a UNIX-based environment, etc.