Changes between Version 9 and Version 10 of GeneralImplementationConcept

Timestamp:

Sep 27, 2010, 8:52:44 AM (14 years ago)

Author:

lnerger

Comment:

--

GeneralImplementationConcept

@@ -39 +39 @@
 == Remarks on the implementation concept ==
 
- * The implementation concept of PDAF does not require that the time stepping part of the model is implemented as a subroutine. Instead the control of the ensemble integration is added around the code performed the time stepping. However, if the time stepping part is implemented as a subroutine, the code will look clearer.
- * Depending on the parallelization, there can be cases in which the model has to jump back in time and cases in which the time always moves forward. 
+ * The implementation concept of PDAF does not require that the time stepping part of the model is implemented as a subroutine. Instead calls to subroutines that control of the ensemble integration are added to the model code before and after the code parts performing the time stepping. If the time stepping part is implemented as a subroutine, this subroutine can be called in between the additional routines.
+ * Depending on the parallelization, there can be cases in which the model has to jump back in time and cases in which the time always moves forward: 
   * Jumping back in time will be required if the number of model tasks used to evolve the ensemble states is smaller than the number of ensemble members. In this case a model task has integrate more than one model state and will have to jump back in time after the integration of each ensemble member. 
   * If there are as many model tasks as ensemble members, the model time always moves forward. In this case, one can implement PDAF also without the external ensemble loop. That is, one can add calls to `PDAF_get_state` and `PDAF_put_state` directly into the code of the model's time stepping loop. This strategy might also be called for, if a model uses staggered loops (like a loop over minutes inside a loop over hours).
- * model-specific operations like the initialization of the array of ensemble states in `PDAF_init` are actually performed by user-supplied routines. These routines are called through the standard interface of `PDAF`. Details on the interface and the required routines are given on the pages describing the implementation steps.
- * The control of the assimilation system
-
-the core routines of PDAF remain unchanged. The data assimilation system is controlled by the user-supplied routines. Accordingly, the driver functionality remains in the model part of the program. In addition, the user-supplied routines can be implemented analogously to the model code, i.e. by using Fortran common blocks or modules of the model code. This simplifies the implementation of the user-supplied routines knowing about the particularities of their model. 
+ * Model-specific operations like the initialization of the array of ensemble states in `PDAF_init` are actually performed by user-supplied routines. These routines are called through the standard interface of `PDAF`. Details on the interface and the required routines are given on the pages describing the implementation steps.
+ * The assimilation system is controlled by the user-supplied routines that are called through PDAF.  With this strategy, the assimilation program is essentially driven by the model part of the program. Thus, logically the model is not a sub-component of the assimilation system, but the implementation with PDAF results in a model extended for data assimilation.
+ * The user-supplied routines can be implemented analogously to the model code. For example, if the model is writting using Fortran common blocks or modules of the model code, these can be used to implement the user-supplied routines, too. This simplifies the implementation of the user-supplied routines knowing about the particularities of their model.