Changes between Version 14 and Version 15 of ImplementationConceptOffline

Timestamp:

May 17, 2025, 11:27:15 AM (24 hours ago)

Author:

lnerger

Comment:

--

ImplementationConceptOffline

@@ -24 +24 @@
 The assimilation program is a simplified implementation of what is required when PDAF is used in its online mode. In particular, no explicit linkage to the model code and no forecast phase are required. Essentially, one just needs the driver program that calls the PDAF routines. The general structure of the program for the offline assimilation program is depicted in figure 1.
 
-[[Image(//pics/PDAF_offline.png)]]
-[[BR]]'''Figure 1:''' Structure of the assimilation program with PDAF in offline mode.
+[[Image(//pics/PDAF_offline_v3.png)]]
+[[BR]]'''Figure 1:''' The offline mode exchanges information on model fields and the model grid information using disk files. For the assimilaton program the typical structure is shown.
 
 The structure of the assimilation program is the following:
- * At the beginning of the program, the routine `init_parallel_pdaf` is executed. `init_parallel_pdaf` creates the parallel environment for PDAF. In the offline mode, it is possible to execute the assimilation program on a single processor, even if the model is parallelized. 
+ * At the beginning of the program, the subroutine `init_parallel_pdaf` is executed. This subroutine creates the parallel environment for PDAF. In the offline mode, it is possible to execute the assimilation program on a single processor, even if the model is parallelized. With local filter methods, one can also use OpenMP (shared memory) parallelization.
  * Subsequently, a routine `init_pdaf` is executed. In this routine, parameters for PDAF can be defined and then the core initialization routine `PDAF_init` is called. This core routine also initializes the array of ensemble states. In case of the offline mode, this means that the ensemble is read from the output files of the model.
- * Finally, the routine `assimilation_pdaf` is call. In this routine, the names of the user-supplied routines are declared and than the filter-specific PDAF core routine `PDAF_put_state_X` is executed (where X is replaced by the name of the filter algorithm, e..g X=estkf). As for the offline mode there is no ensemble integration in the assimilation program, this subroutine directly computes the analysis step (i.e. the actual assimilation of the observations). In a user-supplied subroutine of `PDAF_put_state`, the ensemble of analysis states is finally written into restart files for the next forecast phase conducted by direct model integrations initialized from these files.
+ * Finally, the routine `assimilation_pdaf` is called. In this routine, the names of the user-supplied routines are declared and than the PDAF core routine `PDAF3_assim_offline` is executed (With PDAF before version 3.0, a routine `PDAFomi_put_state_X` is used (where X is replaced by the specific type of DA method, e..g X=`local`). For the offline mode there is no ensemble integration in the assimilation program. Thus, this subroutine directly computes the analysis step (i.e. the actual assimilation of the observations). In a user-supplied subroutine called by `PDAF3_assim_offline`, the ensemble of analysis states is finally written into restart files for the next forecast phase conducted by direct model integrations initialized from these files.
 
 == Important aspects of the implementation concept ==
 
  * With the offline mode of PDAF, no direct coupling between PDAF and the model code is required. The exchange of information between the model and the assimilation program is performed solely through the output and restart files of the model. It requires that the user implements routines to read the model fields from the forecast files. In addition, routines are necessary that write the analysis state ensemble into restart files of the model. 
- * Model-specific operations like the initialization of the array of ensemble states in `PDAF_init` are actually performed by user-supplied call-back routines. These routines are called through the standard interface of `PDAF`. They can be implemented int he users programming style and just have to be consistent with the interface. 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.
-[[Image(//pics/PDAF_callback_offline.png)]]
+ * Model-specific operations like the initialization of the array of ensemble states in `PDAF_init` are performed by user-supplied subroutines, which are executed by PDAF as call-back routines. These routines are called through the standard interface of PDAF. They can be implemented in the users programming style and just have to be consistent with the interface. 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.
+[[Image(//pics/PDAF_callback_offline_v3.png)]]
 [[BR]]'''Figure 2:''' The assimilation program consist of the driver program, the PDAF core, and user-supplied call-back routines.
 
- * With regard to the parallelization, the assimilation program can be run on a single processor, i.e. without parallelization. The variables for the parallelization still have to be initialized by a call to `init_parallel_pdaf`. However, one does not need to compile with an MPI library, but it is sufficient to use the dummy implementation of the MPI-routines that is supplied with PDAF. If the model is parallelized, one needs to ensure that the model fields are read correctly. In particular, if in the parallel model each process writes a separate file, one has to read these files sequentially in order to initialize an ensemble array holding the global state information.
- * For large-scale models, it can be useful to execute the assimilation program with parallelization. Perhaps, following the domain decomposition of the model is the easiest strategy for this. In this case the decomposition information from the model has to be read into the assimilation program in order to initialize the state dimension of the sub-domains as well as the coordinates for each sub-domain.
- * The core routines of PDAF (those with the prefix `PDAF_`) are identical for the online and offline modes. The offline mode is switched on by selecting the corresponding subtype of the filter method in the call to `PDAF_init`.
+ * With regard to the parallelization, the assimilation program can be run on a single processor, i.e. without parallelization. The variables for the parallelization still have to be initialized by calling `init_parallel_pdaf`. 
+ * For large-scale models, it can be useful to execute the assimilation program with parallelization. The easiest approach is to use the OpenMP-parallelization of the local filter algorithms in PDAF. One can also explicitly decompose the state vector. Perhaps, following the domain decomposition of the model is the easiest strategy for this. In this case the decomposition information from the model has to be read into the assimilation program in order to initialize the state dimension of the sub-domains as well as the coordinates for each sub-domain.
+ * The core routines of PDAF (those with the prefix `PDAF_`) are identical for the online and offline modes.