Changes between Initial Version and Version 1 of OnlineModifyModelforEnsembleIntegration_PDAF3


Ignore:
Timestamp:
May 25, 2025, 5:27:44 PM (7 days ago)
Author:
lnerger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • OnlineModifyModelforEnsembleIntegration_PDAF3

    v1 v1  
     1= Modifying the model code for the ensemble integration =
     2
     3{{{
     4#!html
     5<div class="wiki-toc">
     6<h4>Online Mode: Implementation Guide</h4>
     7<ol><li><a href="OnlineImplementationGuide_PDAF3">Main page</a></li>
     8<li><a href="OnlineAdaptParallelization_PDAF3">Adapting the parallelization</a></li>
     9<li><a href="OnlineInitPdaf_PDAF3">Initializing PDAF</a></li>
     10<li><a href="OnlineModifyModelforEnsembleIntegration_PDAF3">Modifications for ensemble integration</a></li>
     11  <li>&nbsp;&nbsp;&nbsp;<a href="OnlineFlexible_PDAF3">Flexible implementation variant</a></li>
     12<li><a href="ImplementationofAnalysisStep_PDAF3">Implementing the analysis step</a></li>
     13<li><a href="OnlineAddingMemoryandTimingInformation_PDAF3">Memory and timing information</a></li>
     14</ol>
     15</div>
     16}}}
     17
     18[[PageOutline(2-3,Contents of this page)]]
     19
     20== Overview ==
     21
     22On the [wiki:ImplementationConceptOnline Page on the Implementation Concept of the Online Mode] we explained the modification of the model code for the ensemble integration. Here, we focus on the ''fully parallel'' implementation variant, which only needs minor code changes. In this case, the number of model tasks is equal to the ensemble size such that each model task integrates exactly one model state. In this case, the model always moves forward in time. As before, we refer to the example code for the online mode in `tutorial/online_2D_parallelmodel` and `tutorial/online_2D_serialmodel`.
     23
     24|| The more complex ''flexible'' parallelization variant is described separately on the page: [OnlineFlexible_PDAF3 Modification of the model code for the ''flexible'' implementation variant]. ||
     25
     26The extension to the model code for the ''fully parallel'' implementation is depicted in the figure below (See also the page on the [ImplementationConceptOnline implementation concept of the online mode.]) As at this stage of the implementation the calls to `init_parallel_pdaf` and `init_pdaf` are already inserted into the code, the difference is in the addition of routines for the time stepping. The parallel ensemble integration is enabled by the configuration of the parallelization that was done by `init_parallel_pdaf` in the first step of the implementation. This does not require further code changes.
     27
     28For the ''fully parallel'' parallelization variant, the number of time steps `nsteps` shown in Figure 1 is the overall length of the data assimilation run. This can include several data assimilation cycles of forecasts and analysis steps.
     29
     30[[Image(//pics/DAextension_PDAF3.png)]]
     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.
     32
     33To complete the forecasting there are three further steps required now:
     341. 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`.
     351. To enable that the analysis can be performed, we then have to insert the routine `assimilate_pdaf` into the model code.
     361. 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.
     37
     38These steps are described below.
     39
     40== Calling `PDAF_init_forecast` ==
     41
     42The routine `PDAF_init_forecast` is called at the end of the routine `init_pdaf` that was discussed on the [InitPdaf page on initializing PDAF]. The main purpose of this routine is to initialize the model fields for all model tasks from the ensemlbe of state vectors. This is done in the call-back routine `distribute_state_pdaf`. The routine also calls the call-back routine `next_observation_pdaf` to set the number of time steps for the initial forecast phase and an exit flag. These values used are internally by PDAF to control the forecast phase. Further, the routine calls the call-back-routine `prepoststep_pdaf`. This pre/postep routine provides the user access to the initial ensemble.
     43
     44The interface of `PDAF_init_forecast` is:
     45{{{
     46  SUBROUTINE PDAF_init_forecast(next_observation_pdaf, distribute_state_pdaf, &
     47                                prepoststep_pdaf, status)
     48}}}
     49with the arguments (where the bold names show the arguments relevant to the user for the ''fully-parallel'' variant):
     50 * **[#next_observation_pdafnext_observation_pdaf.F90 next_observation_pdaf]**:[[BR]] The name of a user supplied routine that initializes the number of time steps of the forecast phase.
     51 * **[#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
     52 * **[#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.
     53 * **`status`, `integer, intent(inout)`**:[[BR]] The status flag. It is zero, if the routine is exited without errors. We recommend to check the value.
     54
     55The user-supplied routines are described further below.
     56
     57
     58== Inserting `assimilate_pdaf` into the model code ==
     59
     60The right place to insert the routine `assimilate_pdaf` into the model code is at the end of the model time stepping loop, thus when the model completed the computation of a single time step. In most cases, this is just before the 'END DO' in the model source code. However, there might be special cases, where the model does some additional operations so that the call to `assimilate_pdaf` should be insered somewhat earlier.
     61
     62== Using `assimilate_pdaf` ==
     63
     64The purpose of `assimilate_pdaf` is to call the universal PDAF-core routine `PDAF3_assimilate` (or a more specific varant of this routine).  The arguments of `PDAF3_assimilate` are mainly the names of user-supplied call-back routines, except from an argument for the status flag. These names are specified in `assimilate_pdaf` as 'external'.
     65
     66The routine `assimilate_pdaf` is called at each time step of the model forecast. This allows to, e.g., apply [wiki:IncrementalAnalysisUpdates incremental analysis updates].
     67
     68Details on the implementations of the user-routines for the analysis step are provided in the following [wiki:ImplementationofAnalysisStep Page on implementating the analysis step].
     69
     70Relevant 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.
     71
     72== Completing `collect_state_pdaf`  ==
     73
     74The 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.
     75
     76The 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`.
     77
     78
     79== User-supplied routines ==
     80
     81Here, we discuss the user-supplied routines that are arguments of `PDAF_init_forecast`.
     82
     83In the section titles below we provide the name of the template file in parentheses.
     84
     85
     86
     87=== `next_observation_pdaf` (next_observation_pdaf.F90) ===
     88
     89The interface is:
     90{{{
     91SUBROUTINE next_observation_pdaf(stepnow, nsteps, doexit, timenow)
     92
     93  INTEGER, INTENT(in)  :: stepnow  ! The current time step provided by PDAF
     94  INTEGER, INTENT(out) :: nsteps   ! The number of time steps of the next forecast phase
     95  INTEGER, INTENT(out) :: doexit   ! Exit flag: (1) exit, (0) continue data assimilation
     96  REAL, INTENT(out)    :: timenow  ! Current (physical) model (physical) time. Not used by PDAF itself.
     97}}}
     98
     99The 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.
     100
     101
     102Based on the information of the current time step, the routine has to define the number of time steps `nsteps` for the next forecast phase.
     103
     104For 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.
     105
     106Some hints:
     107 * We assume that 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.
     108 * It is up to the user to define `timenow` because it is only used in the user-code. The user can either ignore it (setting to to 0.0), or could use it freely to indicate the model time. 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. In the user code, one can access `timenow` with a call to [wiki:PDAF_get_fcst_info].
     109 * In the ''fully-parallel'' implementation discussed here, `doexit` is not used in the user-code. One can safely just set it to 0.
     110 * Inside PDAF, `doexit` is used as follows: If `nsteps=0` or `doexit=1` is set, the ensemble state will not be distributed by PDAF (thus `distribute_state`, see below, is not called). If one intends to proceed with ensemble forecasting, one has to set `nsteps` to a value >0 and `doexit=0`. 
     111 * The total number of time steps set for the assimilation experiment (variable `isteps` in Fig. 1) defines when the model integrations end. If `nsteps` is set so that it specifies a time step larger than `isteps` not all of these steps will be computed.
     112
     113=== `distribute_state_pdaf` (distribute_state_pdaf.F90) ===
     114
     115The interface for this routine is
     116{{{
     117SUBROUTINE distribute_state(dim_p, state_p)
     118
     119  INTEGER, INTENT(in) :: dim_p           ! Size of state vector for process-local sub-domain
     120  REAL, INTENT(inout) :: state_p(dim_p)  ! State vector for process-local sub-domain
     121}}}
     122
     123The 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.
     124
     125PDAF calls this routine providing the state vector `state_p` and its size `dim_p`. The routine has to write the information from the state vector into the model field arrays.
     126
     127Some hints:
     128 * The user has defined the setup of the state vector, so that it is know which model fields are stored at which position in the state vector and in which order, for example, a 3-dimensional model field is stored. This was already used in `init_ens_pdaf`.
     129 * The code usually consist of (nested) loops through each of the model fields, one field at a time. In the loop each element of the state vector is written into an element of a model field array.
     130 * 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.
     131
     132
     133=== `prepoststep_pdaf` (prepoststep_ens_pdaf.F90) ===
     134
     135The interface for this routine is
     136{{{
     137SUBROUTINE prepoststep(step, dim_p, dim_ens, dim_ens_p, dim_obs_p, &
     138                       state_p, Ainv, ens_p, flag)
     139
     140  INTEGER, INTENT(in) :: step        ! Current time step
     141                         ! (When the routine is called before the analysis -step is provided.)
     142  INTEGER, INTENT(in) :: dim_p       ! Process-local state dimension
     143  INTEGER, INTENT(in) :: dim_ens     ! Size of state ensemble
     144  INTEGER, INTENT(in) :: dim_ens_p   ! Process-local ensemble size (not relevant for fully parallel)
     145  INTEGER, INTENT(in) :: dim_obs_p   ! Process-local dimension of observation vector
     146  REAL, INTENT(inout) :: state_p(dim_p) ! Process-local state vector
     147                                     ! The array 'state_p' is not generally not initialized.
     148                                     ! It can be used freely in this routine.
     149  REAL, INTENT(inout) :: Ainv(dim_ens-1, dim_ens-1) ! Inverse of matrix A )only for special cases)
     150  REAL, INTENT(inout) :: ens_p(dim_p, dim_ens)      ! State ensemble for process-local sub-domain
     151  INTEGER, INTENT(in) :: flag        ! PDAF status flag
     152}}}
     153
     154The routine `prepoststep_pdaf` 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=.true.`).
     155
     156With this routine, PDAF provides 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.
     157
     158The routine also allows to perform adjustments to the state vectors, e.g. for balances, in the ensemble.
     159
     160Hints:
     161 * 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`.
     162 * 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]).
     163
     164
     165=== `collect_state_pdaf` (collect_state_pdaf.F90) ===
     166
     167The interface for this routine is
     168{{{
     169SUBROUTINE collect_state(dim_p, state_p)
     170
     171  INTEGER, INTENT(in) :: dim_p           ! State dimension for process-local model sub-domain
     172  REAL, INTENT(inout) :: state_p(dim_p)  ! State vector for process-local model sub-domain
     173}}}
     174
     175The 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.
     176
     177PDAF 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`.
     178
     179Hint:
     180* 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.
     181
     182
     183== Compiling and testing ==
     184
     185One 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.
     186
     187The 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.
     188