Differences between revisions 2 and 3
Revision 2 as of 2014-03-03 13:30:01
Size: 6748
Comment: Elaborate on Problem
Revision 3 as of 2016-03-23 19:56:41
Size: 6320
Comment: Draft Summary of Discussion with Michel and Stephane
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:
  * Main Purpose: set initial conditions at t=-2 to t=0 for respective specified values. All unspecified values are kept at zero.
  * Interaction with {{{steady}}}: use specified exogenous values to compute conditional steady state for endogenous variables and set t=-2 to t=0 to these values
  * Main Purpose: set initial conditions for solver for t=1 to t=100 for respective specified values. All unspecified values are kept at zero.
  * Interaction with {{{steady}}}: use specified exogenous values to compute conditional steady state for endogenous variables and set all time periods to these values
Line 20: Line 20:
   i. set terminal values for the endogenous variables (t=101 to 103) and the starting values for the optimizer from t=1 to t=100 to the specified values.
   i. set exogenous variables variables for simulation period from t=1 to t=103 to specified values.
   i. set terminal values for the endogenous variables (t=101 to 103) and the historical values for the state variables at t=-2 to t=0 to the specified values.
   i. set exogenous variables variables for simulation period from t=-2 to t=103 to specified values unless overwritten by other blocks. This is often used for permanent shocks
Line 71: Line 71:
  {\bar y \: given \: x=1.2 \: for \: t = 1} \\   {\bar y \: given \: x=1.1 \: for \: t = 1} \\
Line 97: Line 97:
That is, {{{initval}}} now takes over the function of setting the terminal steady state. At the same time, all initial values need to be entered explicitly as {{{initval}}} does not work with {{{steady}}}. That is, {{{initval}}} now takes over the function of setting the terminal steady state. At the same time, all initial values need to be entered explicitly as {{{histval}}} does not work with {{{steady}}}.
Also, in general the order of blocks is important, because it can change the meaning. This is a bad design choice.
Line 99: Line 100:
== Potential Improvements: ==
 1. Keep functionality of blocks constant regardless of other blocks. This minimizes interactions.
  a. even in the presence of a {{{histval}}}-block, {{{initval}}} should set the initial conditions. {{{histval}}} then selectively overrides those initial values (requires {{{initval}}} always before {{{histval}}})
  a. this would then allow using {{{endval}}} to set the terminal steady state even in the presence of {{{histval}}}
 1. Restrict the functionality of the blocks to what their name says and add dedicated blocks for auxiliary functions
  a. {{{initval}}}, {{{endval}}}, and {{{histval}}} only set initial and terminal conditions
  a. add blocks or functionality for setting exogenous variables that are constant at a particular value for the simulation periods from t=1 to 100. This functionality is basically already there with the {{{shocks}}}-block and is rather dirtily hacked by using {{{initval}}} and {{{endval}}} to set permanent values
  a. Add block to specify starting values. This block could allow specifying them explicitly or selecting the initial or terminal steady state (basically what {{{initval}}} if present alone and {{{endval}}} already do). Moreover, one could allow for using the steady state conditional on the specified exogenous variables, which could be useful if a {{{steady_state_model}}}-block is present
 1. allow {{{histval}}} with {{{steady}}}. This would prevent users from being forced to enter all endogenous variables manually.
 1. Potentially make {{{endval}}} also set initial conditions in the same way {{{initval}}} sets terminal conditions already (0 often is a poor initial condition) or always require {{{initval}}}-block.
Additionally, in the presence of a steady state file, the user has no control over whether the initial/terminal condition is set at the specified values in a {{{initval/endval}}} block or at the steady state given the exogenous variables in these blocks, because {{{make_y_}}} will always set them to the conditional steady state, implicitly triggering a call to {{{steady}}}.
Line 110: Line 102:
Problems with the above suggestions:
   1. backward compatibility
   2. forces users to always specify {{{initval}}}, {{{endval}}}, and {{{shocks}}}-blocks. I see this as an advantage as it cleans up mod-files by making transparent which elements belong to the problem and need to be specified. If needed, one could still emulate the old behavior by allowing for an initial-value option for {{{endval}}} to emulate what happens if {{{endval}}} was not present and a terminal value option of {{{shocks}}} to emulate what happens when {{{endval}}} and no {{{shocks}}} block was present.
== Proposed design changes for 4.6: ==
 1. Replace the current commands with alternative syntax that only assigns one purpose to each block and is more flexible.
  a. Use {{{histval}}} to set the historical conditions for the states and allow calling {{{steady}}} after the block to set the initial conditions to steady states conditional on the exogenous variables
  a. Use {{{endval}}} to set the terminal condition and allow it in the presence of {{{histval}}}
  a. Add a {{{solver_starting_values}}}-block that allows specifying the starting values for the solver. It should allow for options like {{{initial_condition}}},{{{terminal_condition}}}, {{{interpolation}}} (to use a straight line between initial and terminal conditions) and {{{steady_state_conditional_on_exogenous}}} (useful if a {{{steady_state_model}}}-block is present) with a syntax like the {{{estimated_params_init}}}-block. The user should be able to provide dedicated starting values with a syntax as in the {{{shocks}}}-block.
  a. Potentially add a {{{permanent_shock}}}-command to mimic what {{{initval}}} already allows, although it might be better to force users to specify this in the {{{shocks}}}-block
 2. Prevent presence of {{{steady_state}}}-file from interfering with meaning of a given command.

