# Difference between revisions of "Analysis-Forecast Cycle Observation Impacts"

(→Practicalities) (change visibility) |
|||

Line 64: | Line 64: | ||

#The observation impact driver for the forecast cycles is activated using the [[Options#W4DPSAS_FCT_SENSITIVITY|W4DPSAS_FCT_SENSITIVITY]] cpp option. | #The observation impact driver for the forecast cycles is activated using the [[Options#W4DPSAS_FCT_SENSITIVITY|W4DPSAS_FCT_SENSITIVITY]] cpp option. | ||

#The default option is 3<sup>rd</sup>-order approximations of the squared forecast error difference <math>\delta e</math>. 1<sup>st</sup>- and 2<sup>nd</sup>-order cases can also be run by changing the parameter <span class="limeGreen">ImpOrd</span> in the routine <span class="red">obs_sen_w4dpsas_forecast.h</span> but this is recommended ''only'' for testing purposes and once you feel confident about how things work. | #The default option is 3<sup>rd</sup>-order approximations of the squared forecast error difference <math>\delta e</math>. 1<sup>st</sup>- and 2<sup>nd</sup>-order cases can also be run by changing the parameter <span class="limeGreen">ImpOrd</span> in the routine <span class="red">obs_sen_w4dpsas_forecast.h</span> but this is recommended ''only'' for testing purposes and once you feel confident about how things work. | ||

− | #The length of the analysis cycle is assigned in [[ | + | #The length of the analysis cycle is assigned in [[roms.in]] using the parameter [[Variables#ntimes_ana|NTIMES_ANA]]. |

− | #The length of the | + | #The length of the forecast cycle is assigned in [[roms.in]] using the parameter [[Variables#ntimes_ana|NTIMES_FCT]]. |

− | #The default configuration of the driver is to use a verifying analysis to compute the forecast errors as in equation (1). Two adjoint model forcing input files are required: one that corresponds to <math>\bold{C}(\bold{x}_f^j-\bold{x}_a^{j+2})</math> in equation (3) and one that corresponds to <math>\bold{C}(\bold{x}_f^{j+1}-\bold{x}_a^{j+2})</math>. These are referred to respectively as [[Variables#FCTnameB|FCTnameB]] and [[Variables#FCTnameA|FCTnameA]] in [[ | + | #The default configuration of the driver is to use a verifying analysis to compute the forecast errors as in equation (1). Two adjoint model forcing input files are required: one that corresponds to <math>\bold{C}(\bold{x}_f^j-\bold{x}_a^{j+2})</math> in equation (3) and one that corresponds to <math>\bold{C}(\bold{x}_f^{j+1}-\bold{x}_a^{j+2})</math>. These are referred to respectively as [[Variables#FCTnameB|FCTnameB]] and [[Variables#FCTnameA|FCTnameA]] in [[roms.in]]. |

− | #For forecast error metrics in observation space as in equation (4), it is necessary to also define the [[Options#OBS_SPACE|OBS_SPACE]] cpp option. In this case the input forcing files for the adjoint model have the same structure as an observation file. In the code they are referred to as [[Variables#FOInameA|FOInameA]] and [[Variables#FOInameB|FOInameB]] in [[ | + | #For forecast error metrics in observation space as in equation (4), it is necessary to also define the [[Options#OBS_SPACE|OBS_SPACE]] cpp option. In this case the input forcing files for the adjoint model have the same structure as an observation file. In the code they are referred to as [[Variables#FOInameA|FOInameA]] and [[Variables#FOInameB|FOInameB]] in [[roms.in]] corresponding to <math>\bold{C}(\bold{y}_f^{j+1}-\bold{y}^{j+2})</math> and <math>\bold{C}(\bold{y}_f^j-\bold{y}^{j+2})</math> respectively in equation (5). The actual observations assimilated during the analysis cycle prior to the forecast cycle are referred to as <span class="limeGreen">obs_C.nc</span> in the driver. |

