3DVAR WORKSHOP IN BUDAPEST

(more details: Andras HORANYI, HMS)

29th of May, 2000 - 9th of June, 2000 with Maria Siroka, Claude Fischer, Andras Horanyi

 

Introduction

At the end of last year while planning the stays for the French-Hungarian bilateral cooperation the idea was born to organise a working action on 3DVAR (as it was done in September, 1999 for diag.pack) in Budapest. The main objective of the workshop was to install and adapt the 3DVAR (131) configuration of ALADIN on the Origin 2000 machine (recently having 12 processors in it) of the Hungarian Meteorological Service. Maria Siroka and Claude Fischer were invited to take part in this action.

This workshop was held parallel to the 2 studies in Toulouse by Wafaa Sadiki and Adam Dziedzic, respectively on the tuning of the Jo/Jb ratio and the treatment of the E-zone. Claude Fischer kept close contacts with the two "stagiaires" during the work.


1. Preliminary work

Cycle AL12 has been provided for installation in Budapest. The cycle is already operationally used for fullpos and dynamical adaptation at Météo-France. Raw clearcase branches were downloaded, so that the version installed does not match completely the export version. In particular, the bugfix for nhs/3tlsl is not present. Otherwise, the installed code was bug-free and could be quite rapidly used for the installation (work of Gabor Radnoti). Wafaa Sadiki provided the scripts and namelists as a basis for the work.

The work done by Gergely Boloni and Andras Horanyi provided from the scratch the necessary statistical files, which proved to be of good quality for the porting effort.


2. Scripts, Namelists

Namelists and scripts already used for research in Toulouse have been provided, both for single and full-obs experiments. It turned out that the maintenance of a single script for E002/E131 doing every possible job sequence is difficult, since bugs were still found in the scripts while porting. Thus, the maintenance and validation in Toulouse will be done with a duplicated set of scripts+namelists: one for single-obs, one for full-obs, in the near future.

Some namelist cleaning was done, especially removal of ARPEGE features such as NAMNMI, NAMLEG.

The general feeling is that the proper maintenance of scripts for 3DVAR is both a crucial and a time consuming activity. It is not clear whether the ALADIN community should try to stick to a common set of scripts over all its centers (possibly diverging quickly from ARPEGE scripts), or whether each center remains in charge of its own environment. The second solution will probably impose itself for the time being. For namelists, a common set of files is however wished.


3. Installations from the general point of vue

A very good first installation of the source was already done by Gabor Radnoti before the start of the workshop, so that the practical implementation of 3DVAR could begin promptly. However, several difficulties have shed some light on the relatively large efforts required by 3dvar, in contrast to the forecast version E001:

- need for a consistent CMA installation (OLD_CMA_WRITE)
- a number of contradictions with the ecmwf-born code due to platform mismatches (IBITS ?, GRIBEX, MPI, REFTIME)

- uncomplete tov22 library.

(A more detailed technical description is available on request.)


4. Debugging and validation of 3DVar

4.1 VALIDATION

4.1.1 SINGLE OBS EXPERIMENTS

The first validation of the installation of assimilation configurations on SGI was made via single observation experiments. Setup of the experiment was the same as used in Toulouse. The script was updated, now it contains the possibility to run fullpos to model levels (for the visualisation by CHAGAL, or possibly later in vertical cross-sections). Background error statistics for ALADIN/HU domain were provided by G. Boloni and A. Horanyi.

Both shared memory and distributed memory versions of single obs were running correctly and gave the same results (cost function values). The only exception is, that in the shared memory the JO in the screening is two times the Jo from the distributed memory run (but this problem is an old one and also apparent in Toulouse).

Figures of the single-observation experiments can be obtained on request.

4.1.2 FULL OBS EXPERIMENTS

Experiment with the observation file containing SYNOPs and TEMPs was made for the date 2000/06/06 00 UTC (file was created in Budapest and processed by CANARI - see later for deeper explanation).

For SCREENING, shared memory version and distributed memory version using one processor gave identical results (just Jo(shared_mem)=2xJo(distributed mem), i.e. all the observations and their contributions are counted twice in SM).

For minimization, the cost function slightly differs between SM and DM runs. The initial Jo is the same for the first 2 iterations, then it starts to diverge. The biggest difference after 40 iterations is on the last 3 digits.

4.1.3 SGI/O2000 vs. VPP5000 run

For the validation of the installation of assimilation configurations on SGI/O2000, the cross-comparison of the results of the screening and of the minimization job between the SGI and the "reference system" - VPP5000 in Toulouse was made.

Reference date was 2000/06/06 00 UTC. The first guess was the 12h ALADIN/HU forecast. The observation file was created in Budapest. It contains SYNOP and TEMP observations, and it has passed CANARI to initialize all necessary values.

Screening: Some small differences were encountered. The Jo cost function have very similar values on both platforms: For the numbers of rejected observations, the total amount was similar, but not the reason for the rejections.

Minimisation (e131): The minimization job comparison was not done because of non-compatible representation of the integer values in ALADIN installation on both machines. On VPP, integers are defined as 4 bytes, but on SGI they are considered to be 8 bytes long. As a consequence, the external STABAL files (in binary format) created on SGI (with 8 bytes integers) were not properly read on VPP (which tried to read them into 4 bytes variables).

