PDAF-OMI, the Observation Module Infrastructure in PDAF3

PDAF-OMI (Observation Module Infrastructure) provides a structured and modularized approach to implement the observation handling for PDAF.

Here, we describe OMI in the context of the PDAF3. The documention on PDAF-OMI for PDAF2 is still available: PDAF-OMI in PDAF2

However, one can also implement the assimilation using PDAF's full interface without using PDAF-OMI, but this expert mode requires significantly more programming.

PDAF-OMI permits to implement the observation handling with a low number of user-provided routines. Each observation type is encapsulated in a Fortran module (referred to as 'observation module'). With this, the implementations of different observation types cannot interfere which each other. The code structure is motivated from object-oriented programming, but we avoid here the abstract level of object-orientation in Fortran. The modularization allows different developers to implement observation types without interfering with the implementations by others.

Main Components of OMI

The main components of OMI are

• Observation Modules
  One observation-specific Fortran module for each observation type
• callback_obs_pdafomi.F90
  PDAF can only call a generic call-back routine for the different functionalities, e.g. init_dim_obs_pdafomi or obs_op_pdafomi, see below. This file contains these generic call-back routines, in which the observation-specific subroutines of the different observation modules are called. Thus, the subroutines in this file are merely pass-through routines without own functionality.
• PDAF-OMI core routines
  These routines are part of the PDAF library and provide functionality for observation handling, localization, and observation operators

Figure 1 shows the call structure for the analysis step with PDAF-OMI. For the analysis step, the core routines of PDAF (green) call different user-provided call-back functions. Only the routines in the red box 'callback_obs_pdafomi.F90' are related to observations. PDAF-OMI is concerned with these routines and the observation modules (purple). The call-back functions shown in cyan are only used for domain-localized filters.

Figure 1: Call-structure of PDAF with OMI: (green) PDAF library with core and omi; (blue) call-back routines; (red) OMI call-back routines; (purple) observation-specific modules. The cyan color marks call-back functions for localization. If PDAFlocal is not used, there will be two additional routines g2l_state and l2g_state relating to localization.

With OMI, the functionality to handle observations is included in generic routines in callback_obs_pdafomi.F90 and observation-specific modules (purple obs_*_pdafomi in the third column in Fig. 1, denoted obs-module below). Based on the information initialized in the call-back routines, PDAF will perform further observation handling internally. There is one obs-module per observation type with contains these routines. For example, one can have one obs-module for the satellite sea surface temperature from one data provider and another one for sea level anomaly data. Important is that each of these obs-modules, which are further described below, is independent from the others. This allows us to switch between different combinations of observations ensuring that their implementations don’t interfere.

For each observation type, one needs to implement the follwing routines in the respective obs-module. For ensemble-based filters one needs:

• init_dim_obs
  Reads observations from a file and initializes all variables holding the information about one observation type.
• obs_op
  Applies the observation operator to a state vector. One can call an observation operator routine provided by PDAF-OMI, or one can to implement a new operator.
• init_dim_obs_l
  Calls a generic routine to initialize local observations (only for domain-localizated filters)

Only in the case of 3D-Varmethods, two more routines are required:

• obs_op_lin
  Calls a routine for the linearized observation operator (equal to obs_op if this is linear)
• obs_op_adj
  Calls a routine for the adjoint observation operator

The only 'real' coding effort will be in init_dim_obs because the other routines merely call a subroutine provided by PDAF-OMI. All functionality needed during the analyis step bases on variables that are initialized by these routines and is provided by PDAF-OMI. For each observation type, PDAF-OMI uses a data structure (Fortran 'type') that is initialized in init_dim_obs in the obs-module.

Since the actual operations are performed in the obs-modules obs_*_pdafomi, the generic call-back routines (init_dim_obs_pdafomi, obs_op_pdafomi, init_dim_obs_l_pdafomi) are reduced to pass-through routines. Thus, each of these routines contains only calls to one observation-specific routine from each obs-module. Because the generic call-back routines are very compact, they are collected into the file callback_obs_pdafomi.F90. This is mainly for convenience, because all these routines are now ‘in one place’.

The set of routines in callback_obs_pdafomi.F90 provide the observation handling for all data assimilation methods provided by PDAF. Thus, once the routines in an obs-module are implemented for a particular observation and the subroutine calls in callback_obs_pdafomi.F90 for this observation type are inserted, one can use this observation type with all of PDAF's assimilation methods.

Further documentation of PDAF-OMI

The documentation for implementing is provided on the following pages:

• The file callback_obs_pdafomi.F90
• The Observation Modules
• Observation Operators
• Debugging Functionality
• Implementing the analysis step
• Porting an existing implementation to OMI
• Additional functionality of OMI

Implementation examples

The PDAF package provides several implementation examples:

• /tutorial/online_2D_serialmodel
  This implementation includes three obs-modules. The two modules obs_A_pdafomi.F90 and obs_B_pdafomi.F90 are for observation at grid points, while obs_C_pdafomi.F90 uses an observation operator with bi-linear interpolation. In this case we have only implemented support for the global and the domain-localized filters, but not the LEnKF (see /models/lorenz96_omi for the example supporting all filters)
• /tutorial/online_2D_parallelmodel
  This implementation includes two obs-modules (obs_A_pdafomi.F90, obs_B_pdafomi.F90) for observations at grid points. One can compare these modules with those in online_2D_serialmodel_omi to see differences in the case of a serial model to those in a parallel model
• /models/lorenz96
  This implementation uses one obs-module for observations at grid points. The implementation supports all filters that are available in PDAF. This variant uses the flexible parallelization variant (PDAFomi_put_state_X).

Some Known Limitations

The current version of PDAF-OMI has a few limitations

• Using nondiagonal R-matrices, requires a user-supplied code for operations relating to R (see the documentation on the implemenetation for using non-diagonal R-matrices with OMI)
• OMI currently only includes observation operators with linear interpolation and for observation located at grid points.
• We have not tested interoperability with other programming languages. Generally Fortran derived data types and C structs should be compatible. Obviously, taking the Fortran routines and calling C functions to perform the actual initializations will work. (However, pyPDAF provides interoperability with Python).