Changes between Version 31 and Version 32 of ModifyModelforEnsembleIntegration
- Timestamp:
- May 22, 2025, 10:01:14 PM (2 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ModifyModelforEnsembleIntegration
v31 v32 1 = Modif ication ofthe model code for the ensemble integration =1 = Modifying the model code for the ensemble integration = 2 2 3 3 {{{ … … 6 6 <h4>Implementation Guide</h4> 7 7 <ol><li><a href="ImplementationGuide">Main page</a></li> 8 <li><a href="AdaptParallelization">Adaptati on ofthe parallelization</a></li>9 <li><a href="InitPdaf">Initializ ationof PDAF</a></li>8 <li><a href="AdaptParallelization">Adaptating the parallelization</a></li> 9 <li><a href="InitPdaf">Initializing of PDAF</a></li> 10 10 <li>Modifications for ensemble integration</li> 11 <li> <a href="InsertAnalysisStep">Fully parallel implementation variant</a></li>12 11 <li> <a href="ExternalModelLoop">Flexible implementation variant</a></li> 13 <li><a href="ImplementationofAnalysisStep">Implement ation ofthe analysis step</a></li>12 <li><a href="ImplementationofAnalysisStep">Implementing the analysis step</a></li> 14 13 <li><a href="AddingMemoryandTimingInformation">Memory and timing information</a></li> 15 14 </ol> … … 21 20 == Overview == 22 21 23 Numerical models are typically implemented for normal integration of some initial state. For the data assimilation with a filter algorithm, an ensemble of model states has to be integrated for limited time until observations are available and an analysis step of the filter is computed. Subsequently, the updated ensemble has to be integrated further. To allow for the interruption of the integrations by the analysis step, the model code has to be extended. As described on the page on the [ImplementationConceptOnline implementation concept of the online mode], there are two options for the ensemble integration: 24 * '''fully parallel''': For this implementation one needs to use a parallel computed with a sufficient number of processes such that the data assimilation program run be run with a concurrent time stepping of all ensemble states. Thus, if one runs each mode task with '''n''' processes and the ensemble has '''m''' members, the program has to run with '''n''' times '''m''' processes. This parallelism allows for a simplified implementation as each model task integrated only one model state and the model is always going forward in time. 25 * '''flexible''': This variant allows to run the assimilation program in a way so that a model task (set of processors running one model integration) can propagate several ensemble states successively. In the extreme case, this could mean that one only a a single model task that is successively performing the integration of all ensemble states. The implementation for this variant is a bit more complicated, because one has to ensure that the model can jump back in time. 22 On the [wiki:ImplementationConceptOnline Page on the Implementation Concept of the Online Mode] we explained the modification of the model code for the ensemble integration. On this page, we focus on the ''fully parallel'' implementation variant, which only needs minor code changes. In this case, the number of model tasks is equal to the ensemble size such that each model task integrates exactly one model state. In this case, the model always moves forward in time. As before, we refer to the example code for the online mode in `tutorial/online_2D_parallelmodel` and `tutorial/online_2D_serialmodel`. 26 23 27 The extension to the model code for both cases is depicted in the figure below (See also the page on the [ImplementationConceptOnline implementation concept of the online mode.]) As at this stage of the implementation the calls to `init_parallel_pdaf` and `init_pdaf` are already inserted into the code, the difference is in the addition of routines for the time stepping. 24 || The more complex ''flexible'' parallelization variant is described separately on the page: [ExternalModelLoop Modification of the model code for the ''flexible'' implementation variant]. || 28 25 29 [[Image(//pics/da_extension2x.png)]] 30 [[BR]]'''Figure 1:''' (left) Generic structure of a model code, (center) extension for ''fully-parallel'' data assimilation system with PDAF, (right) extension for ''flexible'' data assimilation system with PDAF. 26 The extension to the model code for the ''fully parallel'' implementation is depicted in the figure below (See also the page on the [ImplementationConceptOnline implementation concept of the online mode.]) As at this stage of the implementation the calls to `init_parallel_pdaf` and `init_pdaf` are already inserted into the code, the difference is in the addition of routines for the time stepping. The parallel ensemble integration is enabled by the configuration of the parallelization that was done by `init_parallel_pdaf` in the first step of the implementation. This does not require further code changes. 31 27 28 [[Image(//pics/DAextension_PDAF3.png)]] 29 [[BR]]'''Figure 1:''' (left) Generic structure of a model code, (right) modified structure for ''fully-parallel'' data assimilation system with PDAF. The figures assumes that the model is parallelized, such that it initializes its parallelization in the step `initial parallelization`. If the model is not parallelized this step does not exist. 32 30 31 To enable that the analysis can be performed, we next have to insert the routine `assimilate_pdaf` into the model code. 33 32 34 Operations that are specific to the model and to the assimilated observations are performed by call-back routines that are supplied by the user. These are called through the defined interface of PDAF. Generally, these user-supplied routines have to provide quite elementary operations, like initializing a model state vector for PDAF from model fields or providing the vector of observations. PDAF provides examples for these routines and templates that can be used as the basis for the implementation. As only the interface of these routines is specified, the user can implement the routines like a routine of the model. Thus, the implementation of these routines should not be difficult. The implementation of the call-back routines is identical for the fully-parallel and flexible implementation variants. 33 == Inserting `assimilate_pdaf` into the model code == 35 34 36 The implementations that are required for the fully-parallel and the flexible implementation variants are described on separate pages: 37 * '''fully parallel''': [InsertAnalysisStep Inserting the routine for the analysis step] 38 * '''flexible''': [ExternalModelLoop Modification of the model code for the '''flexible''' implementation variant] 35 The right place to insert the routine `assimilate_pdaf` into the model code is at the end of the model time stepping loop, thus when the model completed the computation of a single time step. In most cases, this is just before the 'END DO' in the model source code. However, there might be special cases, where the model does some additional operations so that the call to `assimialte_pdaf` should be insered somewhat earlier. 39 36 37 == Using `assimilate_pdaf` == 38 39 The purpose of `assimilate_pdaf` is to call the universal PDAF-core routine `PDAF3_assimilate` (or a more specific varant of this routine). The arguments of `PDAF3_assimilate` are mainly the names of user-supplied call-back routines, except from an argument for the status flag. These names are specified in `assimilate_pdaf` as 'external'. 40 41 The routine `assimilate_pdaf` is called at each time step of the model forecast. This allows to, e.g., apply [wiki:IncrementalAnalysisUpdates incremental anaylsis updates]. 42 43 Details on the implementations of the user-routines for the analysis step ar provided in the following [wiki:ImplementationofAnalysisStep Page on implementating the analysis step].
