| 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. |
| | 50 | * `nsteps`, `integer, intent(inout)`:[[BR]] The return value for the number of time steps to be performed |
| | 51 | * `timenow`, `real, intent(out)`:[[BR]] The current model time in a user-defined definition |
| | 52 | * `doexit`, `integer, intent(inout)`:[[BR]] The exit flag defining whether the assimilation process is completed. (1: exit, 0: continue). |
| | 53 | * **[#next_observation_pdafnext_observation_pdaf.F90 next_observation_pdaf]**:[[BR]] The name of a user supplied routine that initializes the variables `nsteps`, `timenow`, and `doexit` |
| | 54 | * **[#distribute_state_pdafdistribute_state_pdaf.F90 distribute_state_pdaf]**:[[BR]] 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 prepoststep_pdaf]**:[[BR]] 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`, `integer, intent(inout)`**:[[BR]] The status flag. It is zero, if the routine is exited without errors. We recommend to check the value. |
| 93 | | To 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 | | |
| 95 | | The 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 | | |
| 99 | | The interface for this routine is |
| 100 | | {{{ |
| 101 | | SUBROUTINE 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 | | |
| 109 | | The routine is called once at the beginning of each forecast phase. It is executed by all processes that participate in the model integrations. |
| 110 | | |
| 111 | | Based 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. |
| | 99 | Based 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 only used inside PDAF. |
| 144 | | state_p, Uinv, ens_p, flag) |
| | 133 | state_p, Ainv, ens_p, flag) |
| | 134 | }}} |
| | 135 | with arguments: |
| | 136 | * `step`, `INTEGER, INTENT(in)`:[[BR]] Current time step (When the routine is called for the forecast state the time steps is provided as a negative value.) |
| | 137 | * `dim_p`, `INTEGER, INTENT(in)`:[[BR]] Process-local state dimension |
| | 138 | * `dim_ens`, `INTEGER, INTENT(in)`:[[BR]] Ensemble size |
| | 139 | * `dim_ens_p`, `INTEGER, INTENT(in)`:[[BR]] Process-local ensemble size (not relevant for ''fully parallel'') |
| | 140 | * `dim_obs_p`, `INTEGER, INTENT(in)`:[[BR]] Process-local dimension of observation vector |
| | 141 | * `state_p`, `REAL, INTENT(inout), dimension(dim_p)`:[[BR]] Process-local state vector (The array 'state_p' is not generally not initialized. It can be used freely in this routine.) |
| | 142 | * `Ainv`, `REAL, INTENT(inout), dimension(dim_ens-1, dim_ens-1)`:[[BR]] Inverse of matrix A (only for special cases) |
| | 143 | * **`ens_p`, `REAL, INTENT(inout), dimension(dim_p, dim_ens)`**:[[BR]] State ensemble for process-local sub-domain |
| | 144 | * `flag`, `INTEGER, INTENT(in)`:[[BR]] PDAF status flag |
| 164 | | Hint: |
| 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 | | |
| 169 | | To 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 | | |
| 171 | | The 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 | | |
| 175 | | The interface for this routine is |
| 176 | | {{{ |
| 177 | | SUBROUTINE 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 | | |
| 185 | | The 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 | | |
| 187 | | Based 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 | | |
| 189 | | Some 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 | | |
| 197 | | The interface for this routine is |
| 198 | | {{{ |
| 199 | | SUBROUTINE 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 | | |
| 205 | | This 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 | | |
| 207 | | When 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 | | |
| 209 | | Some 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`. |
| | 152 | Hints: |
| | 153 | * The state vector, `state_p`, is usually not initialized because the ensemble DA methods focus on computing the ensemble and not its mean state. Thus the user would need to compute the ensemble mean, if this is required. This array can be used freely in `prepoststep_pdaf`. |
| | 154 | * The interface of `prepoststep_pdaf` 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]). |
| 213 | | === `U_prepoststep` (prepoststep_ens_pdaf.F90) === |
| 214 | | |
| 215 | | The 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 | | |
| 217 | | The interface for this routine is |
| 218 | | {{{ |
| 219 | | SUBROUTINE 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 | | |
| 236 | | The 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 | | |
| 238 | | The 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 | | |
| 240 | | Hint: |
| 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 | | |
| 245 | | Based 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 | | |
| 247 | | Some 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 | | |
| 255 | | The interface for this routine is |
| 256 | | {{{ |
| 257 | | SUBROUTINE 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 | | |
| 263 | | This 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 | | |
| 265 | | When 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 | | |
| 267 | | Some 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 | | |
| 273 | | The 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 | | |
| 275 | | The interface for this routine is |
| 276 | | {{{ |
| 277 | | SUBROUTINE 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 | | |
| 294 | | The 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 | | |
| 296 | | The 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 | | |
| 298 | | Hint: |
| 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]) |
