• DeterministicSimulationBlocks

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

and y to

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.

Second, 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.

Third, there is an additional interaction between endval and initval. If some variables, endogenous or exogenous, are NOT mentioned in the @code{endval} block, the value assumed is that of the last initval block or steady command (if present). Therefore, omitted variables are not automatically assumed to be 0 in this case.

Proposed design changes for 6.0:

1. Replace the current commands with alternative syntax that only assigns one purpose to each block and is more flexible.

   1. Use historical_conditions to set the historical conditions for the states and allow calling historical_conditions(steady_state) to set the initial conditions to steady states conditional on the exogenous variables, based on the starting values used in the block.

   2. Use terminal_conditions to set the terminal condition and allow it in the presence of historical_conditions

   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.

3. Clarify default behavior if one block is not present. I would propose using 0 by default. The other alternative would by the steady state, but this would be infeasible if an exogenous variable is not set.

4. The proposed changes would also simplify the structure of make_y_ and make_ex_ as we would always concatenate [historical_conditions solver_starting_values terminal_conditions]