Edit on GitHub

Model Implementation Details

This section describes important functions and implementation features in greater detail. If the user is interested only in running the default model and reproducing the estimation results, this section can be ignored. Additional documentation can also be found in function documentation or in-line.

This section focuses on what the code does and why. Docstrings and the code itself (including comments) provide detailed information regarding how these basic procedures are implemented.

As of DSGE.jl v0.7.3, many types housed in the DSGE.jl package have been moved to ModelConstructors.jl. The following types now belong in ModelConstructors.jl:

  • AbstractModel
  • AbstractParameter
    • Parameter{T<:Number, U<:Transform}: The abstract supertype for parameters that are directly estimated.
      • UnscaledParameter{T<:Number, U:<Transform}: Concrete type for parameters that do not need to be scaled for equilibrium conditions.
      • ScaledParameter{T<:Number, U:<Transform}: Concrete type for parameters that are scaled for equilibrium conditions.
    • SteadyStateParameter{T<:Number}: Concrete type for steady-state parameters.
  • Setting
  • Observable
  • PseudoObservable
  • Types and functions used to define and work with priors

We refer users to the documentation provided for ModelConstructors.jl for information about the implementation of these types. Below, we document the implementation of DSGE.jl specific types.

The AbstractDSGEModel Type

The AbstractModel type has been rewritten to be an abstract type for any model with parameters. We have replaced the AbstractModel type in DSGE.jl with the AbstractDSGEModel type, which is a subtype of AbstractModel and includes various methods that standard DSGE models need.

The AbstractDSGEModel type provides a common interface for all DSGE model objects, which greatly facilitates the implementation of new model specifications. Any concrete subtype of AbstractDSGEModel can be passed to any function defined for AbstractDSGEModel, provided that the concrete type has the fields that the function expects to be available.

Model990 is one example of a concrete subtype of AbstractDSGEModel that implements a single specification of the New York Fed DSGE model. All model objects must have these fields so that the interface for AbstractDSGEModel objects works correctly. See Editing or Extending a Model for more detail.

DSGE.Model990 — Type
Model990{T} <: AbstractRepModel{T}

The Model990 type defines the structure of the New York Fed DSGE model.

Fields

Parameters and Steady-States

  • parameters::Vector{AbstractParameter}: Vector of all time-invariant model parameters.

  • steady_state::Vector{AbstractParameter}: Model steady-state values, computed as a function of elements of parameters.

  • keys::OrderedDict{Symbol,Int}: Maps human-readable names for all model parameters and steady-states to their indices in parameters and steady_state.

Inputs to Measurement and Equilibrium Condition Equations

The following fields are dictionaries that map human-readable names to row and column indices in the matrix representations of of the measurement equation and equilibrium conditions.

  • endogenous_states::OrderedDict{Symbol,Int}: Maps each state to a column in the measurement and equilibrium condition matrices.

  • exogenous_shocks::OrderedDict{Symbol,Int}: Maps each shock to a column in the measurement and equilibrium condition matrices.

  • expected_shocks::OrderedDict{Symbol,Int}: Maps each expected shock to a column in the measurement and equilibrium condition matrices.

  • equilibrium_conditions::OrderedDict{Symbol,Int}: Maps each equlibrium condition to a row in the model's equilibrium condition matrices.

  • endogenous_states_augmented::OrderedDict{Symbol,Int}: Maps lagged states to their columns in the measurement and equilibrium condition equations. These are added after gensys solves the model.

  • observables::OrderedDict{Symbol,Int}: Maps each observable to a row in the model's measurement equation matrices.

  • pseudo_observables::OrderedDict{Symbol,Int}: Maps each pseudo-observable to a row in the model's pseudo-measurement equation matrices.

