Changes between Version 21 and Version 22 of ImplementationConceptOnline

Timestamp:

May 31, 2025, 6:37:05 PM (2 days ago)

Author:

lnerger

Comment:

--

ImplementationConceptOnline

@@ -39 +39 @@
 '''Extensions for the fully-parallel assimilation system'''[[BR]]
 The right side of Figure 1 shows the extensions required for the ''fully-parallel'' assimilation system (marked green):
- * **init_parallel_PDAF**: This subroutine is inserted close to the start of the model code. If the model itself is parallelized the correct location is directly after the initialization of the parallelization in the model code. `init_parallel_pdaf` creates the parallel environment that allows to compute the time stepping for an ensemble of models ("model tasks") at the same time.
- * **init_PDAF**: This subroutine is added after the initialization part of the model, just before the time stepping loop. In this subroutine one defines parameters for PDAF and then one calls the core initialization routine `PDAF_init`. This core routine initializes internal parameters and afterwards the array of ensemble states using a user-provided call-back routine. Subsequently, one calls the PDAF core routine `PDAF_init_forecast` (in implementations of PDAF before version 3.0, this routine was called `PDAF_get_state`). This routine initializes model fields from the array of ensemble states using a call-back routine. In addition, it returns the number of time steps that have to be computed in the following forecast phase. 
- * **assimilate_PDAF**: This routine is added to the model code before the end of the time stepping loop (usually just before the ''END DO'' in a Fortran program). The routine declares the names of user-supplied subroutines and calls a PDAF-core routine `PDAF3_assimilate`. (In implementations of PDAF before version 3.0, different routines named `PDAFomi_assimilate_X` with, e.g., X=`local`, for local filters are used). This routine has to be called at the end of each time step. It counts whether all time steps of the current forecast phase have been computed. If this is not the case, the program continues integrating the model. If the forecast phase is completed, the analysis step, i.e. the actual assimilation of the observations, is computed. Subsequently, the next forecast phase is initialized by writing the analysis state vector into the model fields and setting the number of time steps in the next forecast phase.
- * **finalize_PDAF**: This routine is used to let PDAF display timing and memory information and to call PDAF to deallocate its internal arrays. 
+ * **init_parallel_pdaf**: This subroutine is inserted close to the start of the model code. If the model itself is parallelized the correct location is directly after the initialization of the parallelization in the model code. `init_parallel_pdaf` creates the parallel environment that allows to compute the time stepping for an ensemble of models ("model tasks") at the same time.
+ * **init_pdaf**: This subroutine is added after the initialization part of the model, just before the time stepping loop. In this subroutine one defines parameters for PDAF and then one calls the core initialization routine `PDAF_init`. This core routine initializes internal parameters and afterwards the array of ensemble states using a user-provided call-back routine. Subsequently, one calls the PDAF core routine `PDAF_init_forecast` (in implementations of PDAF before version 3.0, this routine was called `PDAF_get_state`). This routine initializes model fields from the array of ensemble states using a call-back routine. In addition, it returns the number of time steps that have to be computed in the following forecast phase. 
+ * **assimilate_pdaf**: This routine is added to the model code into the time stepper before the end of the time stepping loop (usually just before the ''END DO'' in a Fortran program). The routine declares the names of user-supplied subroutines and calls a PDAF-core routine like `PDAF3_assimilate`. (In implementations of PDAF before version 3.0, different routines named `PDAFomi_assimilate_X` with, e.g., X=`local`, for local filters are used). This routine has to be called at the end of each time step. It counts whether all time steps of the current forecast phase have been computed. If this is not the case, the program continues integrating the model. If the forecast phase is completed, the analysis step, i.e. the actual assimilation of the observations, is computed. Subsequently, the next forecast phase is initialized by writing the analysis state vector into the model fields and setting the number of time steps in the next forecast phase.
+ * **finalize_pdaf**: This routine is used to let PDAF display timing and memory information and to call PDAF to deallocate its internal arrays. 
 
 With the implementation strategy of PDAF, calls to four subroutines are added to the model code. These additions are usually only single lines of code and the changes only affect the general part of the model code.  
@@ -53 +53 @@
 * The implementation with PDAF does not require that the time stepping part of the model is implemented as a subroutine. Instead calls to subroutines that control the the ensemble integration are added to the model code. This minimizes the changes in the model code.
 * In the ''fully parallel'' mode described here, we use as many model tasks as ensemble members. Thus, the model always moves forward in time. 
-* PDAF uses the concept to 'pull' information at the time when it is needed. All model-specific operations, like the initialization of the array of ensemble states in `PDAF_init`, are performed by user-supplied routines which are called through PDAF's standard interface as call-back routines. Details on the interface and the required routines are given on the pages describing the implementation steps. The concept of the call-back routines is depicted in Fig. 2.
+* PDAF uses the concept to 'pull' information at the time when it is needed. All model-specific operations, like the initialization of the array of ensemble states in `PDAF_init`, are performed by user-supplied routines which are called through PDAF's standard interface as call-back routines. Also the reading of observational infromation is performed by user-supplied call-back subroutines. Details on the interface and the required routines are given on the pages describing the implementation steps. The concept of the call-back routines is depicted in Fig. 2.
 * The assimilation system is controlled by the user-supplied routines that are called through PDAF as call-back routines.  With this strategy, the assimilative model program is essentially driven by the model part of the program. Thus, 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 call-back routines can be implemented in the context of the model analogously to the model code. For example, if the model is implemented using Fortran modules (or even common blocks), 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.