There is an option to redo the cross-comparison of e131 on NEC SX4 in Prague.

4.2 PROBLEMS, OPEN ISSUES

4.2.1 PROBLEM WITH LBGOBS

During installation a problem was spotted in the unproper setup for satellite data (setup below SURAD routine in case LBGOBS=.TRUE.).

Therefore we have decided to use LBGOBS=.FALSE. (in NAMVAR), however this solution will not be proper in case the satellite data are to be used, so this problem should be later investigated.

4.2.2 PROBLEM WITH LOCAL DATA

The observation input files are created from the local SYNOP and TEMP database using MANDALAY software. But those files were not suitable for the screening (for unknown reason, all data were rejected, according the listing, they had too big observation error or/and they were over the sea). If we use the LACE observation file from Prague (this is partly created in Toulouse after ARPEGE screening and completed in Prague with SYNOP data, then passed to CANARI quality control), there were no problems in screening run, observations were processed.

There was a suspicion that there are some uninitialized values in the initial locally created obs file, so we tried to set them (observation error s_o and the station pressure) - see the explanation later - but without any success. (REMARK: we have seen in all our attempts that we have never managed to set properly the s _o for geopotential. After visualization of the obs-files this value was always uninitialized after screening, although we have set it in the input file.)

But if the obs file created in "standard" way passes the CANARI run, we can use it as the input for the screening. Obviously CANARI is able to initialize the missing values properly, but screening is not. (Although it may seem to be strange that we perform screening - what is variational quality control - on the data which were already used in another configuration, this was the only technical way we have found to overcome problems with rejected local data). This problem was reported to Toulouse.

4.2.3 LOBSTL PROBLEM

The fact that 3dvar is still a young model configuration was strikingly underlined by the finding of a bug for the case where LOBSTL=L131TL=.TRUE. It was found that the minimisation per se is performing well in both LOBSTL=.F. and .T. However, in the latter case, a bug produces wrong output files POS1/POS2: the mean wind is missing from the written wind field, so that POS1/POS2 files are presently useless for forecasting purposes.

Finally it is noted that the surface CANARI analysis after 3DVAR altitude analysis was not yet tested.


5. Final discussions

5.1. NMC STATISTICS

The plans basically concern the Budapest work:

- make a thorough study of the properties of the NMC stats with respect to conventional/lagged, time window, validating time. This study will tackle both predictability aspects (how does the ALADIN forecast error build up ?) and clarify which type of statistics can be used for 3dvar. The work will be performed through spring/summer/fall 2000 by Gergely Boloni, student at Eotvoes Lorant University.

- make basic validation of 3DVAR, using the conventional NMC stats. Firstly, single obs cases should be tested, then real cases (fall/winter 2000)

Generally speaking, it is clear that a decision will have to be taken in early 2001 on the type of statistics that have to be used in ALADIN 3DVAR. The choice between conventional, large scale stats and lagged, mesoscale ones is crucial for the definition of the cycling strategy in data assimilation context.

5.2. CASE STUDIES

In addition to the preliminary cases that would be tested in Budapest, both Toulouse and Prague will start to run 3dvar analysis and subsequent forecasts on specific cases. Prague can concentrate on 1 or 2 cases, and compare the conventional and lagged stats behavior.

Once results from the DFI-blending double suite in Prague are official, considerations for using blended data as first guess in the 3dvar could start. Maria Siroka could then firstly assess the impact of blended data in the innovation vector, and secondly , if needed, recompute NMC stats from those data (note that in the case of lagged stats, a new type of "lagged/blended" forecasts would have to be performed, where coupling data would have to be blended instead of ARPEGE analysis). Wafaa Sadiki's work on the a posteriori evaluation of 3DVAR consistency will give some input for this topic as well.

Toulouse will also produce case studies. There is presently already some work started on the impact of the DFI initialization on the analysis increments (Adam Dziedzic). A comparison between Prague and Toulouse cases could give some input on the sensitivity of 3DVAR with respect to the amount and type of observations, and with domain orography and size.

Systematic analysis+forecasts experiments are also planned in Toulouse, without data assimilation cycle, to obtain a first evaluation of the 3DVAR with respect to dynamical adaptation.

In 2001, Budapest would then join this common effort on case studies and 3dvar evaluation.

5.3. NOWCASTING

Since the most important part for the nowcasting application, namely the surface analysis, is still an optimal interpolation, the potential use of 3dvar here is expected to be marginal for the time being. Thus, we do not consider nowcasting to be an issue at short term.

5.4. DECISIONS FOR EXCHANGE OF INFORMATION

It was noticed that the above described work is subdued to some "kick-up" decisions concerning:

5.5. PROGRESS PLAN

June 2000: based on the work of Wafaa Sadiki and Adam Dziedzic, decisions on E-zone treatment and REDNMC coefficient

July 2000-December 2000: in Toulouse and Prague, case studies. In Budapest, systematic review of NMC stats and preliminary validation of 3DVAR on SGI.

Late 2000-first semester 2001:


Acknowledgments

The participants of the 3DVAR workshop in Budapest are grateful to Gabor Radnoti for providing a stable working ALADIN cycle and helping in finding the remaining bugs for 3DVAR. We would like also to thank Waafa Sadiki for providing the initial scripts and namelists for our work.




Home