Changes between Version 24 and Version 25 of ImplementationConceptOnline

Timestamp:

Sep 1, 2025, 10:16:50 AM (22 hours 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. 
+ * **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. The routine calls the PDAF core routine `PDAF3_set_parallel` to provide the parallelization variables to PDAF (in implementations of PDAF before verison 3.0, this call is not present).
+ * **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 `PDAF3_init` (in implementations of PDAF before version 3.0, this routine was called `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.