Interaction of initval, endval, and histval for deterministic simulations

The generic setup to to think about this issue is one of finding the optimal path for the endogenous variables, denoted here with y, given the path for exogenous variables, denoted with x. In addition, the endogenous variables are separated into backward- and forward-looking ones, y_forward and y_backward. Due to the presence of those variables, initial and terminal conditions are required.

For the sake of concreteness, assume the horizon is periods=100 and max_endo_lead=3 and max_endo_lag=3.

Dynare transforms this problem into one with 1 lead and lag by using auxiliary variables.

Functionality of Different Blocks

Here is what the respective Dynare blocks do:

  1. General Initialization:
    • periods -2 to 103 are set to +0
  2. initval-block

    • Main Purpose: set initial conditions for solver for t=1 to t=100 for respective specified values. All unspecified values are kept at zero.
    • Interaction with steady: use specified exogenous values to compute conditional steady state for endogenous variables and set all time periods to these values

    • Auxiliary Purposes:
      1. set terminal values for the endogenous variables (t=101 to 103) and the historical values for the state variables at t=-2 to t=0 to the specified values.
      2. set exogenous variables variables for simulation period from t=-2 to t=103 to specified values unless overwritten by other blocks. This is often used for permanent shocks
  3. endval-block

    • Main Purpose: set terminal conditions at t=101 to t=103 for respective specified values. All unspecified values are kept at zero.
    • Interaction with steady: use specified exogenous values to compute conditional steady state for endogenous variables and set t=101 to t=103 to these values

    • Auxiliary Purposes:
      1. set the starting values for the optimizer from t=1 to t=100 to the specified values; without initval, t=-2 to t=0 initial conditions stay at 0

      2. Set exogenous variables variables for simulation period from t=1 to t=100 to specified values, thereby overriding initval's values

  4. histval-block

    • Main Purpose: sets initial conditions at t=-2 to t=0 for respective specified values. All unspecified values are kept at zero, even if initval is present

    • Interaction with steady: none. In contrast to other blocks, providing only exogenous variables and then computing a conditional steady state is not possible

    • currently excludes use of endval: after the last period specified in histval, the values from initval are used

  5. shocks-block

    • Main Purpose: sets values for exogenous variables for t=1 to t=100 for respective specified values. All unspecified values are kept at the values they inherit from either initval or endval.

The Problem

The auxiliary functionality of setting exogenous variables to the specified values even outside of the time periods for which the respective block is specified makes it confusing for users and is restrictive. In particular, depending on the presence of histval, initval changes its meaning, because:

  1. initial steady state + terminal steady state : initval + endval

  2. arbitrary initial condition + terminal steady state: histval + initval

Consider the example:

initval;
x = 1;
end;
steady;

endval;
x = 1.1;
steady;

shocks;
var x;
periods 1;
values 1.2;
end;

This sets x to

\[x = \left\{ {\begin{array}{*{20}{c}}
  {1 \: for \: t =  - 2 \: to \: t = 0} \\
  {1.2 \: for \: t = 1} \\
  {1.1 \: for \: t = 2 \: to \: t = 103}
\end{array}} \right.\]

and y to

\[y = \left\{ {\begin{array}{*{20}{c}}
  {\bar y \: given \: x=1 \: for \:t =  - 2 \: to \: t = 0} \\
  {\bar y \: given \: x=1.1 \: for \: t = 1} \\
  {\bar y \: given \: x=1.1 \: for \: t = 2 \: to \: t = 103}
\end{array}} \right.\]

Doing the same in the presence of histval requires

initval;
x = 1.1;
end;
steady;

histval;
x(-2) = 1;
x(-1) = 1;
x(-0) = 1;
y(-2) = ...;
y(-1) = ...;
y(-0) = ...;
end;

shocks;
var x;
periods 1;
values 1.2;
end;

That is, initval now takes over the function of setting the terminal steady state. At the same time, all initial values need to be entered explicitly as histval does not work with steady. Also, in general the order of blocks is important, because it can change the meaning. This is a bad design choice.

Additionally, in the presence of a steady state file, the user has no control over whether the initial/terminal condition is set at the specified values in a initval/endval block or at the steady state given the exogenous variables in these blocks, because make_y_ will always set them to the conditional steady state, implicitly triggering a call to steady.

Proposed design changes for 4.6:

  1. Replace the current commands with alternative syntax that only assigns one purpose to each block and is more flexible.
    1. Use histval to set the historical conditions for the states and allow calling steady after the block to set the initial conditions to steady states conditional on the exogenous variables

    2. Use endval to set the terminal condition and allow it in the presence of histval

    3. Add a solver_starting_values-block that allows specifying the starting values for the solver. It should allow for options like initial_condition,terminal_condition, interpolation (to use a straight line between initial and terminal conditions) and steady_state_conditional_on_exogenous (useful if a steady_state_model-block is present) with a syntax like the estimated_params_init-block. The user should be able to provide dedicated starting values with a syntax as in the shocks-block.

    4. Potentially add a permanent_shock-command to mimic what initval already allows, although it might be better to force users to specify this in the shocks-block

  2. Prevent presence of steady_state-file from interfering with meaning of a given command.

DynareWiki: DeterministicSimulationBlocks (last edited 2022-10-14 10:48:57 by JohannesPfeifer)