Version 6 (modified by lnerger, 3 months ago) (diff)


Using thisobs%use_global_obs=0


In the domain-localized filters (LESTK, LETKF, LSEIK, LNETF) observations are assimilated that are located within the localization around some grid point. When a model uses parallelization with domain-decomposition some of these observations might belong to a different process-domain. In the default mode (thisobs%use_global_obs=1) PDAF-OMI gathers all globally available observations so that each process has access to all observations. It can be more efficient to limit the observations on a process-domain to those observations that are located inside the domain or within the localization radius around it. Then, in the local analyses less observations have to be checked for their distance. Setting thisobs%use_global_obs=0 activates this feature. However, it needs additional preparations to make PDAF-OMI aware of the limiting coordinates of a process sub-domain.

In order to make use of the domain-limited observations, one has to provide PDAF-OMI with the limiting coordinates of a process-subdomain. There are two routines that can to this task:

  • PDAFomi_set_domain_limits
  • PDAFomi_get_domain_limits_unstrc

One of these routines has to be called in init_pdaf to set the domain information. Their use is described below.

After this call, OMI is set up to use domain-limited observations with thisobs%use_global_obs=0. The necessary operation will be performed by PDAF-OMI inside PDAFomi_gather_obs and inside the observation operators.

Note: The domain-limitation is only implemented to work in two dimensions.


In this routine one provide the limiting coordinates of the process domain so that PDAF-OMI can store the information.

The interface is

  SUBROUTINE PDAFomi_set_domain_limits(lim_coords)

    REAL, INTENT(in) :: lim_coords(2,2)     !< coordinate array (1: longitude, 2: latitude)
                                            !< geographic range: longitude (-pi, pi), latitude (-pi/2, pi/2)
                                            !< Cartesian range: (x) coordinate grows from left to right; (y) from bottom to top

here lim_coords are

        |         |           - (1,1) longitude of the western edge of the domain (or x-coordinate of the left edge)
        |         |           - (1,2) longitude of the eastern edge of the domain (or x-coordinate of the right edge)
  (1,1) |         | (1,2)     - (2,1) latitude of the northern edge of the domain (or y-coordinate of the upper edge)
        |         |           - (2,2) latitude of the southern edge of the domain (or y-coordinate of the lower edge)
        |         |

Thus, (:,1) specifies the north-western corner of the sub-domain and (:,2) the souther-estern corner. The first (x) coordinate grows from left to right, while the second coordinate (y) increases from bottom to the top.

If the model grid is not decomposed in cardinal directions, but e.g. rotated, the coordinates should specife the extrema. Thus, lim_coords(1,1) would be the coordinate of the northernmost grid point of a domain.


This routine is find the extreme coordinates for a model domain. The routine is provided with the coordinates of all grid pints of a domain and then find the limiting coordinates. It is designed for unstructured grid and we have only tested it with the ocean model FESOM. (The tricky part is when a process-domain crosses the date line).

The interface is

  SUBROUTINE PDAFomi_get_domain_limits_unstr(verbose, npoints_p, coords_p)

    INTEGER, INTENT(in) :: verbose          !< verbosity flag (1: write output)
    INTEGER, INTENT(in) :: npoints_p        !< number of process-local grid points
    REAL, INTENT(in) :: coords_p(:,:)       !< geographic coordinate array, dimension (2, npoints_p)
                                            !<   (row 1: longitude, 2: latitude)
                                            !<   ranges: longitude (-pi, pi), latitude (-pi/2, pi/2)

This function only supports geographic coordinates given in radians.