Changes between Version 12 and Version 13 of ModifyModelforEnsembleIntegration

Timestamp:

Aug 27, 2010, 10:17:50 AM (14 years ago)

Author:

lnerger

Comment:

--

ModifyModelforEnsembleIntegration

@@ -78 +78 @@
 == User-supplied routines ==
 
-Here, one the user-supplied routines are discussed that are required at this stage of the implementation (that is, the ensemble integration). The routines that are required to conduct the analysis step of some filter, are described in the main section about the implementation of the analysis step. For testing (see [#Compilationandtesting 'Compilation and testing']), all routines need to exist, but only those described here in detail need to be implemted with functionality.
+Here, only the user-supplied routines are discussed that are required at this stage of the implementation (that is, the ensemble integration). The routines that are required to conduct the analysis step of some filter, are described in the main section about the implementation of the analysis step. 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.
 
 To indicate user-supplied routines we use the prefix `U_`. In the template directory `templates/` these routines are provided in files with the routines name without this prefix. In the example implementation in `testsuite/src/dummymodel_1D` the routines exist without the prefix, but with the extension `_dummy_D.F90`. In the section titles below we provide the name of the template file in parentheses.
@@ -174 +174 @@
 == 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.
+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.
 
 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.