= 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]]