Changes between Version 3 and Version 4 of InsertAnalysisStep

Timestamp:

Apr 29, 2014, 4:49:30 PM (11 years ago)

Author:

lnerger

Comment:

--

InsertAnalysisStep

@@ -41 +41 @@
  * `nsteps`: An integer specifying upon exit the number of time steps to be performed
  * `timenow`: A real specifying upon exit the current model time. (This value is usually not used in the fully-parallel implemenation variant)
- * `doexit`: An integer variable defining whether the assimilation process is completed and the program should exit the while loop. For compatibility 1 should be used for exit, 0 for continuing in the loop. (This value is not used in the fully-parallel implemenation variant)
+ * `doexit`: An integer variable defining whether the assimilation process is completed. For compatibility 1 should be used for exit, 0 for continuing. (This value is not used in the fully-parallel implemenation variant)
  * [#U_next_observationnext_observation.F90 U_next_observation]: The name of a user supplied routine that initializes the variables `nsteps`, `timenow`, and `doexit`
  * [#U_distribute_statedistribute_state.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
@@ -96 +96 @@
 The routine is called once at the beginning of each forecast phase. It is executed by all processes that participate in the model integrations.
 
-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. In addition, the flag `doexit` has to be initialized to provide the information if the external ensemble loop can be exited. `timenow` is the current model time. This variable should also be initialized. It is particularly important, if an ensemble task integrates more than one model state. In this case `timenow` can be used to correctly jump back in time. 
+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 assimialtion variant the flag `doexit` is not used. `timenow` is the current model time. However, for the 'fully parallel' data assimilation variant, this value is not relevant.
 
 Some hints: 
  * 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
- * `doexit` should be 0 to continue the assimilation process. In most cases `doexit` is set to 1, when `PDAF_get_state` is called after the last analysis for which observations are available. 
- * At the first call to `U_next_obs` the variable `timenow` should 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.
+ * 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.
 
 === `U_distribute_state` (distribute_state_pdaf.F90) ===
@@ -173 +172 @@
 == Simulating model errors ==
 
-The implementation of the filter algorithms does not support the specification of a model error covariance matrix. This was left out, because in the SEEK and SEIK filter, the handling can be extremely costly, as the model error covariance matrix has to be projected onto the ensemble space. Instead PDAF support the simulation of model errors by disturbing fields during the model integration. For this, some routine will be required that is inserted into the time stepping loop of the model. As this procedure is specific to each model, the is no routine provided by PDAF for this. 
+The implementation of the filter algorithms does not support the specification of a model error covariance matrix. This was left out, because in the SEEK and SEIK filter, the handling can be extremely costly, as the model error covariance matrix has to be projected onto the ensemble space. Instead PDAF support the simulation of model errors by disturbing fields during the model integration. For this, some routine will be required that is inserted into the time stepping loop of the model, or into `assimilate_pdaf`. As this procedure is specific to each model, the is no routine provided by PDAF for this. 
 
 == Compilation and testing ==
@@ -184 +183 @@
  * Is `U_prepoststep` working correctly?
  * Does `U_next_observation` work correctly and is the information from this routine used correctly for the model integration
- * Are `U_distribute_state` and `U_collect_state` work correctly?
+ * Do `U_distribute_state` and `U_collect_state` work correctly?
 One could also comment out the actual time stepping part of the model. This would allow to only test the interfacing between PDAF and the model.
-
-It is important to ensure that the ensemble integration performs correctly. The simplest case should be a parallel configuration in which the number of model tasks equals the ensemble size as here the model tasks always compute forward in time. If the number of model tasks is smaller than the ensemble size, some model tasks will have to integrate multiple states of the ensemble. If a model task has to integrate two states, the model will have to jump back in time for the integration of the second state. It might be that some arrays of the model need to be re-initialized to ensure that the second integration is consistent. Also, one might need to check if the initialization of forcing fields (e.g. wind stress over the ocean) performs correctly for the second integration. (Sometimes model are implemented with the constraint that the model time always increases, which is the normal case for pure model simulations without assimilation.) A useful test is to initialize an ensemble in which all states are equal. If this ensemble is integrated the forecast states of the ensemble should, of course, still be equal.