Changes between Version 39 and Version 40 of ModifyModelforEnsembleIntegration

Timestamp:

May 24, 2025, 1:43:57 PM (8 days ago)

Author:

lnerger

Comment:

--

ModifyModelforEnsembleIntegration

@@ -31 +31 @@
 [[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. ''isteps'' is the total number of time steps in the assimialtion program.
 
-There are two further steps required now:
+To complete the forecasting there are three further steps required now:
 1. 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`.
 1. To enable that the analysis can be performed, we then have to insert the routine `assimilate_pdaf` into the model code.
+1. To be able to test whether the forecasting works correctly we also recommend to implement the routine `collect_state_pdaf` at this point. The routine is used in `assimilate_pdaf` to write the forecasted model fields into a state vector. 
 
 Both are described below.
@@ -65 +66 @@
 The routine `assimilate_pdaf` is called at each time step of the model forecast. This allows to, e.g., apply [wiki:IncrementalAnalysisUpdates incremental analysis updates].
 
-Details on the implementations of the user-routines for the analysis step ar provided in the following [wiki:ImplementationofAnalysisStep Page on implementating the analysis step].
+Details on the implementations of the user-routines for the analysis step are provided in the following [wiki:ImplementationofAnalysisStep Page on implementating the analysis step].
 
+Relevant for the forecasting is that `PDAF3_assimilate` calls the user-supplied routine `collect_state_pdaf` which writes forecasted model fields into a state vector from PDAF's ensemble array. We recommend to implement the functionality in `collect_state_pdaf` at this point, even though we explain `PDAF3_assimilation` only later. 
+
+== Completing `collect_state_pdaf`  ==
+
+The routine `collect_state_pdaf` (In file collect_state_pdaf.F90 in the tutorials and template), is called during the forecast phase for each state vector of the ensemble to write the forecasted model fields back into a state vector. This is the reserve operation to what is done in `distribute_state_pdaf`. The routine is executed by all processes that belong to model tasks.
+
+The full interface of this call-back routine is explained further below with the other user-supplied routines. When the functionality is implemented, one can test the forecasting. In particular one can already test funtionality in `prepoststep_pdaf` because PDAF will provide this routine with the ensemble array that was filled with the information from model fields by calls to `collect_state_pdaf`.
 
 
@@ -91 +99 @@
 The routine is called by `PDAF_init_forecast` and later at the beginning of each forecast phase by `PDAF3_assimilate`, or similar routines. It is executed by all processes that participate in the model integrations.
 
-For the ``fully parallel`` implementation variant, the main variable to be returned is the number of time steps in the next forecast phase.
 
-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'' implementation variant, the flag `doexit` is only used inside PDAF.
+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'' implementation variant, the main variable to be returned is `nsteps`, the number of time steps in the next forecast phase. The flag `doexit` is only used inside PDAF for the ''fully parallel'' implementation variant.
 
 Some hints: 
@@ -154 +163 @@
 
 
+=== `collect_state_pdaf` (collect_state_pdaf.F90) ===
+
+The interface for this routine is
+{{{
+SUBROUTINE collect_state(dim_p, state_p)
+
+  INTEGER, INTENT(in) :: dim_p           ! State dimension for process-local model sub-domain
+  REAL, INTENT(inout) :: state_p(dim_p)  ! State vector for process-local model sub-domain
+}}}
+
+The routine is called by `PDAF3_assimilate`, or similar assimilate routine, for each ensemble state for which a forecast was computed . It is executed by all processes that participate in the model integrations.
+
+PDAF calls this routine providing the state vector `state_p` and its size `dim_p`. The routine has to write the information from the model fields into this state vector. This is the reverse operation to that of the routine `distribute_state_pdaf`. 
+
+Hint:
+* 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.
+
+
 == Compiling and testing ==
 
-One can test the program without hacing implemented the actual assimilation step. In the template code `template/online` all required user-supplied routines are included, but they don't contain functionality. However, one can use them to be able to compile and run the assimilation program for testing. In particular one can check if the ensemble forecasting works correctly. 
+One can test the program without having implemented the actual assimilation step. In the template code `template/online` all required user-supplied routines are included, but they do not contain functionality. However, one can use them to be able to compile and run the assimilation program for testing. In particular one can check if the ensemble forecasting works correctly. 
 
-However, one can only check this in the model code at this point because the forecasted model fields are not yet written back into the state vectors. This will be implemented in the routine `collect_state_pdaf` for the analysis step.
+The flow of the modified model is now the following: `distribute_state_pdaf` provides each model task with a model state that is to be integrated. Having computed the forecast, `collect_state_pdaf` writes the propagated model fields back into a state vector from the ensemble array of PDAF. This array is then provided to `prepoststep_pdaf`. Thus, one can check if the forecasting works correctly. In `prepoststep_pdaf` one can access the ensemble. Here one can, e.g. compute the ensemble mean - thus the state estimate of the ensemble assimilation - and write this into a file.
+