Model Specifications and Settings

  • spec::String: The model specification identifier, "m990", cached here for filepath computation.

  • subspec::String: The model subspecification number, indicating that some parameters from the original model spec ("ss3") are initialized differently. Cached here for filepath computation.

  • settings::Dict{Symbol,Setting}: Settings/flags that affect computation without changing the economic or mathematical setup of the model.

  • test_settings::Dict{Symbol,Setting}: Settings/flags for testing mode

Other Fields

  • rng::MersenneTwister: Random number generator. Can be is seeded to ensure reproducibility in algorithms that involve randomness (such as Metropolis-Hastings).

  • testing::Bool: Indicates whether the model is in testing mode. If true, settings from m.test_settings are used in place of those in m.settings.

  • observable_mappings::OrderedDict{Symbol,Observable}: A dictionary that stores data sources, series mnemonics, and transformations to/from model units. DSGE.jl will fetch data from the Federal Reserve Bank of St. Louis's FRED database; all other data must be downloaded by the user. See load_data and Observable for further details.

  • pseudo_observable_mappings::OrderedDict{Symbol,PseudoObservable}: A dictionary that stores names and transformations to/from model units. See PseudoObservable for further details.

source

Defining Indices

The model's equilibrium conditions and observables are represented as fairly large matrices, and keeping track of which rows and columns correspond to which states, shocks, equations, etc. can be confusing. To improve clarity, we define several dictionaries that map variable names to indices in these matrices:

  • endogenous_states: Indices of endogenous model states
  • exogenous_shocks: Indices of exogenous shocks
  • expected_shocks: Indices of expectation shocks
  • equilibrium_conditions: Indices of equilibrium condition equations
  • endogenous_states_augmented: Indices of model states, after model solution and system augmentation
  • observables: Indices of named observables

This approach has a number of advantages. Most importantly, it is robust to inadvertent typos or indexing errors. Since the actual index number doesn't matter to us, the user only needs to define the names of their equilibrium conditions, states, and other variables. Adding states is easy - we have only to add them to the appropriate list in the model constructor, and they will be assigned an index.

As an example, consider the model's equilibrium conditions. The canonical representation of the equilibrium conditions is

Γ0 s_t = Γ1 s_{t-1} + C + Ψ ε_t + Π η_t

where Γ0, Γ1, C, Ψ, and Π are matrices of coefficients for s_t (states at time t), s_{t-1} (lagged states), ε_t (exogenous shocks) and η_t (expectational shocks). Each row of these matrices corresponds to an equilibrium condition, which we define using a descriptive name (for example, we name the consumption Euler equation :euler). States (columns of Γ0 and Γ1), exogenous shocks (columns of Ψ), and expectational shocks (columns Π) also have names.

Type Interfaces

AbstractDSGEModel Interface

DSGE.update! — Function
update!(m::AbstractDSGEModel, values::Vector{T}) where T<:AbstractFloat

Update m.parameters with values, recomputing the steady-state parameter values.

Arguments:

  • m: the model object
  • values: the new values to assign to non-steady-state parameters.
source
update!(m::AbstractDSGEModel, values::ParameterVector{T};
    regime_switching::Bool = false, toggle::Bool = true) where T

Update m.parameters with values, recomputing the steady-state parameter values.

Arguments

  • m: the model object
  • values: the new values to assign to non-steady-state parameters.