#The options [[Options#OBS_IMPACT_SPLIT|OBS_IMPACT_SPLIT]] and [[Options#IMPACT_INNER|IMPACT_INNER]] can also be used. | #The options [[Options#OBS_IMPACT_SPLIT|OBS_IMPACT_SPLIT]] and [[Options#IMPACT_INNER|IMPACT_INNER]] can also be used. | ||

## Revision as of 15:00, 10 July 2019

## Contents

The procedure for computing the observation impacts during the forecast cycle is a little more involved than that for the analysis cycle. However, a separate ROMS driver exists for this. To help illustrate the procedure involved, consider the typical analysis-forecast cycle shown schematically below.

In the figure above, each analysis cycle is assumed to be of length and analysis cycle spans the interval . The circulation estimate at time (*i.e.* the *end* of analysis cycle ) is denoted as and is the initial condition for the forecast spanning the next analysis interval . *In the figure it is assumed, for convenience only, that the forecast duration is an integer multiple of , but this does not have to be the case, and the code is set up to handle analysis and forecast cycles that are different lengths.* The figure shows the analyses and forecasts that result from three adjacent analysis cycles, namely cycles , and cycle . The analysis at the *end* of cycle is used as the initial condition for the forecast of duration that terminates at time , the end of analysis cycle . Similarly, the analysis at the *end* of cycle is used as the initial condition for the forecast of duration and also terminates at time , the end of analysis cycle . After sufficient time has elapsed, a new analysis will be computed at this time. Since represents our best estimate of the ocean circulation at time it can be used to quantify the veracity of the forecasts and . For this reason, is usually referred to as the “verifying analysis.” However, as discussed shortly, other sources of information can be used to verify the forecasts, such as new or independent observations.

It should be clear from the figure that the forecast benefits from the observations assimilated into the model during analysis cycle (i.e. during the interval ). Therefore, providing that and are subject to *identical* surface forcing and open boundary conditions during the interval , any differences in forecast error must be associated with the observations assimilated into the model during the interval .

## Forecast Error Metrics

As in the case of the analysis cycle observation impacts described above, the impact of the observations during the forecast cycle is computed for a specific metric, in this case a metric of the forecast error. The methodology will be described first for a standard generic quadratic forecast error metric given by:

(1) |

where denotes the forecast state-vector, denotes the true state-vector, and is a weight matrix. For example, if is a diagonal matrix with elements equal to 1 corresponding to all surface temperature grid points, and zero elsewhere, then would represent the sum of the squared errors in SST. Forecast error metrics of the form (1) are very common in numerical weather prediction and oceanography, so (1) is a good starting point.

In the figure there are two forecasts of interest: initialized at the end of analysis cycle at time , and initialized at the end of analysis cycle at time . At time the error in forecast is given by , while the error in is given by . As noted above, if and are subject to *identical* surface forcing and open boundary conditions during the interval , then the difference in forecast error is due solely to the difference in the forecast initial conditions due to the observations assimilated during analysis cycle spanning the interval . (The more realistic case where the two forecasts are subject to different surface forcing fields is addressed below in the step-by-step procedure notes). Specifically, if the observations assimilated during cycle lead to an improvement in the forecast skill (*i.e.* ), while if the observations assimilated during cycle have degraded the forecast (*i.e.* ). While this convention may seem counter-intuitive, it is the convention used in the numerical weather prediction literature, so it seems prudent to adopt it here.

### Using a verifying analysis as a surrogate for the true ocean circulation

In practice, the true state will never be known, so the forecast error (1) is usually computed relative to the verifying analysis , in which case:

(2) |

where denotes the verifying analysis at the appropriate forecast time.

The 3^{rd}-order approximation for is given by:

(3) |

where represents the adjoint model run backwards over the forecast interval and linearized about the forecast solution ; is the adjoint model run backwards over the 4D-Var analysis interval and linearized about 4D-Var background ; and denotes the adjoint model linearized about the forecast solution . Thus, the 3^{rd}-order impact given by (3) requires two integrations of the adjoint model: one forced by and another forced by and linearized about different forecast solutions.

### Using the independent observations as a surrogate for the true ocean circulation

