Changes between Version 33 and Version 34 of ModifyModelforEnsembleIntegration


Ignore:
Timestamp:
May 23, 2025, 8:05:16 PM (9 days ago)
Author:
lnerger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ModifyModelforEnsembleIntegration

    v33 v34  
    2020== Overview ==
    2121
    22 On the [wiki:ImplementationConceptOnline Page on the Implementation Concept of the Online Mode] we explained the modification of the model code for the ensemble integration. On this page, we focus on the ''fully parallel'' implementation variant, which only needs minor code changes. In this case, the number of model tasks is equal to the ensemble size such that each model task integrates exactly one model state. In this case, the model always moves forward in time. As before, we refer to the example code for the online mode in `tutorial/online_2D_parallelmodel` and `tutorial/online_2D_serialmodel`.
     22On the [wiki:ImplementationConceptOnline Page on the Implementation Concept of the Online Mode] we explained the modification of the model code for the ensemble integration. Here, we focus on the ''fully parallel'' implementation variant, which only needs minor code changes. In this case, the number of model tasks is equal to the ensemble size such that each model task integrates exactly one model state. In this case, the model always moves forward in time. As before, we refer to the example code for the online mode in `tutorial/online_2D_parallelmodel` and `tutorial/online_2D_serialmodel`.
    2323
    2424|| The more complex ''flexible'' parallelization variant is described separately on the page: [ExternalModelLoop Modification of the model code for the ''flexible'' implementation variant]. ||
    2525
    26 The extension to the model code for the ''fully parallel'' implementation is depicted in the figure below (See also the page on the [ImplementationConceptOnline implementation concept of the online mode.]) As at this stage of the implementation the calls to `init_parallel_pdaf` and `init_pdaf` are already inserted into the code, the difference is in the addition of routines for the time stepping. The parallel ensemble integration is enabled by the configuration of the parallelization that was done by `init_parallel_pdaf` in the first step of the implementation. This does not require further code changes. 
     26The extension to the model code for the ''fully parallel'' implementation is depicted in the figure below (See also the page on the [ImplementationConceptOnline implementation concept of the online mode.]) As at this stage of the implementation the calls to `init_parallel_pdaf` and `init_pdaf` are already inserted into the code, the difference is in the addition of routines for the time stepping. The parallel ensemble integration is enabled by the configuration of the parallelization that was done by `init_parallel_pdaf` in the first step of the implementation. This does not require further code changes.
     27
     28For the ''fully parallel'' parallelization variant, the number of time steps `nsteps` shown in Figure 1 is the overall length of the data assimilation run. This can include several data assimilation cycles of forecasts and analysis steps.
    2729
    2830[[Image(//pics/DAextension_PDAF3.png)]]
    2931[[BR]]'''Figure 1:''' (left) Generic structure of a model code, (right) modified structure for ''fully-parallel'' data assimilation system with PDAF. The figures assumes that the model is parallelized, such that it initializes its parallelization in the step `initial parallelization`. If the model is not parallelized this step does not exist.
    3032
    31 To enable that the analysis can be performed, we next have to insert the routine `assimilate_pdaf` into the model code.
     33There are two further steps required now:
     341. We need to initialize the ensemble forecasting. Thus, we need to set how many time steps need to be done until the first observations are assimilated. In addition, we need to write the ensemble state vector values into the model fields. For these operations, we call the routine `PDAF_init_forecast` in the routine `init_pdaf`.
     351. To enable that the analysis can be performed, we then have to insert the routine `assimilate_pdaf` into the model code.
     36
     37Both are described below.
     38
     39== Calling `PDAF_init_forecast` ==
     40
     41The routine `PDAF_init_forecast` is called at the end of the routine `init_pdaf` that was discussed on the [InitPdaf page on initializing PDAF]. The main purpose of this routine is to initialize the model fields for all model tasks from the ensemlbe of state vectors. This is done in the call-back routine `distribute_state_pdaf`. Further, the routine calls the call-back-routine `prepoststep_pdaf`. This pre/postep routine provides the user access to the initial ensemble. The routine also returns the number of time steps for the initial forecast phase, and an exit flag. These variables are usually not used in the user code in the `fully parallel` variant, but only internally by PDAF.
     42
     43The interface of `PDAF_init_forecast` is:
     44{{{
     45  SUBROUTINE PDAF_init_forecast(nsteps, timenow, doexit, &
     46                                next_observation_pdaf, distribute_state_pdaf, &
     47                                prepoststep_pdaf, status)
     48}}}
     49with the arguments (where the bold names show the arguments relevant to the user for the ''fully-parallel'' variant):
     50 * `nsteps`: An integer specifying upon exit the number of time steps to be performed
     51 * `timenow`: A real specifying upon exit the current model time.
     52 * `doexit`: An integer variable defining whether the assimilation process is completed. (1: exit, 0: continue).
     53 * **[#next_observation_pdafnext_observation_pdaf.F90 U_next_observation]**: The name of a user supplied routine that initializes the variables `nsteps`, `timenow`, and `doexit`
     54 * **[#distribute_state_pdafdistribute_state_pdaf.F90 U_distribute_state]**: The name of a user supplied routine that initializes the model fields from the array holding the ensemble of model state vectors
     55 * **[#prepoststep_pdafprepoststep_ens_pdaf.F90 U_prepoststep]**: The name of a user supplied routine that is called before and after the analysis step. Here the user has the possibility to access the state ensemble and can e.g. compute estimated variances or can write the ensemble states the state estimate into files.
     56 * **`status`**: The integer status flag. It is zero, if the routine is exited without errors. We recommend to check the value.
     57
     58The user-supplied routines are described further below.
     59
    3260
    3361== Inserting `assimilate_pdaf` into the model code ==
    3462
    35 The right place to insert the routine `assimilate_pdaf` into the model code is at the end of the model time stepping loop, thus when the model completed the computation of a single time step. In most cases, this is just before the 'END DO' in the model source code. However, there might be special cases, where the model does some additional operations so that the call to `assimialte_pdaf` should be insered somewhat earlier.
     63The right place to insert the routine `assimilate_pdaf` into the model code is at the end of the model time stepping loop, thus when the model completed the computation of a single time step. In most cases, this is just before the 'END DO' in the model source code. However, there might be special cases, where the model does some additional operations so that the call to `assimilate_pdaf` should be insered somewhat earlier.
    3664
    3765== Using `assimilate_pdaf` ==
    … …  
    4270
    4371Details on the implementations of the user-routines for the analysis step ar provided in the following [wiki:ImplementationofAnalysisStep Page on implementating the analysis step].
     72
     73== User-supplied routines ==
     74
     75Here, we discuss the user-supplied routines that are arguments of `PDAF_init_forecast`.
     76
     77In the section titles below we provide the name of the template file in parentheses.
     78
     79=== `next_observation_pdaf` (next_observation_pdaf.F90) ===
     80
     81The interface for this routine is
     82{{{
     83SUBROUTINE next_observation_pdaf(stepnow, nsteps, doexit, timenow)
     84
     85  INTEGER, INTENT(in)  :: stepnow  ! The current time step
     86  INTEGER, INTENT(out) :: nsteps   ! Number of time steps until next obs
     87  INTEGER, INTENT(out) :: doexit   ! Whether to exit forecasting (1 for exit)
     88  REAL, INTENT(out)    :: timenow  ! Current model (physical) time (canbe defined freely by the user.
     89}}}
     90
     91The routine is called by Here, only the user-supplied routines are discussed that are required at this stage of the implementation (that is, the ensemble integration). For testing (see [#Compilationandtesting 'Compilation and testing']), all routines need to exist, but only those described here in detail need to be implemented with functionality.
     92
     93To indicate user-supplied routines we use the prefix `U_`. In the tutorials in `tutorial/` and in the template directory `templates/` these routines exist without the prefix, but with the extension `_pdaf`. The files are named correspondingly. In the section titles below we provide the name of the template file in parentheses.
     94
     95The user-supplied routines are in general identical for the 'fully parallel' and 'flexible' implementation variants. The only difference is in `U_next_observation` as is described below.
     96
     97=== `U_next_observation` (next_observation_pdaf.F90) ===
     98
     99The interface for this routine is
     100{{{
     101SUBROUTINE next_observation(stepnow, nsteps, doexit, timenow)
     102
     103  INTEGER, INTENT(in)  :: stepnow  ! Number of the current time step
     104  INTEGER, INTENT(out) :: nsteps   ! Number of time steps until next obs
     105  INTEGER, INTENT(out) :: doexit   ! Whether to exit forecasting (1 for exit)
     106  REAL, INTENT(out)    :: timenow  ! Current model (physical) time
     107}}}
     108
     109The routine is called once at the beginning of each forecast phase. It is executed by all processes that participate in the model integrations.
     110
     111Based on the information of the current time step, the routine has to define the number of time steps `nsteps` for the next forecast phase. For the 'fully parallel' data assimilation variant the flag `doexit` is not used and does not need to be set. `timenow` is the current model time. However, for the 'fully parallel' data assimilation variant, this value is not relevant.
     112
     113Some hints:
     114 * If the time interval between successive observations is known, `nsteps` can be simply initialized by dividing the time interval by the size of the time step
     115 * At the first call to `U_next_obs` the variable `timenow` can be initialized with the current model time. At the next call a forecast phase has been completed. Thus, the new value of `timenow` follows from the timer interval for the previous forecast phase.
     116 * `doexit` is not relevant for the fully-parallel implementation. It is recommended to set `doexit=0` in all cases.
     117 * If `nsteps=0` or `doexit=1` is set, the ensemble state will not be distributed by PDAF (thus `distribute_state` is not called). If one intends to proceed with ensemble forecasting, one has to set nsteps to a value >0 and `doexit=0`.  If nsteps is set to a value larger than the last time step of the model no further analysis step will be performed.
     118
     119=== `U_distribute_state` (distribute_state_pdaf.F90) ===
     120
     121The interface for this routine is
     122{{{
     123SUBROUTINE distribute_state(dim_p, state_p)
     124
     125  INTEGER, INTENT(in) :: dim_p           ! State dimension for PE-local model sub-domain
     126  REAL, INTENT(inout) :: state_p(dim_p)  ! State vector for PE-local model sub-domain
     127}}}
     128
     129This routine is called during the forecast phase as many times as there are states to be integrated by a model task. Again, the routine is executed by all processes that belong to model tasks.
     130
     131When the routine is called a state vector `state_p` and its size `dim_p` are provided. As the user has defined how the model fields are stored in the state vector, one can initialize the model fields from this information. If the model is not parallelized, `state_p` will contain a full state vector. If the model is parallelized using domain decomposition, `state_p` will contain the part of the state vector that corresponds to the model sub-domain for the calling process.
     132
     133Some hints:
     134 * If the state vector does not include all model fields, it can be useful to keep a separate array to store those additional fields. This array has to be kept separate from PDAF, but can be defined using a module like `mod_assimilation`.
     135
     136
     137=== `U_prepoststep` (prepoststep_ens_pdaf.F90) ===
     138
     139The interface of the routine is identical for all filters. However, the particular operations that are performed in the routine can be specific for each filter algorithm. Here, we exemplify the interface on the example of the ESTKF and LESKTF filters.
     140
     141The interface for this routine is
     142{{{
     143SUBROUTINE prepoststep(step, dim_p, dim_ens, dim_ens_p, dim_obs_p, &
     144                       state_p, Uinv, ens_p, flag)
     145
     146  INTEGER, INTENT(in) :: step        ! Current time step
     147                         ! (When the routine is called before the analysis -step is provided.)
     148  INTEGER, INTENT(in) :: dim_p       ! PE-local state dimension
     149  INTEGER, INTENT(in) :: dim_ens     ! Size of state ensemble
     150  INTEGER, INTENT(in) :: dim_ens_p   ! PE-local size of ensemble
     151  INTEGER, INTENT(in) :: dim_obs_p   ! PE-local dimension of observation vector
     152  REAL, INTENT(inout) :: state_p(dim_p) ! PE-local forecast/analysis state
     153                                     ! The array 'state_p' is not generally not initialized.
     154                                     ! It can be used freely in this routine.
     155  REAL, INTENT(inout) :: Uinv(dim_ens-1, dim_ens-1) ! Inverse of matrix U
     156  REAL, INTENT(inout) :: ens_p(dim_p, dim_ens)      ! PE-local state ensemble
     157  INTEGER, INTENT(in) :: flag        ! PDAF status flag
     158}}}
     159
     160The routine `U_prepoststep` is called once at the beginning of the assimilation process. In addition, it is called during the assimilation cycles before the analysis step and after the ensemble transformation. The routine is called by all filter processes (that is `filterpe=1`).
     161
     162The routine provides for the user the full access to the ensemble of model states. Thus, user-controlled pre- and post-step operations can be performed.  For example the forecast and the analysis states and ensemble covariance matrix can be analyzed, e.g. by computing the estimated variances. If the smoother is used, also the smoothed ensembles can be analyzed. In addition, the estimates can be written to disk.
     163
     164Hint:
     165 * If a user considers to perform adjustments to the estimates (e.g. for balances), this routine is the right place for it.
     166 * Only for the SEEK filter the state vector (`state_p`) is initialized. For all other filters, the array is allocated, but it can be used freely during the execution of `U_prepoststep`.
     167 * The interface through which `U_prepoststep` is called does not include the array of smoothed ensembles. In order to access the smoother ensemble array one has to set a pointer to it using a call to the routine `PDAF_get_smootherens` (see page on [AuxiliaryRoutines auxiliary routines])Here, only the user-supplied routines are discussed that are required at this stage of the implementation (that is, the ensemble integration). For testing (see [#Compilationandtesting 'Compilation and testing']), all routines need to exist, but only those described here in detail need to be implemented with functionality.
     168
     169To indicate user-supplied routines we use the prefix `U_`. In the tutorials in `tutorial/` and in the template directory `templates/` these routines exist without the prefix, but with the extension `_pdaf`. The files are named correspondingly. In the section titles below we provide the name of the template file in parentheses.
     170
     171The user-supplied routines are in general identical for the 'fully parallel' and 'flexible' implementation variants. The only difference is in `U_next_observation` as is described below.
     172
     173=== `next_observation_pdaf` (next_observation_pdaf.F90) ===
     174
     175The interface for this routine is
     176{{{
     177SUBROUTINE next_observation_pdaf(stepnow, nsteps, doexit, timenow)
     178
     179  INTEGER, INTENT(in)  :: stepnow  ! Number of the current time step
     180  INTEGER, INTENT(out) :: nsteps   ! Number of time steps until next obs
     181  INTEGER, INTENT(out) :: doexit   ! Whether to exit forecasting (1 for exit)
     182  REAL, INTENT(out)    :: timenow  ! Current model (physical) time
     183}}}
     184
     185The routine is called by `PDAF_init_forecast` and later at the beginning of each forecast phase. It is executed by all processes that participate in the model integrations.
     186
     187Based on the information of the current time step, the routine has to define the number of time steps `nsteps` for the next forecast phase. For the 'fully parallel' data assimilation variant the flag `doexit` is not used in the user code. `timenow` is the current model time. For the 'fully parallel' data assimilation variant, PDAF does not use this value. The user can either ignore it (setting to to 0.0), or could use it freely to indicate the model time.
     188
     189Some hints:
     190 * Usually, the time interval between successive observations is known. Then, `nsteps` can be simply initialized by dividing the time interval by the size of the time step.
     191 * At the first call to `next_observation_pdaf` the variable `timenow` can be initialized with the current model time. At the next call a forecast phase has been completed. Thus, the new value of `timenow` follows from the timer interval for the previous forecast phase and can be incremented accordingly
     192 * `doexit` is not relevant for the fully-parallel implementation. It is recommended to set `doexit=0` in all cases.
     193 * If `nsteps=0` or `doexit=1` is set, the ensemble state will not be distributed by PDAF (thus `distribute_state` is not called). If one intends to proceed with ensemble forecasting, one has to set nsteps to a value >0 and `doexit=0`.  If `nsteps` is set so that it specifies a time step larger than the last overall time step of the assimilation run, the numnber of time steps in the final forecast will be the total number of steps.
     194
     195=== `U_distribute_state` (distribute_state_pdaf.F90) ===
     196
     197The interface for this routine is
     198{{{
     199SUBROUTINE distribute_state(dim_p, state_p)
     200
     201  INTEGER, INTENT(in) :: dim_p           ! State dimension for PE-local model sub-domain
     202  REAL, INTENT(inout) :: state_p(dim_p)  ! State vector for PE-local model sub-domain
     203}}}
     204
     205This routine is called during the forecast phase as many times as there are states to be integrated by a model task. Again, the routine is executed by all processes that belong to model tasks.
     206
     207When the routine is called a state vector `state_p` and its size `dim_p` are provided. As the user has defined how the model fields are stored in the state vector, one can initialize the model fields from this information. If the model is not parallelized, `state_p` will contain a full state vector. If the model is parallelized using domain decomposition, `state_p` will contain the part of the state vector that corresponds to the model sub-domain for the calling process.
     208
     209Some hints:
     210 * If the state vector does not include all model fields, it can be useful to keep a separate array to store those additional fields. This array has to be kept separate from PDAF, but can be defined using a module like `mod_assimilation`.
     211
     212
     213=== `U_prepoststep` (prepoststep_ens_pdaf.F90) ===
     214
     215The interface of the routine is identical for all filters. However, the particular operations that are performed in the routine can be specific for each filter algorithm. Here, we exemplify the interface on the example of the ESTKF and LESKTF filters.
     216
     217The interface for this routine is
     218{{{
     219SUBROUTINE prepoststep(step, dim_p, dim_ens, dim_ens_p, dim_obs_p, &
     220                       state_p, Uinv, ens_p, flag)
     221
     222  INTEGER, INTENT(in) :: step        ! Current time step
     223                         ! (When the routine is called before the analysis -step is provided.)
     224  INTEGER, INTENT(in) :: dim_p       ! PE-local state dimension
     225  INTEGER, INTENT(in) :: dim_ens     ! Size of state ensemble
     226  INTEGER, INTENT(in) :: dim_ens_p   ! PE-local size of ensemble
     227  INTEGER, INTENT(in) :: dim_obs_p   ! PE-local dimension of observation vector
     228  REAL, INTENT(inout) :: state_p(dim_p) ! PE-local forecast/analysis state
     229                                     ! The array 'state_p' is not generally not initialized.
     230                                     ! It can be used freely in this routine.
     231  REAL, INTENT(inout) :: Uinv(dim_ens-1, dim_ens-1) ! Inverse of matrix U
     232  REAL, INTENT(inout) :: ens_p(dim_p, dim_ens)      ! PE-local state ensemble
     233  INTEGER, INTENT(in) :: flag        ! PDAF status flag
     234}}}
     235
     236The routine `U_prepoststep` is called once at the beginning of the assimilation process. In addition, it is called during the assimilation cycles before the analysis step and after the ensemble transformation. The routine is called by all filter processes (that is `filterpe=1`).
     237
     238The routine provides for the user the full access to the ensemble of model states. Thus, user-controlled pre- and post-step operations can be performed.  For example the forecast and the analysis states and ensemble covariance matrix can be analyzed, e.g. by computing the estimated variances. If the smoother is used, also the smoothed ensembles can be analyzed. In addition, the estimates can be written to disk.
     239
     240Hint:
     241 * If a user considers to perform adjustments to the estimates (e.g. for balances), this routine is the right place for it.
     242 * Only for the SEEK filter the state vector (`state_p`) is initialized. For all other filters, the array is allocated, but it can be used freely during the execution of `U_prepoststep`.
     243 * The interface through which `U_prepoststep` is called does not include the array of smoothed ensembles. In order to access the smoother ensemble array one has to set a pointer to it using a call to the routine `PDAF_get_smootherens` (see page on [AuxiliaryRoutines auxiliary routines])once at the beginning of each forecast phase. It is executed by all processes that participate in the model integrations.
     244
     245Based on the information of the current time step, the routine has to define the number of time steps `nsteps` for the next forecast phase. For the 'fully parallel' data assimilation variant the flag `doexit` is not used and does not need to be set. `timenow` is the current model time. However, for the 'fully parallel' data assimilation variant, this value is not relevant.
     246
     247Some hints:
     248 * If the time interval between successive observations is known, `nsteps` can be simply initialized by dividing the time interval by the size of the time step
     249 * At the first call to `U_next_obs` the variable `timenow` can be initialized with the current model time. At the next call a forecast phase has been completed. Thus, the new value of `timenow` follows from the timer interval for the previous forecast phase.
     250 * `doexit` is not relevant for the fully-parallel implementation. It is recommended to set `doexit=0` in all cases.
     251 * If `nsteps=0` or `doexit=1` is set, the ensemble state will not be distributed by PDAF (thus `distribute_state` is not called). If one intends to proceed with ensemble forecasting, one has to set nsteps to a value >0 and `doexit=0`.  If nsteps is set to a value larger than the last time step of the model no further analysis step will be performed.
     252
     253=== `U_distribute_state` (distribute_state_pdaf.F90) ===
     254
     255The interface for this routine is
     256{{{
     257SUBROUTINE distribute_state(dim_p, state_p)
     258
     259  INTEGER, INTENT(in) :: dim_p           ! State dimension for PE-local model sub-domain
     260  REAL, INTENT(inout) :: state_p(dim_p)  ! State vector for PE-local model sub-domain
     261}}}
     262
     263This routine is called during the forecast phase as many times as there are states to be integrated by a model task. Again, the routine is executed by all processes that belong to model tasks.
     264
     265When the routine is called a state vector `state_p` and its size `dim_p` are provided. As the user has defined how the model fields are stored in the state vector, one can initialize the model fields from this information. If the model is not parallelized, `state_p` will contain a full state vector. If the model is parallelized using domain decomposition, `state_p` will contain the part of the state vector that corresponds to the model sub-domain for the calling process.
     266
     267Some hints:
     268 * If the state vector does not include all model fields, it can be useful to keep a separate array to store those additional fields. This array has to be kept separate from PDAF, but can be defined using a module like `mod_assimilation`.
     269
     270
     271=== `U_prepoststep` (prepoststep_ens_pdaf.F90) ===
     272
     273The interface of the routine is identical for all filters. However, the particular operations that are performed in the routine can be specific for each filter algorithm. Here, we exemplify the interface on the example of the ESTKF and LESKTF filters.
     274
     275The interface for this routine is
     276{{{
     277SUBROUTINE prepoststep(step, dim_p, dim_ens, dim_ens_p, dim_obs_p, &
     278                       state_p, Uinv, ens_p, flag)
     279
     280  INTEGER, INTENT(in) :: step        ! Current time step
     281                         ! (When the routine is called before the analysis -step is provided.)
     282  INTEGER, INTENT(in) :: dim_p       ! PE-local state dimension
     283  INTEGER, INTENT(in) :: dim_ens     ! Size of state ensemble
     284  INTEGER, INTENT(in) :: dim_ens_p   ! PE-local size of ensemble
     285  INTEGER, INTENT(in) :: dim_obs_p   ! PE-local dimension of observation vector
     286  REAL, INTENT(inout) :: state_p(dim_p) ! PE-local forecast/analysis state
     287                                     ! The array 'state_p' is not generally not initialized.
     288                                     ! It can be used freely in this routine.
     289  REAL, INTENT(inout) :: Uinv(dim_ens-1, dim_ens-1) ! Inverse of matrix U
     290  REAL, INTENT(inout) :: ens_p(dim_p, dim_ens)      ! PE-local state ensemble
     291  INTEGER, INTENT(in) :: flag        ! PDAF status flag
     292}}}
     293
     294The routine `U_prepoststep` is called once at the beginning of the assimilation process. In addition, it is called during the assimilation cycles before the analysis step and after the ensemble transformation. The routine is called by all filter processes (that is `filterpe=1`).
     295
     296The routine provides for the user the full access to the ensemble of model states. Thus, user-controlled pre- and post-step operations can be performed.  For example the forecast and the analysis states and ensemble covariance matrix can be analyzed, e.g. by computing the estimated variances. If the smoother is used, also the smoothed ensembles can be analyzed. In addition, the estimates can be written to disk.
     297
     298Hint:
     299 * If a user considers to perform adjustments to the estimates (e.g. for balances), this routine is the right place for it.
     300 * Only for the SEEK filter the state vector (`state_p`) is initialized. For all other filters, the array is allocated, but it can be used freely during the execution of `U_prepoststep`.
     301 * The interface through which `U_prepoststep` is called does not include the array of smoothed ensembles. In order to access the smoother ensemble array one has to set a pointer to it using a call to the routine `PDAF_get_smootherens` (see page on [AuxiliaryRoutines auxiliary routines])