Keyword

  • regime_switching: if true, then we assume the parameters are regime-switching, in which case update! assumes the value field of each parameter in valuesholds the parameter value in the first regime, and then we update the fieldregimes` for each parameter
  • toggle: if true, we call ModelConstructors.toggle_regime!(values) before updating any values to ensure the value field of the parameters in values correspond to regime 1 values.
source
DSGE.transform_to_model_space! — Function
transform_to_model_space!(m::AbstractDSGEModel, values::Vector{T}; regime_switching::Bool = false) where T<:AbstractFloat

Transforms values from the real line to the model space, and assigns values[i] to m.parameters[i].value for non-steady-state parameters. Recomputes the steady-state parameter values.

Arguments

  • m: the model object
  • values: the new values to assign to non-steady-state parameters.
  • regime_switching: set to true if the model's parameters are regime-switching
source
transform_to_model_space!(m::AbstractDSGEVARModel, values::Vector{T}) where T<:AbstractFloat

Transforms values from the real line to the model space, and assigns values[i] to m.parameters[i].value for non-steady-state parameters. Recomputes the steady-state paramter values.

Arguments

  • m: the model object
  • values: the new values to assign to non-steady-state parameters.
source
DSGE.load_parameters_from_file — Function
load_parameters_from_file(m::AbstractDSGEModel,path::String)

Returns a vector of parameters, read from a file, suitable for updating m.

source
DSGE.specify_mode! — Function
specify_mode!(m::AbstractDSGEModel, mode_file::String=""; verbose=:low)

Updates the values of m.parameters with the values from mode_file. Sets reoptimize setting to false.

Usage: should be run before calling estimate(m), e.g.:

m = Model990()
specify_mode!(m, modefile)
estimate(m)
source
DSGE.specify_hessian! — Function
specify_hessian!(m::AbstractDSGEModel, path::String=""; verbose=:low)

Specify a Hessian matrix calculated at the posterior mode to use in the model estimation. If no path is provided, will attempt to detect location.

source

Parameter and Setting Interface

See ModelConstructors.jl.

The PoolModel Type

A PoolModel has a very similar structure to concrete subtypes of AbstractDSGEModel, but certain fields have been removed because they are not necessary for a PoolModel, such as exogenous_shocks. We chose to define PoolModel as a concrete subtype of AbstractDSGEModel because, for the foreseeable future, we have no plans to implement a more complex type hierarchy for types that perform model averaging. By defining PoolModel as a subtype of a AbstractDSGEModel and taking advantage of multiple dispatch, less refactoring was required to make PoolModel compatible with DSGE.jl functions like estimate.

The DSGEVAR Type

Like the PoolModel type, the DSGEVAR is not a DSGE model, but unlike the PoolModel, which is still a subtype of AbstractDSGEModel, DSGEVAR has the following type hierarchy:

DSGEVAR <: AbstractDSGEVARModel <: AbstractVARModel <: AbstractModel

The behavior of DSGEVAR is sufficiently distinct from AbstractDSGEModel and requires enough specialized functions that simply using multiple dispatch did not seem an effective way to implement DSGEVAR. Moreover, several functions, like the impulse_responses code, apply to generic VARs. Restricting these functions to DSGEVAR did not seem like the best idea.

In the near term, there are no plans to further flesh out the VAR capabilities of DSGE.jl, but in the longer term, we may add VAR routines to DSGE.jl or implement them in a separate package. If we do create a separate package, then DSGEVAR will be refactored to be compatible with this new package.

Features that have not been fully implemented for DSGEVAR include

  • Loading data directly from the DSGEVAR
  • Calling forecast_one on a DSGEVAR
  • Calling compute_meansbands on a DSGEVAR
  • Plotting with a DSGEVAR
  • Alternative policy

The DSGEVECM Type

The DSGEVECM extends the DSGEVAR to accommodate DSGE-VECM methods. It has the following type hierarchy:

DSGEVECM <: AbstractDSGEVECMModel <: AbstractDSGEVARModel <: AbstractVARModel <: AbstractModel

In the near term, there are no plans to further flesh out the VECM capabilities of DSGE.jl, but in the longer term, we may add VECM routines to DSGE.jl or implement them in a separate package. If we do create a separate package, then DSGEVECM will be refactored to be compatible with this new package.

Features that have not been fully implemented for DSGEVECM include

  • Testing the creation of a DSGEVECM from a DSGE
  • Tests that a DSGEVECM can be estimated properly
  • Loading data directly from the DSGEVECM
  • Calling forecast_one on a DSGEVECM
  • Calling compute_meansbands on a DSGEVECM
  • Plotting with a DSGEVECM
  • Alternative policy