Changes between Version 17 and Version 18 of ImplementationConceptOffline


Ignore:
Timestamp:
May 31, 2025, 6:35:14 PM (4 days ago)
Author:
lnerger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ImplementationConceptOffline

    v17 v18  
    1818[[PageOutline(2-3,Contents of this page)]]
    1919
    20 In case of the offline mode of PDAF, the ensemble integrations are performed by the numerical model without required changes. After all ensemble members are integrated to the time when observations are to be assimilated, the assimilation program containing PDAF is started. The program reads the files from the model for all ensemble members. Subsequently, the analysis step of the chosen filter algorithm is computed. Finally, the updated ensemble states are written into input or restart files of the model. This completes the analysis step such that the next forecast phase can be computed.
     20The offline mode of PDAF separates the model forecasts from the analysis step of the data assimialtion. The ensemble integrations are performed by the numerical model. After all ensemble members are integrated to the time when observations are to be assimilated, the assimilation program containing PDAF is started. This program reads the files from the model for all ensemble members. Subsequently, the analysis step of the chosen filter algorithm is computed. Finally, the updated ensemble states are written into input or restart files of the model. This completes the analysis step such that the next forecast phase can be computed.
    2121
    22 In the forecast phase the user has to run the numerical model as many times as there are ensemble members. Each model forecast has to be initialized by the state fields of the ensemble member. At the end of each single forecast integration the forecast fields are written into regular output files of the model. Within the offline mode of PDAF, we leave it to the user to control the integrations. As these are regular model integrations, it should be easiest to use the regular scripts used also to perform a free model integration without data assimilation. However, the user has to take care that the output files from each ensemble member are stored separately.
     22In the forecast phase, the user has to run the numerical model seprately for each  ensemble member state. Each model forecast has to be initialized by the state fields of the ensemble member. At the end of each single forecast integration, the model writes the forecast fields into regular output or restart files. Within the offline mode of PDAF, we leave it to the user to control the model runs. As these are regular model integrations, it should be easiest to use the regular scripts used also to perform a free model integration without data assimilation. However, the user has to take care that the output files from each ensemble member are stored separately.
    2323
    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.
     24The 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 a driver program that calls the PDAF routines. The general structure of the program for the offline assimilation program is depicted on the right hand side of Figure 1.
    2525
    2626[[Image(//pics/PDAF_offline_v3.png)]]
    … …  
    2828
    2929The structure of the assimilation program is the following:
    30  * 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.
    31  * 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.
    32  * 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` for the assimilation 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.
     30 * **init_parallel_pdaf**: This routine is executed at the beginning of the program. 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.
     31 * **init_pdaf**: The routine `init_pdaf` is executed next. In this routine, parameters for PDAF can be defined and then the core initialization routine `PDAF_init` is called.  This core routine initializes internal parameters and afterwards the array of ensemble states using a user-provided call-back routine. In case of the offline mode, this means that the ensemble is read from the output files of the model.
     32 * **assimilation_pdaf**: This routine executes the analysis step. It declares the names of user-supplied subroutines and then the PDAF core routine `PDAF3_assim_offline` for the assimilation 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. 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 performed by model integrations initialized from these files.
     33 * **finalize_PDAF**: This routine is used to let PDAF display timing and memory information and to call PDAF to deallocate its internal arrays.
    3334
    3435== Important aspects of the implementation concept ==
    3536
    36  * 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.
    37  * PDAF uses the concept to 'pull' information at the time when it is needed. 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.
     37 * 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 and routines that write the analysis state ensemble into restart files of the model.
     38 * PDAF uses the concept to 'pull' information at the time when it is needed. Model-specific operations like reading the model files and initializing the array of ensemble states in `PDAF_init` are performed by user-supplied subroutines, which are executed by PDAF as call-back routines. Also the reading of observational infromation is performed by user-supplied call-back subroutines.
     39These 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.
    3840[[Image(//pics/PDAF_callback_offline_v3.png)]]
    3941[[BR]]'''Figure 2:''' The assimilation program consist of the driver program, the PDAF core, and user-supplied call-back routines.
    4042
    41  * 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`.
    42  * 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.
     43 * With regard to the parallelization, the assimilation program can be run on a single processor. The variables for the parallelization still have to be initialized by calling `init_parallel_pdaf`.
     44 * 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 ensemble filter algorithms in PDAF. One can also explicitly decompose the state vector. An easy strategy for this can be to follow the domain decomposition of the model. 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.
    4345 * The core routines of PDAF (those with the prefix `PDAF_`) are identical for the online and offline modes.
    4446