(hPa)
The operational ALADIN models
1. Present status of operational ALADIN suites, and plans
2. Changes in the operational version of ARPEGE along the first half of 2002
(more details samuel.westrelin++at++meteo.fr)
17 January 2002 : "Increase of resolutions" (new design of the operational suite)
· Improved stability and reproducibility of the physics
· Retunings
imposed by the changes of resolution
· bugs introduction !
(in convection)
· Increase of vertical resolution :
from 31 to 41 vertical levels
highest level : from 5 hPa to 1 hPa
lowest level : from 20 m to 17 m
Old and new distributions of vertical levels, compared to that of the ECMWF model
| P (hPa) |
|
· Increase of spectral resolution
the grid does not change
the orography does not change
the spectral resolution is increased by 50% for prognostic variables ("linear" truncation, also called "linear" grid)
· Changes in 4d-var
increased vertical and spectral resolution
less incrementality : innermost loop suppressed, considering the ratio extra-cost / efficiency, semi-Lagrangian advection for the propagation of increments in the TL/AD models
--> The new configuration is the following :
28 March 2002 : "Bug correction" (correction of the bugs introduced on 12/11/2001)
· Corrections in the vertical diffusion and anti-fibrillation schemes
· Retunings
14 May 2002 : "Safer physics" (a few improvements in physics)
· Stronger safety thresholds in the convection scheme
· Improved anti-fibrillation scheme
The vertical variations of the coefficient controlling the anti-fibrillation scheme are limited, with a maximum equal to the value at the lowest level, in order to avoid the previous (sometimes very strong) oscillations.
Latest parallel suite : "New observations"
· Use of raw AMSU-A data, use of profilers data, use of temperature observations at all levels for TEMPs (instead of a combination of Z and T), and some technical changes in pre-processing
still some technical problems : failures in the analysis step, and improvements mainly after 48h ... The parallel suite stopped at the beginning of July without moving to operations. I was relaunched afterwards.
3. Operational version in Austria
(more details thomas.haiden++at++zamg.ac.at)
Early in 2002, the operational ALADIN-VIENNA suite and all its post-processing applications were ported from the DEC-alpha single-processor machine to an SGI Origin 3400 computer with 20 processors (500 MHz). On the new platform, the operational 48 h integration run (144x128 gridpoints, 37 vertical levels) including DFI takes roughly 10 mn.
Concurrent with the switch of platforms, we moved from AL11 to AL12/Cycora_bis operationally. AL15 has been installed on SGI and will be run in parallel mode for some time before becoming operational later in 2002.
4. Operational version in Belgium
(more details olivier.latinne++at++oma.be)
No significant change since the last Newsletter. See part 1 for the present status and plans.
5. Operational version in Bulgaria
(more details andrey.bogatchev++at++meteo.bg)
The New Operational Suite of ALADIN-BG
The new operational suite of ALADIN-BG was developed during the second quarter of this year. For that purpose the export_AL12_04 package was used. Also the new climatological files were created for the integration domain.
The distributed memory version of the code was preferred. It is running on a single processor station without initialization of MPI. On Sun Hyper 60 the averaged time for integration job is 90 minutes. The increased integration time is balanced by the introduction of a new system for visualization of forecast fields. The last version (1.8 SL10) of GRADS (Grid Analysis and Display System) was implemented on our station. It has some new features like producing gif images in batch mode, which gave us the possibility to decrease almost twice the execution time of the visualization part. The price for this decrease is a larger size of the gif files.
There are significant changes in the graphical presentation of forecast fields.
1. All pictures are displayed with colour bars.
2. For 2m temperature, a fixed colour palette is used.
3. The wind is displayed with barbs, coloured with the temperature of the corresponding level.
4. The precipitation fields are displayed in shaded format with the value of the maximum of precipitation printed at the corresponding grid point.
5. The cloudiness is presented in gray scale.
Figures 1-4 show the images for 2m temperature, 6 hours precipitation geopotential height and wind on 950 hPa.
The last part of the new operational suite is related with the production of specific files for end-users like: National Company for Electricity, wind wave model, oil-spill model and MEDIA model.
The new operational suite was run in pseudo-operational mode more than one month and there were no crashes, or some other problems.
We plan to implement it in full operational mode on 16 of July.
Figure 1
Figure 2.
Figure 3.
Figure 4.
6. Operational version at Croatian Meteorological Service
(more details bajic++at++cirus.dhz.hr)
Transfer of operational AL12 suite on the SGI machine is finished. Modification of scripts and new visualization procedures have been done.
ALADIN is running operationally twice a day on the Croatian HRv8 domain that contains 144x120 gridpoints (127x109 without the extension zone) with an horizontal resolution of 8 km and 37 vertical levels. The surface wind field from the integration on the Croatian domain with a 8 km horizontal resolution is dynamically adapted to orography with a 2 km resolution.
7. Operational version at Météo-France
(more details samuel.westrelin++at++meteo.fr)
Similar changes as in ARPEGE along these 6 months. The new (linear) spectral resolution is E149×149.
The main worries were related to the so-called "Aladinades", i.e. spurious, and strong, small-scale precipitation patterns, also noticed in other ALADIN models (e.g. the Adriatic storm cases studied by Zoran Vakula et al. in ALADIN-LACE, see the ALADIN report for RC-LACE).
8. Workstation version at Météo-France
(more details jean-marc.audoin++at++meteo.fr)
Nothing new since the last Newsletter.
9. Operational version in Hungary
(more details horanyi++at++met.hu)
The most important news for the Hungarian Meteorological Service was the installation of the new IBM Regatta server at the beginning of January. The main characteristics of this computer are as follows (it is noted that ECMWF purchased the same kind of machine with building blocks of such Regatta servers) :
- IBM p690 Regatta server with 32 processors (1,3 GHz POWER4 processors),
- Architecture: Symmetric Multiprocessing (SMP)
- Peak performance: 5,2 Gflops/processor
- Memory: 1 Gbyte/processor
- Disk capacity: 364 Gbyte
To give a rough idea about the performance of our new computer it can be said that a 48 hours forecast for the ALADIN/LACE domain (216 × 240 points with 31 vertical levels) takes less than 8 minutes for the AL15 version of the ALADIN code.
After installation the first and most important step was the repetition of the benchmark tests provided by the manufacturer. After its completion the official handover ceremony was organised on 18th of February, 2002 in the presence of the Minister of Environment.
The migration work was continued afterwards and until now the most important configurations were put into work: ee927 (lancelot), 001 (morgane), Full-Pos (off-line), 002 (screening), 131 (3d-var). The latter configurations are using the ODB database. Additionally several auxiliary procedures were written for data handling, different interfaces and other important algorithms needed for the operational suite.
As far as the new operational suite was concerned the first objective was to reproduce the same version as it was the case for our Origin 2000 machine. Therefore the differences in the new suite are rather minimal and restricted to the new version of the code (old : AL12, new : AL15) and to off-line Full-Pos (in the SGI machine on-line Full-Pos was used). A one month intermediate period was considered while the model was running on both platforms and then at the beginning of June the new suite was put into operations on the Regatta server. It is noted here that the nowcasting analysis (CANARI-Diagpack) was and will be kept on the Origin machine (this machine will primarily serve the interest of the nowcasting applications).
After the stabilization of the operational suite, in the near future the following main tasks are planned to be performed :
- Migration of the remaining auxiliary procedures to the Regatta machine.
- Completion of all the steps required for the 3d-var data assimilation scheme.
- Installation and tuning of the loadleveler software for effective resource management.
- Preparations for direct coupling from ARPEGE (with the disappearance of ALADIN/LACE operational model version) together with a new domain definition (higher resolution and extended domain).
As a summary it can be said that significant work was carried out around the new machine of HMS. At the end of June the new operational suite was stabilised on Regatta and the work is going to be continued towards 3d-var and single-nesting strategy (direct coupling from ARPEGE).
10. Operational LACE application
(more details vana++at++chmi.cz)
1. Evolution of the ALADIN/LACE application.
The ALADIN/LACE suite was switched to 37 vertical levels :
07/02/2002 at 12 UTC network time for the production run and at 06 UTC network time for the assimilation cycle : increase of the vertical resolution from 31 to 37 levels.
This switch was, as usual, preceded by a parallel test. A slight improvement of all parameters near the surface was due to a better resolution in the Planetary Boundary Layer (PBL) in the 37-levels version. Contrary to ARPEGE switching to a 41-levels version, the very high altitude vertical levels were not retained in ALADIN/LACE : the dynamics of these upper-stratospheric levels was likely to cause more problems than bringing in some benefits and in contrast with the global model there is no urgent practical need to keep them. The same applies to the linear grid version, not retained in ALADIN/LACE while applied in ARPEGE and ALADIN/FRANCE : the tests performed in summer 2001 were not convincing enough to motivate the use of the linear grid, which would have brought a non-negligible impact on the telecommunications and archiving costs due to increased size of model files. The switch to 37 levels was coordinated with Members regarding their national applications. A detailed description of the necessary changes made by the Prague Team Leader (PTL) ensured the smooth switch to 37 levels in the nested ALADIN models.
Impact on the forecast : weak improvements in the scores of all parameters within PBL.
Technical impact : prolongation of the computational time due to more levels and also to a shorter timestep which has to be used due to the increased vertical resolution. Now the +48h GRIB bulletins are ready for dissemination around 3 h 30 mn about after the network time (the timeliness constraint is 4 h after the network time). Also the boundary conditions and history files issued from ALADIN/LACE increased their size.
The ALADIN/LACE application switched to a higher temporal frequency of the Lateral Boundary Conditions update on :
05/03/2002 at 12 UTC network time for the production run and at 00 UTC for the assimilation cycle : the update frequency of the Lateral Boundary Conditions (LBC) was increased from 6 hours to 3 hours.
This change was motivated by the increased computational time needed for the 37-levels version, which created a time window to repatriate more boundary-condition files from ARPEGE. At the same time it is a well known fact that a higher update frequency of LBCs allows a better passage of the information from the driving to the coupled model, hence the aim was not only to re-balance the computer and line speeds. At the same time the quadratic time-interpolation of LBC data was kept despite a recent rumour that the quadratic time interpolation in combination with the increased (3h) frequency might cause problems. PTL has made a careful check on that issue and proven it to be only a rumour. In addition, a parallel test was made and the better ability of capturing the signal from ARPEGE was seen again on the recent "Hana" Storm case (storm of 26th February 2002 hitting Danish and German coast).
Impact on the forecast : slight improvement of the mass field scores; known beneficial impact for extreme weather cases such as T1 French Storm (26/12/1999), Hana Storm (26/02/2002).
Technical impact : increase of the downloading time of the LBC files from ARPEGE. In order to keep a balance with the speed of computations, the sending of RETIM charts on the back line to Toulouse was delayed till the end of the downloading task: this eliminates a problem of slowing down the reception of confirmation packets when downloading the LBC files. There is no technical change on the downstream of products to Vienna.
2. Parallel Suites & Code Maintenance
The Prague Team launched the following parallel tests to assess the impact of different modifications :
- Suite ABM : "test of 37 vertical levels" . The suite showed slight improvement of all fields near the surface. It became operational on 07/02/2002.
- Suite ABN : "repeated CYCORA-ter after bug correction". There was a hope that the bug found in the vertical diffusion parameterization scheme could explain the bad scores of the suite ABL for the winter type of weather. The suite was run for the same period like the suite ABL. Unfortunately the scores were as bad as before.
- Suite ABO : "3h quadratic frequency coupling" . This suite was meant to check the results obtained back to 1997 when the increased temporal resolution of the lateral boundary conditions (LBC) was tried for the first time and also when the quadratic temporal interpolation was compared to the linear one. Indeed, the signal is almost neutral except for a very slight improvement in the geopotential score. The increased frequency of the update of the LBC confirms to be important when there are fast moving cyclones; otherwise it does not play a too important role. The suite became operational on 05/03/2002.
- Suite ABP : "3h linear frequency coupling" . As mentioned above, there was a rumour saying that the quadratic temporal interpolation can produce some pathological behaviour with the 3h frequency update of the LBC and that the use of the linear interpolation is better in such case. To be quite sure that it is only a rumour (there was no theoretical evidence), a parallel suite was launched. There was no signal in the scores compared to the quadratic interpolation. The two techniques were compared for the extreme cases. There the quadratic interpolation performed better.
- Suite ABQ : "repeat of CYCORA-ter package test but with the mixing length of CYCORA-bis". This suite was run again on the same winter type of weather as the ABN suite. It proved that the tuning of the mixing length was one of the crucial factors influencing the scores. With the old tuning the CYCORA-ter physics performed almost as well as the CYCORA-bis physics for the cold continental weather. It remains to test also the spring and summer situations to assess the qualities of the CYCORA-ter package.
- Suite ABR : "slantwise convection & the latest CYCORA-ter". This suite combines several changes in the physics package: it contains all the latest correction and improvements of the CYCORA-ter, it keeps the CYCORA-bis mixing length, it contains a modification of the convection scheme having the same effect as the slantwise convection parameterization. The suite is not yet evaluated.
The results of parallel tests may be consulted on / pages.
- Back-phasing of physics and problems with ODB
As mentioned above, the last version of the physics was back-phased to cycles AL12/CY22T1 in order to allow its operational application once the tests are completed. This back-phasing is mainly due to the problems related to the port of the ODB software, which is necessary for any configuration using observations with cycles AL15/CY24T1. Hence the difficulties with ODB block the introduction of AL15 into operational exploitation. While ALADIN/ARPEGE/IFS is reasonably hard to port, ODB itself is not finished nor documented. The porting process requires modifying undocumented code that heavily uses techniques in ways long deprecated by computer science community, such as the C pre-processor. The code is big endian dependent and since the data files are not documented either, it is impossible for anyone else that the ODB author to port it to a little endian platform, such as popular PCs. The source tree is not organised and is hard to build. In summary, we had three skilled system administrators working on ODB for 8 weeks in total, and those were not yet able to get it running on any of our platforms.
- Bug in reading the spectral arrays
Other maintenance issue concerned the bug in reading spectral arrays and affecting the spectral norms of vorticity. The problem was located with ALADIN cycle AL15_op1 but also cycle AL12_op6 on NEC-SX4 super-computer. However, the same problem was reported on other platforms, perhaps except the VPP.
Solution for AL15_op1 and AL12_op6 :
Beginning state :
1 processor
SPECTRAL NORMS - SURFACE PRESSURE 0.114791074605369E+02
LEV VORTICITY DIVERGENCE TEMPERATURE HUMIDITY KINETIC ENERGY
AVE 0.493188076536417E-04 0.421293426850173E-04 0.256429672957490E+03 0.313741881325838E-02 0.613511922401997E+02
1 0.123230803794318E-04 0.280337525477330E-05 0.248872736033203E+03 0.204345281969550E-05 0.114191583165689E+03
2 0.706968502499767E-05 0.445577890475627E-05 0.227309477147068E+03 0.296383928915048E-05 0.433114385866733E+02
3 0.558903141344059E-05 0.557412052443573E-05 0.221494219308932E+03 0.115399480362638E-04 0.235739446655111E+02
........................ ..................... ..................... ..................... .....................
31 0.240905639045916E-04 0.269483984823826E-04 0.288490086380765E+03 0.875349092093968E-02 0.296433232741700E+01
2 processors
SPECTRAL NORMS - SURFACE PRESSURE 0.114791074605369E+02
LEV VORTICITY DIVERGENCE TEMPERATURE HUMIDITY KINETIC ENERGY
AVE 0.493166015655407E-04 0.421293426850173E-04 0.256429672957490E+03 0.313741881325838E-02 0.613501380862824E+02
1 0.122546916483002E-04 0.280337525477330E-05 0.248872736033203E+03 0.204345281969550E-05 0.114158904394253E+03
2 0.706968502499767E-05 0.445577890475627E-05 0.227309477147068E+03 0.296383928915048E-05 0.433114385866733E+02
3 0.558903141344059E-05 0.557412052443573E-05 0.221494219308932E+03 0.115399480362638E-04 0.235739446655111E+02
........................ ..................... ..................... ..................... .....................
31 0.240905639045916E-04 0.269483984823826E-04 0.288490086380765E+03 0.875349092093968E-02 0.296433232741700E+01
The differences are "only" in level 1 for Vorticity and Kinetic energy.
Changes in code :
1. cy24t1op1/setup/suspec.F90
instead of:
REAL_B :: PSPVOR(:,:),PSPDIV(:,:)
to use:
REAL_B :: PSPVOR(NFLSUR,NSPEC2)
REAL_B :: PSPDIV(:,:)
2. al15/include/suspec.h -> ../../cy24t1op1/interface/suspec.h
same changes in interface suspec.h
3. recompilation of all routines with changed interface suspec.h
elsirf.F90 su1yom.F90 cun3.F90 cva1.F90 edfi2.F90 rd801.F90 sim4d.F90 suecges.F90 suinif.F90 suvazx.F90 upspec.F90 suspec.F90
After this modification the norms are identical and independent on number of processors. Same for values in historical files. However this fix is temporary, before the true mistake is found (like missing interfaces or so).
- TUC: Transparent Use of ClearCase
This software was further improved by introducing the cc_depend command. The dependencies can be checked also through other projects.
More details on the parallel suites and code maintenance can be asked to : Filip Vana, Tomas Kalibera, Oldrich Spaniel
11. Operational version in Morocco
(more details radi.ajjaji++at++pioneer.meteo.ma)
ALADIN/Morocco status
Observations
Since last January, our BDM (Meteorological Data Base) became operational again after more than two months of hardware problems. Now it processes all observation types on an area between 0° N, 55° N, 40° W and 56° E. This area, which is the target for the expected ALADIN North Africa (NA) model, is very poor of conventional data especially in the Southern part. We decided to rely on satellite data, especially TOVS 120. Météo-France agreed to send us this observation type.
Concerning ODB, we are still in the process of porting all its components on IBM, but without good results for the while. We expect local assistance from Météo-France (Philippe Caille should come to Casablanca) and remote assistance from Sandor Kertesz.
Assimilation
ALBACHIR is still running CANARI operationally with the AL13 code version on IBM. But we expect to go soon to the Blendvar method, when ODB will be OK and when ALBACHIR will be run on the North Africa domain. It has been shown in a local study that Blendvar gives better scores compared to CANARI, Blending alone and 3d-var alone. Surface analysis will still be done by CANARI
We are waiting for ODB to be ported on IBM in order to begin a pre-operational suite based on Blendvar. This pre-operational version will also use TOVS 120 that will be received routinely from Toulouse.
Forecast
ALBACHIR is now running until 72 hours twice a day. We expect to extend the domain to the North Africa region by the end of September. This version will cover all Northern Africa and the Mediterranean sea (25 km of horizontal resolution and 41 levels : a grid of 180x300x41 points). We will keep an asynchronous coupling with ARPEGE, with a 12-hour delay. ALBACHIR NA will be used, among others, to couple a fine mesh version of ALADIN centred on Morocco (9km of resolution)
This suite, which will be coupled in asynchronous mode with ARPEGE, is already tested on single situations. It is ready to become operational when Météo-France will send us the corresponding coupling files. It is detailed in a separate paper.
Control and verification
A verification procedure, described in a separate paper, is running once a day to control ALADIN 24-hour forecasts against TEMP and SYNOP observation types. The first bias and rms graphs for June and July 2002 are available on our web site http://www.spn.meteo.ma/ . The verifala mailing list will receive these results very soon.
12. Operational version in Poland
(more details zijerczy++at++cyf-kr.pl)
See part 1 for the present status and plans.
13. Operational version in Portugal
(more details margarida.belo++at++meteo.pt or maria.jose++at++meteo.pt)
During this first half of 2002 not so many changes have been introduced on the Portuguese operational suite (AL12_bf_CYCORA_bis). New meteorological fields are now being post-processed for development and forecasting purposes.
14. Operational version in Romania
(more details banciu++at++meteo.inmh.ro)
See part 1 and the ALADIN report.
15. Operational version in Slovakia
(more details Olda.Spaniel++at++mail.shmu.sk)
OPERATIONAL ENVIRONMENT OF ALADIN/SLOVAKIA
COMPUTER CHARACTERISTICS
DEC Alpha Xp1000 (Compaq), EV6 processor DIGITAL UNIX V4.OD
DIGITAL F90 compiler, native C compiler
640 MB memory (will be upgraded on 1GB), 12 GB HDD
MODEL CHARACTERISTICS
size of the domain 862 x 646 km
domain corners SW : 14.69 E, 46.05 N - NE : 22.26 E, 51.07 N
number of points 120 x 90 (including E-zone)
horizontal resolution 7.18 km
vertical resolution 31 levels
time step 337.5 s
length of the forecast 48 hours
frequency of the outputs 1 hour
runs twice per day (00 UTC and 12 UTC)
mode dynamical adaptation
coupling model ALADIN/LACE (12.2 km resolution)
coupling frequency 6 hours
physics and dynamics the same as ALADIN/LACE
model version AL12_op6 (CYCORA_bis) operational, AL15_op3 ported
MODEL PRODUCTS
- surface parameters in map form (2m temperature, 2m Tmax, 2m Tmin, 2m relative humidity, 10m wind, precipitations, cloudiness)
- meteograms for 22 cities over Slovakia (our SYNOP stations)
- vertical cross-sections
- pseudo-TEMP
- ATPA - automatic text forecast from ALADIN for 22 Slovak towns (user configurable via web interface, distributed by e-mail / SMS)
- the area average precipitation for the main river catchments
- wind roses - use of CANARI configuration to determine surface wind characteristic within ALADIN/SLOVAKIA domain
- RODOS - selected meteorological fields for the dispersion model RODOS
16. Operational version in Slovenia
(more details neva.pristov++at++rzs-hm.si)
There was nothing new in operations but the activities for ITT for a new computer started in March 2002. The replacement of the old cluster is expected till the end of 2002, when AL15 will be put in operational use on a larger integration domain.
17. Operational version in Tunisia
(more details nmiri++at++meteo.nat.tn)
Most of the work during this period concentrated on the purchase procedures of computing equipments for the operational forecasting system. The INM invitation to Tender were formal. The technical choice has been done and we should conclude the purchase contract during the few next months. The expected date for a local implementation of ALADIN is December 2002.
Concerning the verification procedures we started last year, there is no commensurate advancement due to lack of required data.