Changes between Version 35 and Version 36 of ImplementAnalysislseik


Ignore:
Timestamp:
May 17, 2011, 10:47:30 AM (13 years ago)
Author:
lnerger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ImplementAnalysislseik

    v35 v36  
    2525== Overview ==
    2626
    27 For the analysis step of the LSEIK filter several operations related to the observations are needed. These operations are requested by PDAF by calling user-supplied routines. Intentionally, the operations are split into separate routines in order to keep the operations rather elementary as this procedure should simplify the implementation. The names of the required routines are specified in the call to the routine `PDAF_put_state_lseik` described below. With regard to the parallelization, all these routines (except `U_collect_state`) are executed by the filter processes (`filterpe=1`) only.
    28 
    29 For completeness we discuss here all user-supplied routines that are specified in the interface to `PDAF_put_state_lseik`. Many of the routines are localized versions of those that are needed for the global SEIK filter. Hence, if the user-supplied routines for the global SEIK filter have been already implemented, one can base on these routines to spped up the implementation.
     27For the analysis step of the LSEIK filter, several operations related to the observations are needed. These operations are requested by PDAF by calling user-supplied routines. Intentionally, the operations are split into separate routines in order to keep the operations rather elementary as this procedure should simplify the implementation. The names of the required routines are specified in the call to the routine `PDAF_put_state_lseik` described below. With regard to the parallelization, all these routines (except `U_collect_state`) are executed by the filter processes (`filterpe=1`) only.
     28
     29For completeness we discuss here all user-supplied routines that are specified in the interface to `PDAF_put_state_lseik`. Many of the routines are localized versions of those that are needed for the global SEIK filter. Hence, if the user-supplied routines for the global SEIK filter have been already implemented, one can base on these routines to speed up the implementation. Due to this, it can also be reasonable to first fully implement a global filter version and subsequently implement the corresponding localized filter by modifying and extending the global routines.
    3030
    3131== `PDAF_put_state_lseik` ==
    3232
    33 The general espects of the filter specific routines `PDAF_put_state_*` have been described on the page [ModifyModelforEnsembleIntegration Modification of the model core for the ensemble integration].
    34 The interface for the routine `PDAF_put_state_lseik` contains several routine names for routines that operate on the local analysis domains (marked by `_local` at then end of the routine name). In addition, there are names for routines that consider all available observations required to perform local analyses with LSEIK within some sub-domain of a domain-decomposed model (marked by `_full` at then end of the routine name). In case of a serial execution of the assimilation program, these will be all globally available observations. However, if the program is executed with parallelization, this might be a smaller set of observations. To explain the  difference it is assumed, for simplicity, that a local analysis domain consists of a single vertical column of the model grid. In addition, we assume that the domain decomposition splits the global model domain by vertical boundaries as is typical for ocean models and that the observations are spatially distributed observations of model fields that are part of the state vector.  Under these assumptions, the situation is the following: When a model uses domain decomposition, the LSEIK filter is executed such that for each model sub-domain a loop over all local analysis domains (e.g. vertical columns) that belong to the model sub-domain is performed. As each model sub-domain is treated by a different process, all loops are executed parallel to each other. For the update of each single vertical column, observations from some larger domain surrounding the vertical column are required. If the influence radius for the observations is sufficiently small there will be vertical columns for which all relevant observations reside inside the model sub-domain of the process. However, if a vertical column is considered that is located close to the boundary of the model sub-domain, there will be some observations that don't belong spatially to the local model sub-domain, but to a neighboring model sub-domain. Nonetheless, these observations are required on the local model sub-domain. A simple way to handle this situation is to initialize for each process all globally available observations, together with their coordinates. While this method is simple, it can also become inefficient if the assimilation program is executed using a large number of processes. As for an initial implementation it is usually not the concern to obtain the highest parallel efficiency, the description below assumes that 'full' refers to the global model domain.
     33The general espects of the filter-specific routines `PDAF_put_state_*` have been described on the page [ModifyModelforEnsembleIntegration Modification of the model code for the ensemble integration].
     34The interface for the routine `PDAF_put_state_lseik` contains several routine names for routines that operate on the local analysis domains (marked by `_local` at then end of the routine name). In addition, there are names for routines that consider all available observations required to perform local analyses with LSEIK within some sub-domain of a domain-decomposed model (marked by `_full` at then end of the routine name). In case of a serial execution of the assimilation program, these will be all globally available observations. However, if the program is executed with parallelization, this might be a smaller set of observations.
     35
     36To explain the  difference, it is assumed, for simplicity, that a local analysis domain consists of a single vertical column of the model grid. In addition, we assume that the domain decomposition splits the global model domain by vertical boundaries as is typical for ocean models and that the observations are spatially distributed observations of model fields that are part of the state vector.  Under these assumptions, the situation is the following: When a model uses domain decomposition, the LSEIK filter is executed such that for each model sub-domain a loop over all local analysis domains (e.g. vertical columns) that belong to the model sub-domain is performed. As each model sub-domain is treated by a different process, all loops are executed parallel to each other.
     37
     38For the update of each single vertical column, observations from some larger domain surrounding the vertical column are required. If the influence radius for the observations is sufficiently small there will be vertical columns for which the relevant observations reside completely inside the model sub-domain of the process. However, if a vertical column is considered that is located close to the boundary of the model sub-domain, there will be some observations that don't belong spatially to the local model sub-domain, but to a neighboring model sub-domain. Nonetheless, these observations are required on the local model sub-domain. A simple way to handle this situation is to initialize for each process all globally available observations, together with their coordinates. While this method is simple, it can also become inefficient if the assimilation program is executed using a large number of processes. As for an initial implementation it is usually not the concern to obtain the highest parallel efficiency, the description below assumes that 'full' refers to the global model domain.
    3539
    3640The interface when using the LSEIK filter is the following:
     
    6771Here, all user-supplied routines are described that are required in the call to `PDAF_put_state_lseik`. For some of the generic routines, we link to the page on [ModifyModelforEnsembleIntegration modifying the model code for the ensemble integration].
    6872
    69 To indicate user-supplied routines we use the prefix `U_`. In the template directory `templates/` these routines are provided in files with the routines name without this prefix. In the example implementation in `testsuite/src/dummymodel_1D` the routines exist without the prefix, but with the extension `_dummy_D.F90`. In the section titles below we provide the name of the template file in parentheses.
    70 
    71 In the subroutine interfaces some variables appear with the suffix `_p`. This suffix indicates that the variable is particular to a model sub-domain, if a domain decomposed model is used. Thus, the value(s) in the variable will be different for different model sub-domains. In addition, there will be variables with the suffix `_f` (for 'full') and with the suffix `_l` (for 'local').
     73To indicate user-supplied routines we use the prefix `U_`. In the template directory `templates/` these routines are provided in files with the routine's name without this prefix. In the example implementation in `testsuite/src/dummymodel_1D`, the routines exist without the prefix, but with the extension `_dummy_D.F90`. In the section titles below we provide the name of the template file in parentheses.
     74
     75In the subroutine interfaces some variables appear with the suffix `_p` (short for 'process'). This suffix indicates that the variable is particular to a model sub-domain, if a domain decomposed model is used. Thus, the value(s) in the variable will be different for different model sub-domains. In addition, there will be variables with the suffix `_f` (for 'full') and with the suffix `_l` (for 'local').
    7276
    7377=== `U_collect_state` (collect_state.F90) ===