# 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.

## 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.

```
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 values`holds the parameter value in the first regime, and then we update the field`

regimes` 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.

`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

`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.

`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`

.

`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)
```

`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.

`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