As discussed above, it is typical in operational numerical weather prediction to use the verifying analysis at the forecast time as a surrogate for the true state of the system, as in equation (2). These days operational weather prediction models generally yield very high-quality analyses, so the assumption that is a reasonable approximation for is probably reasonable. In oceanography, however, this is a more questionable assumption, so when possible, it may be more prudent to verify a forecast against independent observations, or observations that have not yet been assimilated into the model. In this case, equation (2) would be reformulated as:

(4) |

where is model forecast of the vector of verifying observations . In this case, the 3^{rd}-order approximation for becomes:

(5) |

where and denote the adjoint model *forced* at the observation points and linearized about and respectively.

## Practicalities

- The observation impact driver for the forecast cycles is activated using the W4DPSAS_FCT_SENSITIVITY cpp option.
- The default option is 3
^{rd}-order approximations of the squared forecast error difference . 1^{st}- and 2^{nd}-order cases can also be run by changing the parameter ImpOrd in the routine obs_sen_w4dpsas_forecast.h but this is recommended*only*for testing purposes and once you feel confident about how things work. - The length of the analysis cycle is assigned in roms.in using the parameter NTIMES_ANA.
- The length of the forecast cycle is assigned in roms.in using the parameter NTIMES_FCT.
- The default configuration of the driver is to use a verifying analysis to compute the forecast errors as in equation (1). Two adjoint model forcing input files are required: one that corresponds to in equation (3) and one that corresponds to . These are referred to respectively as FCTnameB and FCTnameA in roms.in.
- For forecast error metrics in observation space as in equation (4), it is necessary to also define the OBS_SPACE cpp option. In this case the input forcing files for the adjoint model have the same structure as an observation file. In the code they are referred to as FOInameA and FOInameB in roms.in corresponding to and respectively in equation (5). The actual observations assimilated during the analysis cycle prior to the forecast cycle are referred to as obs_C.nc in the driver.
- The options OBS_IMPACT_SPLIT and IMPACT_INNER can also be used.

## Step-by-Step Procedure

- Run 4D-Var for the analysis cycle and save the MODname.nc and FWDname.nc files.
- Run the forecast initialized from the 4D-Var analysis at the
*end*of the analysis cycle and write the surface fluxes and wind stress to the HISname.nc file. Also ensure that you*define*FORWARD_WRITE and VERIFICATION, and save the MODname.nc and HISname.nc files. - Rerun step 2
BULK_FLUXES and instead use the saved surface fluxes and wind stress in the history file from step 2 to force the model. This represents the forecast in equation (3) (**without***i.e.*the red curve in the figure). This step is necessary because the forecast run using the background in step 4 below to generate must also be subject to the same surface fluxes, wind stress, and open boundary conditions. Any difference in the forecast errors in and those from the forecast in step 2 will be due to the differences in the surface boundary conditions. As in step 2, ensure that you*define*FORWARD_WRITE and VERIFICATION, and save the MODname.nc and HISname.nc files. - Run a forecast
BULK_FLUXES initialized from the 4D-Var**without***background*solution at the*end*of the 4D-Var window using the saved surface fluxes and wind stress in the history file from step 2 to force the model. This represents the forecast in equation (3) (*i.e.*the portion of the blue curve in the figure spanning the interval ).**Recall that in order for equation (3) to hold, and must be subject to the same surface and open boundary conditions. Steps 2, 3 and 4 ensure this.**As in step 2, ensure that you*define*FORWARD_WRITE and VERIFICATION, and save the MODname.nc and HISname.nc files. - When the verification time arrives, compute the verifying 4D-Var analysis, in equation (3).
- Using the FWDname.nc and MODname.nc files from steps 3 and 4, prepare the adjoint forcing file FCTnameA corresponding to in equation (3) and FCTnameB corresponding to if using the verifying analysis as a surrogate for the true ocean state. Similarly, if using independent or unassimilated observations as a surrogate for the true ocean state, prepare the adjoint forcing files in observation space FOInameA and FOInameB corresponding to and respectively in equation (5).
- Run the forecast observation impact driver.