• DesignIssues

Design Issues for Dynare

Global structures

• We use structures to store

  • the characteristics of the model (M_)

  • options (options_)

  • intermediary results such as decision rules (oo_.dr)

  • results made available to the users(oo_)

• The distinction between intermediary and final results is a little artificial because intermediary results such as decision rules must be made available to the users and final results are often used as input for further processing
• These structures are global in the sense that the information that they store is used by almost every function in the Dynare toolbox
• Global variables have the following drawbacks
  • they make very unclear which function modifies what;
  • in Matlab, they have an important access cost, contrarily to other languages.
• Recently, we started passing these structures as arguments in the various functions, getting them back as output argument when they are modified by a given function. It turns out that modifying a large structure passed as argument is expensive because Matlab makes a copy of the argument.
• The solution that we are currently thinking of is following:

  • Keep M_, options_, oo_ and make again dr_ global variables.

  • Create utility functions for setting and reading these global structures.

  • The variables themselves should be only accessed in these utility functions and the model *.m file.

• It would be desirable to separate the structures that have only read from or written to in the normal working of the functions of the toolbox.

  • It seems possible to make M_ read-only while all the fields are written by the preprocessor in the model *.m file.

  • options_ should contain the default value of the options, set as now in global_initialization.m, and should only be written to by a function set_option_default.m that allow the user to change the default of an option. The various functions should receive a copy of options_ modified by the local options of a given command.

  • dr_ should be written to by stoch_simul (and ramsey_policy, osr) as well as estimation.

  • oo_ is hard to specialize. By nature, a *.mod file requests intermediary output that are further processed by the next commands.

• For efficiency reason, the results from lower functions that are often called many, many times should be passed by arguments and not in dr_ or oo_. These structures should only be written to by top functions.

Breaking up dr1.m

• the dr1.m function should be broken up in the following parts:

  • an initialization setting up the indices necessary to make the basic matrices from the Jacobian and the Hessians (called once)
  • a first order approximation function (called many times)
  • a second order approximation function (called many times)

• the initialization function output needs probably to be stored in global workspace because it can be called far away from the initialization. It probably should be a structure other than dr_. It should be stored in a cell array, one entry for each model.

• The first order solution should return system matrices (A and B for the transition equation). These matrices are needed by second order approximation and by the Kalman filter. It is the output routines (disp_dr.m) that should eliminate the redundant information.

• Second order approximation (not necessarily the computation function) should make available both the second order derivatives and the Taylor coefficients.

Using several models

• Besides the basic model, we have currently the following models
  • the objective function in optimal policy
  • the sub-models after block decomposition
• we could imagine supporting as well
  • desaggregated/aggregation model
  • measurement model in partial information and/or Giannoni-Boivin type of analysis

• We need to make a distinction between what is at the level of the entire *.mod file and what belongs to specific models

• Top level:
  • symbol names and values
  • number of various types of variables
  • maximum leads and lags
• Each model level
  • indices of variables present in the sub-model
  • lead-lag incidence matrix
  • indices to setup the basic matrices
  • the resulting parameters of the partial decision rules
• The block decomposition implies an order in the resolution and the sub-models should have a numeric index. The other usages of several models indicates rather a named index. So the set of models should be kept in a structure. One field should point to a vector of sub-models issued from block-decomposition. (Potentially, we could have a block decomposition of several models)

Interaction of initval, endval, and histval for deterministic simulations

http://www.dynare.org/DynareWiki/DeterministicSimulationBlocks