| 38 | | * **assimilate_pdaf**: This routine is added to the model code at 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, this routine was called `PDAFomi_get_state_X` with, e.g., X=`local`, for local filters). 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. |
| | 38 | * **assimilate_pdaf**: This routine is added to the model code at 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 routine 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. |
| 45 | | * 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. |
| 46 | | * 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: |
| 47 | | * 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. This case requires to implement the ''flexible'' implementation variant. |
| 48 | | * If there are as many model tasks as ensemble members, the model time always moves forward. In this case, one can implement PDAF with the ''fully-parallel'' variant without the external ensemble loop. That is, one calls `PDAF_assimilate_X` at the end of each time step. This strategy might also be simpler if a model uses nested loops (like a loop over minutes inside a loop over hours). |
| 49 | | * 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. |
| 50 | | * The assimilation system is controlled by the user-supplied routines that are called through PDAF as call-back routines. 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. |
| | 44 | * The implementation concept of PDAF attaches the data assimilation functionality to the model. With this approach, the data assimilation is finally run analogous to a normal model run, but with additional processors and additional options for the data assimilation. |
| | 45 | * 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 of the ensemble integration are added to the model code before and after the code parts performing the time stepping. This minimizes the changes in the model code. |
| | 46 | * In the ''fully parallel'' mode described here, we use as many model tasks as ensemble members. Thus, the model always moves forward in time. |
| | 47 | * 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 the standard interface of PDAF 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. |
| | 48 | * 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. |
| | 49 | * 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. |
| | 50 | |
