L2 Project

Project logo
The Institute of Applied Physics (IFAC-CNR) was involved as prime contractor of a study financed by ESA (European Space Agency) and devoted to the Level 2b analysis of the MARSCHALS measurements. In this study, which is the final segment of the MARSCHALS project, algorithm and codes are developed and used for the level 2 analysis of the measurements made by this instrument during a tropical campaign. The codes are also used for a theoretical retrieval study that provided useful guidelines about the preferred measurement and retrieval configurations as well as about the feasibility of the measurements.

The MARSCHALS L2b project had the following objectives:

  1. to develop algorithms and codes for simulation and retrieval of MARSCHALS data,
  2. to consolidate and validate these codes and perform an error analysis on theoretical basis,
  3. to analyse and validate all data taken from campaigns during the period of the study,
  4. to exploit scientifically the MARSCHALS data obtained in this set of campaigns.
The results of the analysis confirm the capability of MARSCHALS of performing observations of atmospheric minor constituents in presence of clouds that are opaque to middle infrared radiation.

With the same code the analysis is also made of the measurement of the REFIR-PAD instrument which also operated at a tropical latitude and provided information about tropospheric water vapour complementary to the one obtained by MARSCHALS.

Codes for the Level 2 analysis were already been developed at IFAC for other instruments. These codes are:
  1. the Optimised Retrieval Model (ORM) that is the scientific code used by ESA for the development of the operational code for MIPAS/ENVISAT,
  2. the SAFIRE code that is used for the analysis of balloon-borne and aircraft-borne measurements performed with the SAFIRE-A (aircraft) and with the SAFIRE-B (balloon) instruments. SAFIRE A and B are FTS instruments that operate in the sub-millimetre region.

However, the new features of the input data and of the scientific requirements, recommend for MARSCHALS the development of a dedicated code. The development of the code took into account requirements due to:

  • Characteristics of input data (spectral region, instrument and platform).
  • Scientific requirements of output data (study of the UTLS region).
  • Correctness of the atmospheric model.
  • Correctness of the instrument model.
  • Numerical accuracy.
  • Flexibility of the retrieval process in order to model unexpected experimental conditions.
  • Measurement characterisation (analysis of both measurement and retrieval errors).
  • Feasible computing time.


Table 3 provides a summary of the features of the MARSCHALS code in comparison with ORM and SAFIRE codes. A tick indicates either existing or planned features.

Table 3 - COMPARISON OF MARSCHALS CODE WITH EXISTING ONES
  ORM SAFIRE MARSCHAL
Main features      
Scientific   v v
Operational v    
Micro-window (mW) approach v v  
Full band analysis   v v
Retrieval of species with marginal information   v v
Interest in information content assessment     v
       
Instrument model      
ILS (Instrumental Line Shape) v v v
Apodization v v  
Calibration-ILS interaction   v  
FOV (Field Of View) v v v
mW dependent spectral error (noise) v v v
Frequency dependent spectral noise   v v
Correlation of spectral error (noise)

 

(? domain)
v v  
Correlation of spectral error (noise)

 

(z domain)
    v
Hot and cold load     v
       
Atmospheric model      
Platform inside atmosphere   v v
Up-looking geometry   v v
Variable platform altitude during LS sequence   v v
Refraction in the atmosphere v v v
Scattering and Polarisation     v
Horizontal gradient     v
Systematic errors used for mW determination v v  
Systematic errors used for FM VCM     v
Irregular frequency grid v   v
Altitude dependent frequency grid     v
Look up tables v    
Non-LTE (Non Local Thermal Equilibrium)      
       
Retrieval choices      
Retrieval at tangent altitudes v v v
Retrieval at user defined altitudes   v v
Use of frequency-mask for retrieval v    
Exploitation of up-looking geometry
(i.e. geometries which pointing angle is above the horizontal direction)
  v v
Sequential retrieval of species v v v
Simultaneous retrieval of species     v
Retrieval of pointing and temperature v   v
Retrieval of horizontal gradient profiles     v
Retrieval of band-dependent continuum v v v
Retrieval of slope of continuum      
Retrieval of curvature of continuum      
Global fit v v v
Regularisation v v v
Optimal estimation     v

As a recall to the adopted general strategy the following points should be mentioned:

  • a modular structure that allows a relatively easy change of procedure and use of alternative models has been adopted;
  • computing time optimisations has been pursued with options in the adopted approximations and with tuning of variable discretisation, but computing optimisations that increase the complexity of the code has been avoided;
  • coding rules and coding conventions have been defined aiming at improving code portability among different environments, code readability and understanding, especially considering that more than one person wrote the code;
  • a tool for automatic extraction of technical documentation directly from the source code has been adopted for commenting and documenting header files, modules, routines and interfaces in general. The main advantage of this mechanism is to ensure a consistent and up-to-date code documentation at any time;
  • all project components, libraries as well as validation test suites (test applications and test data) and documentation has been centralized and managed by a Code Revision Control mechanism in order to ensure a coherent and always up-to-date version of the system. This mechanism allows in particular to easily access early versions of the software, making one able to backtrack problems on previous versions;

Test and validation procedures have been part of the software development process and ensured a rapid and early discovering of software problems.