You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

The MARS system is based on a client/server architecture, which makes it more flexible and adaptive to changes in a complex environment like ECMWF's.

The interaction between clients and servers is based on MARS requests. Clients send MARS requests to a server which looks for the data online or off-line, depending on the capabilities of the given server. If it fails to satisfy the request, the client will contact another server, according to a list of pre-configured servers.

Clients

The MARS client is a C program linked with ecCodes and the EMOSLIB library (which contains the GRIB interpolation software). The MARS source code is also embedded in other applications, such as Metview.

Access at ECMWF

MARS can be executed either in batch or interactive mode. Usually, clients issue requests from:

  • Workstations and servers, suitable for most retrievals
  • Supercomputers, retrieving data to be used as input for models
  • Metview, for interactive/batch visualisation/plotting and manipulation

It is recommended to use workstations or workstation servers for data retrieval instead of the supercomputers. This avoids unnecessary idle time when data has to be read from tape.

Member States/Co-operating States access

Most of the access from Member State users comes via the ecgate system, by logging in or submitting batch jobs to ECMWF's computers.

Moreover, the MARS client software is also available to access ECMWF's MARS system remotely by installing it at Member State sites. It removes user's need to login. Access and transfer of the data is transparent to the user, although data transfer may be slow. In addition, it is possible to create secondary cache systems at Member State sites in order to minimise remote access and transfer for popular data.

Servers

Details about the architecture of the MARS server are given in a separate article. MARS has evolved since this article was written back in 1999, e.g., software developed at ECMWF has replaced ObjectStore as metadata manager, but the general architecture is still valid. In 2003, the MARS contents were migrated to the High Performance Storage System (HPSS) tape management software, which replaced Tivoli Storage Manager (TSM, previously known as ADSM).

The various servers are described below.

Main Archive

This is the core of the MARS System and consists of the following hardware and software:

Hardware 

  • Dedicated multiprocessor servers
  • Several Terabytes of disk space, used for temporary storage before data is written to tape and for caching purposes while data is read from tape
  • A set of automated tape libraries

Software 

  • A set of applications written in C++ linked with the EMOSLIB library
  • High Performance Storage System (HPSS), which controls the tape, tape drive and robotic related activities.

Some characteristics of the main archive system such as request scheduling and data collocation are very important for users in order to optimise data retrieval.

Fields Data Base (FDB)

This is where models running at ECMWF write their outputs. It contains data produced by the most recent cycles.

Depending on the configuration and disk resources, it can contain up to several days of operational data and more recent research experiments. Also, there are many Fields Databases, several per supercomputer or server able to run ECMWF's models.

It is meant to provide very fast access as all the data resides online. This makes it very suitable for model input data retrieval or last cycles data access.

Reports Data Base

The RDB Contains online observations received via ECMWF's acquisition system. This system has been interfaced with MARS to allow real-time observation access. Access to this server is meant for monitoring and operational archive purpose only.

Interaction client/server: request execution

The MARS client has a configuration of servers to access when looking for data. The following is a schematic view of actions the MARS client performs per request:

  • Checks the request syntax with the help of the MARS language
  • Prints the request to be processed and the number of fields expected
  • Queries the cache system (if configured)
  • Queries all supercomputers' Fields Data Bases (if the data are not cached)
  • Queries the main archives (if data are not in the FDB)
  • Transfers the data to the client and post-processes (if needed)
  • Caches the data (if the cache is present)
  • Reports on the result

Note that post-processing is done while the data is being transferred and before writing to disk.

MARS migration to GRIB API

The MARS client using GRIB API as its data decoder instead of GRIBEX has been made the default on all major platforms on 10 May 2011. To retrieve data in GRIB 2 format the use of this version is essential.

The MARS application has been migrated to use GRIB API as its data decoder instead of GRIBEX. This migration has two components:

  • Migration of the server. For this work, every field in the archive with different encoding had to be tested, to ensure that MARS/grib_api (MARS using GRIB API as its data decoder) indexes the data in the same way as MARS/gribex (MARS using GRIBEX as its data decoder). Most MARS servers have already been migrated and implemented at the end of 2010.
  • Migration of the client. This work involved migration of the following codes:
    • migration of the MARS client source code
    • migration of the interpolation software (libemos)

Because the interpolation software (libemos) uses extensively GRIBEX, many parts of the code had to be modified. Please see Field interpolation software for more information.

For the migration of the MARS client we have tried, as much as possible, to avoid changes to the GRIB headers or the results. Extensive tests have been run and comparisons between interpolations of MARS/gribex and MARS/grib_api have been performed using

grib_compare -P -T 2 ...

where the options have been chosen to skip differences smaller than twice the packing error. However, in some cases we have been unable to produce the same results. At the same time, we have found features of libemos/gribex (libemos using GRIBEX as data decoder) that have been corrected in libemos/grib_api (libemos using GRIB API as data decoder). Please see below for more details on known differences between MARS/gribex and MARS/grib_api.

MARS client for installation in Member States

For a grib_api MARS client version 20110322 or higher should be used, which needs to be compiled with libemos 381 (or higher) and grib_api 1.9.9 (or higher), which can be freely downloaded.

Known differences between MARS/gribex and MARS/grib_api

Interpolation of wave Mediterranean fields

The interpolation of wave fields has been re-written. The new routine correctly recognizes sea points on the southernmost, last latitude for limited area wave fields. This has been verified by the wave experts. Libemos/gribex has not been fixed.

Bitmaps and frames

MARS/gribex doesn't initialise bitmaps (which are also used for frames), while MARS/grib_api initialises bitmaps to 0. Since bitmap arrays are filled differently, for bitmaps that do not fit a multiple of 8, the remaining bits can have different values.

One can detect this difference by running grib_compare, which produces the following output:

-- GRIB #5 -- shortName=10u paramId=165 stepRange=120 levelType=sfc level=0 packingType=grid_simple gridType=rotated_ll --
[bitmap] byte value 5888 of 5889 are different: [e5] and [e0]

Different behaviour in MARS (not necessarily interpolation)

streamGRIBEXstream=da/wv/ef/...
GRIB APIstream=oper/wave/enfo/...
stream=mnthGRIBEXstream=mnth,date=20110100
GRIB APIstream=mnth,date=20110101
computeGRIBEXcompute repacks using simple packing
GRIB APIcompute repacks whatever was the original packing

  File Modified
No files shared here yet.

  • No labels