Changes between Version 19 and Version 20 of ModifyModelforEnsembleIntegration

Timestamp:

Sep 3, 2010, 4:04:00 PM (14 years ago)

Author:

lnerger

Comment:

--

ModifyModelforEnsembleIntegration

@@ -133 +133 @@
  * 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`.
 
+
 === `U_prepoststep` (prepoststep_seik.F90) ===
 
@@ -149 +150 @@
   INTEGER, INTENT(in) :: dim_obs_p   ! PE-local dimension of observation vector
   REAL, INTENT(inout) :: state_p(dim_p) ! PE-local forecast/analysis state
-                         ! The array 'state_p' is not generally not initialized in the case of SEIK.
-                         ! It can be used freely here.
+                                     ! The array 'state_p' is not generally not initialized in the case of SEIK/EnKF/ETKF.
+                                     ! It can be used freely in this routine.
   REAL, INTENT(inout) :: Uinv(dim_ens-1, dim_ens-1) ! Inverse of matrix U
   REAL, INTENT(inout) :: ens_p(dim_p, dim_ens)      ! PE-local state ensemble
@@ -162 +163 @@
 Hint:
  * If a user considers to perform adjustments to the estimates (e.g. for balances), this routine is the right place for it.
+ * 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`.
 
 
@@ -187 +189 @@
 == Compilation and testing ==
 
-To compile the extended model code with PDAF, one has to extend the Makefile for the model by adding the additional user-supplied routines. While all of the user-supplied routines need to exist not all of them need to be fully implemented at this time if the following procedure is used. The routines that will not be called are `U_init_dim_obs`, `U_obs_op`, `U_init_obs`, `U_prodRinvA`, `U_init_obsvar`. A simple way to provide them for the compilation could be to copy the corresponding files from the template directory `templates/` and to compile these files. These templates are simple stubs without any functionality.
+To compile the extended model code with PDAF, one has to extend the Makefile for the model by adding the additional user-supplied routines. While all of the user-supplied routines need to exist not all of them need to be fully implemented at this time if the following procedure is used. The routines that will not be called are `U_init_dim_obs`, `U_obs_op`, `U_init_obs`, `U_prodRinvA`, `U_init_obsvar`. A simple way to provide them for the compilation could be to copy the corresponding files (i.e. named without `U_`) from the template directory `templates/` and to include these files in the compilation and linking. These templates are simple stubs without any functionality.
 
 At this implementation stage one can use the preprocessor definition `PDAF_NO_UPDATE` (available from Version 1.6.1). With this, the actual analysis step of the chosen filter algorithm is not executed. Accordingly, only the user-supplied routines used in `PDAF_get_state` as well as the routine `U_collect_state` need to be implemented with functionality. The other routines will not be executed, because they are only called during the analysis step. Generally with `PDAF_NO_UPDATE` the program performs just an ensemble integration. That is, PDAF is initialized by `PDAF_init`. Then a forecast is computed by using `PDAF_get_state` and the chosen `PDAF_put_state_*` routine. At the initial time `U_prepoststep` is executed by `PDAF_get_state`. `U_next_obs` will provide the number of time steps to be computed by the model and `U_distributed_state` will initialize the model fields. Subsequently the ensemble integration is performed and the forecast fields are written back to the ensemble array by `U_collect_state`. Upon completion of the forecast phase, the routine `U_prepoststep` is executed twice. The first time is the regular call before the analysis is executed. Thus, it allows to access the forecast ensemble. If the analysis would not be deactivated, the second call to `U_prepoststep` would be after the analysis allowing access to the ensemble directly after the analysis. As the analysis is deactivated here, the ensemble will be the same as in the first call.