| 27 | | For the analysis step of the LSEIK filter |
| 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. |
| | 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 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. |
| 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. |
| | 33 | The 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]. |
| | 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. |
| | 35 | |
| | 36 | 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. |
| | 37 | |
| | 38 | 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 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. |
| 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` |
| | 73 | To 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 | |
| | 75 | In 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'). |
