Design Issues for Dynare
- We use structures to store
the characteristics of the model (M_)
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)