diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json
index a795ebc..c34642d 100644
--- a/dev/.documenter-siteinfo.json
+++ b/dev/.documenter-siteinfo.json
@@ -1 +1 @@
-{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2024-03-25T13:58:28","documenter_version":"1.3.0"}}
\ No newline at end of file
+{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2024-03-28T16:50:03","documenter_version":"1.3.0"}}
\ No newline at end of file
diff --git a/dev/index.html b/dev/index.html
index 4a9c727..ebba2fd 100644
--- a/dev/index.html
+++ b/dev/index.html
@@ -1,2 +1,2 @@
-
DynareJulia is a rewriting of Dynare (https://www.dynare.org) that was initially written in Gauss in 1994 and rewritten in Matlab around 2000.
Dynare provides several algorithms to work with Dynamic Stochastic General Equilibrium (DSGE) models often used in macroeconomics. Among other features, it helps
solving such models,
simulating them,
estimating the parameters,
making forecasts.
The user of the package writes a text file, usually with an .mod extension, that contains the equations of the model and the computation tasks. Then, DynareJulia compiles the model and runs the computations.
DynareJulia honors a subset of commands valid in DynareMatlab. Tell us if one of your favorite command or option is missing.
For many computing tasks, DynareJulia provides also Julia functions that can be used in the *.mod file or issued interactively after having run the *.mod file. These Julia functions use keyword arguments for the options and you need only to enter them if you want to change the default value. The keyword arguments without a default value are required arguments. In the sections of this documentation, the Dynare Commands are presented first, then the Julia functions.
Dynare has benefited from many contributions over the years. Here is a list of the contributors:
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
DynareJulia is a rewriting of Dynare (https://www.dynare.org) that was initially written in Gauss in 1994 and rewritten in Matlab around 2000.
Dynare provides several algorithms to work with Dynamic Stochastic General Equilibrium (DSGE) models often used in macroeconomics. Among other features, it helps
solving such models,
simulating them,
estimating the parameters,
making forecasts.
The user of the package writes a text file, usually with an .mod extension, that contains the equations of the model and the computation tasks. Then, DynareJulia compiles the model and runs the computations.
DynareJulia honors a subset of commands valid in DynareMatlab. Tell us if one of your favorite command or option is missing.
For many computing tasks, DynareJulia provides also Julia functions that can be used in the *.mod file or issued interactively after having run the *.mod file. These Julia functions use keyword arguments for the options and you need only to enter them if you want to change the default value. The keyword arguments without a default value are required arguments. In the sections of this documentation, the Dynare Commands are presented first, then the Julia functions.
Dynare has benefited from many contributions over the years. Here is a list of the contributors:
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
Dynare is available for all plateforms supported by the current stable version of Julia (https://julialang.org/downloads/#supported_platforms). It should also work with older versions of Julia starting with version 1.6.3
If you want the solution of very large perfect foresight models and reduce the memory consumption, use the Pardiso package (https://github.com/JuliaSparse/Pardiso.jl) and type
If youw want to solve perfect foresight models with occasionally binding constraints use the PATHSolver package (https://github.com/chkwon/PATHSolver.jl) and type
using PATHSolver
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
Dynare is available for all plateforms supported by the current stable version of Julia (https://julialang.org/downloads/#supported_platforms). It should also work with older versions of Julia starting with version 1.6.3
If you want the solution of very large perfect foresight models and reduce the memory consumption, use the Pardiso package (https://github.com/JuliaSparse/Pardiso.jl) and type
If youw want to solve perfect foresight models with occasionally binding constraints use the PATHSolver package (https://github.com/chkwon/PATHSolver.jl) and type
using PATHSolver
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
diff --git a/dev/macroprocessor/index.html b/dev/macroprocessor/index.html
index bb76100..60b5a62 100644
--- a/dev/macroprocessor/index.html
+++ b/dev/macroprocessor/index.html
@@ -1,5 +1,5 @@
-Macroprocessing language · Dynare.jl
It is possible to use "macro" commands in the .mod file for performing tasks such as: including modular source files, replicating blocks of equations through loops, conditionally executing some code, writing indexed sums or products inside equations...
The Dynare macro-language provides a new set of macro-commands which can be used in .mod files. It features:
File inclusion
Loops (for structure)
Conditional inclusion (if/then/else structures)
Expression substitution
This macro-language is totally independent of the basic Dynare language, and is processed by a separate component of the Dynare pre-processor. The macro processor transforms a .mod file with macros into a .mod file without macros (doing expansions/inclusions), and then feeds it to the Dynare parser. The key point to understand is that the macro processor only does text substitution (like the C preprocessor or the PHP language). Note that it is possible to see the output of the macro processor by using the savemacro option of the dynare command (see dyn-invoc).
The macro processor is invoked by placing macro directives in the .mod file. Directives begin with an at-sign followed by a pound sign (@#). They produce no output, but give instructions to the macro processor. In most cases, directives occupy exactly one line of text. If needed, two backslashes (\\) at the end of the line indicate that the directive is continued on the next line. Macro directives following // are not interpreted by the macro processor. For historical reasons, directives in commented blocks, ie surrounded by /* and */, are interpreted by the macro processor. The user should not rely on this behavior. The main directives are:
@#includepath, paths to search for files that are to be included,
@#include, for file inclusion,
@#define, for defining a macro processor variable,
@#if, @#ifdef, @#ifndef, @#elseif, @#else, @#endif for conditional statements,
@#for, @#endfor for constructing loops.
The macro processor maintains its own list of variables (distinct from model variables and Julia variables). These macro-variables are assigned using the @#define directive and can be of the following basic types: boolean, real, string, tuple, function, and array (of any of the previous types).
In the body of the .mod file, between an at-sign and curly braces: the macro processor will substitute the expression with its value
It is possible to construct macro-expressions that can be assigned to macro-variables or used within a macro-directive. The expressions are constructed using literals of the basic types (boolean, real, string, tuple, array), comprehensions, macro-variables, macro-functions, and standard operators.
Note
Elsewhere in the manual, MACRO_EXPRESSION designates an expression constructed as explained in this section.
Boolean
The following operators can be used on booleans:
Comparison operators: ==, !=
Logical operators: &&, ||, !
Real
The following operators can be used on reals:
Arithmetic operators: +, -, *, /, ^
Comparison operators: <, >, <=, >=, ==, !=
Logical operators: &&, ||, !
Ranges with an increment of 1: REAL1:REAL2 (for example, 1:4 is equivalent to real array [1, 2, 3, 4]).
4.6 Previously, putting brackets around the arguments to the colon operator (e.g. [1:4]) had no effect. Now, [1:4] will create an array containing an array (i.e. [ [1, 2, 3, 4] ]).
Ranges with user-defined increment: REAL1:REAL2:REAL3 (for example, 6:-2.1:-1 is equivalent to real array [6, 3.9, 1.8, -0.3]).
Functions: max, min, mod, exp, log, log10, sin, cos, tan, asin, acos, atan, sqrt, cbrt, sign, floor, ceil, trunc, erf, erfc, gamma, lgamma, round, normpdf, normcdf. NB ln can be used instead of log
String
String literals have to be enclosed by double quotes (like "name").
The following operators can be used on strings:
Comparison operators: <, >, <=, >=, ==, !=
Concatenation of two strings: +
Extraction of substrings: if s is a string, then s[3] is a string containing only the third character of s, and s[4:6] contains the characters from 4th to 6th
Function: length
Tuple
Tuples are enclosed by parenthesis and elements separated by commas (like (a,b,c) or (1,2,3)).
The following operators can be used on tuples:
Comparison operators: ==, !=
Functions: empty, length
Array
Arrays are enclosed by brackets, and their elements are separated by commas (like [1,[2,3],4] or ["US", "FR"]).
The following operators can be used on arrays:
Comparison operators: ==, !=
Dereferencing: if v is an array, then v[2] is its 2nd element
Concatenation of two arrays: +
Set union of two arrays: |
Set intersection of two arrays: &
Difference -: returns the first operand from which the elements of the second operand have been removed.
Cartesian product of two arrays: *
Cartesian product of one array N times: ^N
Extraction of sub-arrays: e.g. v[4:6]
Testing membership of an array: in operator (for example: "b" in ["a", "b", "c"] returns 1)
Functions: empty, sum, length
Comprehension
Comprehension syntax is a shorthand way to make arrays from other arrays. There are three different ways the comprehension syntax can be employed: [filtering], [mapping], and [filtering and mapping].
Filtering
Filtering allows one to choose those elements from an array for which a certain condition hold.
Example
Create a new array, choosing the even numbers from the array 1:5:
[ i in 1:5 when mod(i,2) == 0 ]
would result in:
[2, 4]
Mapping
Mapping allows you to apply a transformation to every element of an array.
Example
Create a new array, squaring all elements of the array 1:5:
[ i^2 for i in 1:5 ]
would result in:
[1, 4, 9, 16, 25]
Filtering and Mapping
Combining the two preceding ideas would allow one to apply a transformation to every selected element of an array.
Example
Create a new array, squaring all even elements of the array 1:5:
[ i^2 for i in 1:5 when mod(i,2) == 0]
would result in:
[4, 16]
Further Examples :
[ (j, i+1) for (i,j) in (1:2)^2 ]
+Macroprocessing language · Dynare.jl
It is possible to use "macro" commands in the .mod file for performing tasks such as: including modular source files, replicating blocks of equations through loops, conditionally executing some code, writing indexed sums or products inside equations...
The Dynare macro-language provides a new set of macro-commands which can be used in .mod files. It features:
File inclusion
Loops (for structure)
Conditional inclusion (if/then/else structures)
Expression substitution
This macro-language is totally independent of the basic Dynare language, and is processed by a separate component of the Dynare pre-processor. The macro processor transforms a .mod file with macros into a .mod file without macros (doing expansions/inclusions), and then feeds it to the Dynare parser. The key point to understand is that the macro processor only does text substitution (like the C preprocessor or the PHP language). Note that it is possible to see the output of the macro processor by using the savemacro option of the dynare command (see dyn-invoc).
The macro processor is invoked by placing macro directives in the .mod file. Directives begin with an at-sign followed by a pound sign (@#). They produce no output, but give instructions to the macro processor. In most cases, directives occupy exactly one line of text. If needed, two backslashes (\\) at the end of the line indicate that the directive is continued on the next line. Macro directives following // are not interpreted by the macro processor. For historical reasons, directives in commented blocks, ie surrounded by /* and */, are interpreted by the macro processor. The user should not rely on this behavior. The main directives are:
@#includepath, paths to search for files that are to be included,
@#include, for file inclusion,
@#define, for defining a macro processor variable,
@#if, @#ifdef, @#ifndef, @#elseif, @#else, @#endif for conditional statements,
@#for, @#endfor for constructing loops.
The macro processor maintains its own list of variables (distinct from model variables and Julia variables). These macro-variables are assigned using the @#define directive and can be of the following basic types: boolean, real, string, tuple, function, and array (of any of the previous types).
In the body of the .mod file, between an at-sign and curly braces: the macro processor will substitute the expression with its value
It is possible to construct macro-expressions that can be assigned to macro-variables or used within a macro-directive. The expressions are constructed using literals of the basic types (boolean, real, string, tuple, array), comprehensions, macro-variables, macro-functions, and standard operators.
Note
Elsewhere in the manual, MACRO_EXPRESSION designates an expression constructed as explained in this section.
Boolean
The following operators can be used on booleans:
Comparison operators: ==, !=
Logical operators: &&, ||, !
Real
The following operators can be used on reals:
Arithmetic operators: +, -, *, /, ^
Comparison operators: <, >, <=, >=, ==, !=
Logical operators: &&, ||, !
Ranges with an increment of 1: REAL1:REAL2 (for example, 1:4 is equivalent to real array [1, 2, 3, 4]).
4.6 Previously, putting brackets around the arguments to the colon operator (e.g. [1:4]) had no effect. Now, [1:4] will create an array containing an array (i.e. [ [1, 2, 3, 4] ]).
Ranges with user-defined increment: REAL1:REAL2:REAL3 (for example, 6:-2.1:-1 is equivalent to real array [6, 3.9, 1.8, -0.3]).
Functions: max, min, mod, exp, log, log10, sin, cos, tan, asin, acos, atan, sqrt, cbrt, sign, floor, ceil, trunc, erf, erfc, gamma, lgamma, round, normpdf, normcdf. NB ln can be used instead of log
String
String literals have to be enclosed by double quotes (like "name").
The following operators can be used on strings:
Comparison operators: <, >, <=, >=, ==, !=
Concatenation of two strings: +
Extraction of substrings: if s is a string, then s[3] is a string containing only the third character of s, and s[4:6] contains the characters from 4th to 6th
Function: length
Tuple
Tuples are enclosed by parenthesis and elements separated by commas (like (a,b,c) or (1,2,3)).
The following operators can be used on tuples:
Comparison operators: ==, !=
Functions: empty, length
Array
Arrays are enclosed by brackets, and their elements are separated by commas (like [1,[2,3],4] or ["US", "FR"]).
The following operators can be used on arrays:
Comparison operators: ==, !=
Dereferencing: if v is an array, then v[2] is its 2nd element
Concatenation of two arrays: +
Set union of two arrays: |
Set intersection of two arrays: &
Difference -: returns the first operand from which the elements of the second operand have been removed.
Cartesian product of two arrays: *
Cartesian product of one array N times: ^N
Extraction of sub-arrays: e.g. v[4:6]
Testing membership of an array: in operator (for example: "b" in ["a", "b", "c"] returns 1)
Functions: empty, sum, length
Comprehension
Comprehension syntax is a shorthand way to make arrays from other arrays. There are three different ways the comprehension syntax can be employed: [filtering], [mapping], and [filtering and mapping].
Filtering
Filtering allows one to choose those elements from an array for which a certain condition hold.
Example
Create a new array, choosing the even numbers from the array 1:5:
[ i in 1:5 when mod(i,2) == 0 ]
would result in:
[2, 4]
Mapping
Mapping allows you to apply a transformation to every element of an array.
Example
Create a new array, squaring all elements of the array 1:5:
[ i^2 for i in 1:5 ]
would result in:
[1, 4, 9, 16, 25]
Filtering and Mapping
Combining the two preceding ideas would allow one to apply a transformation to every selected element of an array.
Example
Create a new array, squaring all even elements of the array 1:5:
[ i^2 for i in 1:5 when mod(i,2) == 0]
would result in:
[4, 16]
Further Examples :
[ (j, i+1) for (i,j) in (1:2)^2 ]
[ (j, i+1) for (i,j) in (1:2)*(1:2) when i < j ]
would result in:
[(1, 2), (2, 2), (1, 3), (2, 3)]
[(2, 2)]
Function
Functions can be defined in the macro processor using the @#define directive (see below). A function is evaluated at the time it is invoked, not at define time. Functions can be included in expressions and the operators that can be combined with them depend on their return type.
Checking variable type
Given a variable name or literal, you can check the type it evaluates to using the following functions: isboolean, isreal, isstring, istuple, and isarray.
Examples
Code
Output
isboolean(0)
false
isboolean(true)
true
isreal("str")
false
Casting between types
Variables and literals of one type can be cast into another type. Some type changes are straightforward (e.g. changing a [real]{.title-ref} to a [string]{.title-ref}) whereas others have certain requirements (e.g. to cast an [array]{.title-ref} to a [real]{.title-ref} it must be a one element array containing a type that can be cast to [real]{.title-ref}).
This directive adds the path contained in PATH to the list of those to search when looking for a .mod file specified by @#include. If provided with a MACRO_EXPRESSION argument, the argument must evaluate to a string. Note that these paths are added after any paths passed using -I <-I\<\<path\>\>>{.interpreted-text role="opt"}.
This directive simply includes the content of another file in its place; it is exactly equivalent to a copy/paste of the content of the included file. If provided with a MACRO_EXPRESSION argument, the argument must evaluate to a string. Note that it is possible to nest includes (i.e. to include a file from an included file). The file will be searched for in the current directory. If it is not found, the file will be searched for in the folders provided by -I <-I\<\<path\>\>>{.interpreted-text role="opt"} and @#includepath.
Example
@#include "modelcomponent.mod"
@@ -145,4 +145,4 @@
% Anything contained in this block will be passed
% directly to the <modfile>.m file, including comments
var = 1;
- end;
For all parameters, endogenous and exogenous variables, stores their value in a text file, using a simple name/value associative table.
for parameters, the value is taken from the last parameter initialization.
for exogenous, the value is taken from the last initval block.
for endogenous, the value is taken from the last steady state computation (or, if no steady state has been computed, from the last initval block).
Note that no variable type is stored in the file, so that the values can be reloaded with load_params_and_steady_state in a setup where the variable types are different.
The typical usage of this function is to compute the steady-state of a model by calibrating the steady-state value of some endogenous variables (which implies that some parameters must be endogeneized during the steady-state computation).
You would then write a first .mod file which computes the steady state and saves the result of the computation at the end of the file, using save_params_and_steady_state.
In a second file designed to perform the actual simulations, you would use load_params_and_steady_state just after your variable declarations, in order to load the steady state previously computed (including the parameters which had been endogeneized during the steady state computation).
The need for two separate .mod files arises from the fact that the variable declarations differ between the files for steady state calibration and for simulation (the set of endogenous and parameters differ between the two); this leads to different var and parameters statements.
Also note that you can take advantage of the @#include directive to share the model equations between the two files (see macro-proc-lang).
load_params_and_steady_state (FILENAME);
For all parameters, endogenous and exogenous variables, loads their value from a file created with save_params_and_steady_state.
for parameters, their value will be initialized as if they had been calibrated in the .mod file.
for endogenous and exogenous variables, their value will be initialized as they would have been from an initval block .
This function is used in conjunction with save_params_and_steady_state; see the documentation of that function for more information.
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
For all parameters, endogenous and exogenous variables, stores their value in a text file, using a simple name/value associative table.
for parameters, the value is taken from the last parameter initialization.
for exogenous, the value is taken from the last initval block.
for endogenous, the value is taken from the last steady state computation (or, if no steady state has been computed, from the last initval block).
Note that no variable type is stored in the file, so that the values can be reloaded with load_params_and_steady_state in a setup where the variable types are different.
The typical usage of this function is to compute the steady-state of a model by calibrating the steady-state value of some endogenous variables (which implies that some parameters must be endogeneized during the steady-state computation).
You would then write a first .mod file which computes the steady state and saves the result of the computation at the end of the file, using save_params_and_steady_state.
In a second file designed to perform the actual simulations, you would use load_params_and_steady_state just after your variable declarations, in order to load the steady state previously computed (including the parameters which had been endogeneized during the steady state computation).
The need for two separate .mod files arises from the fact that the variable declarations differ between the files for steady state calibration and for simulation (the set of endogenous and parameters differ between the two); this leads to different var and parameters statements.
Also note that you can take advantage of the @#include directive to share the model equations between the two files (see macro-proc-lang).
load_params_and_steady_state (FILENAME);
For all parameters, endogenous and exogenous variables, loads their value from a file created with save_params_and_steady_state.
for parameters, their value will be initialized as if they had been calibrated in the .mod file.
for endogenous and exogenous variables, their value will be initialized as they would have been from an initval block .
This function is used in conjunction with save_params_and_steady_state; see the documentation of that function for more information.
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
When the framework is deterministic, Dynare can be used for models with the assumption of perfect foresight. The system is supposed to be in a given state before a period 1 (often a steady state) when the news of a contemporaneous or of a future shock is learned by the agents in the model. The purpose of the simulation is to describe the reaction in anticipation of, then in reaction to the shock, until the system returns to equilibrium. This return to equilibrium is only an asymptotic phenomenon, which one must approximate by an horizon of simulation far enough in the future. Another exercise for which Dynare is well suited is to study the transition path to a new equilibrium following a permanent shock. For deterministic simulations, the numerical problem consists of solving a nonlinear system of simultaneous equations in n endogenous variables in T periods. Dynare uses a Newton-type method to solve the simultaneous equation system. Because the resulting Jacobian is in the order of n by T and hence will be very large for long simulations with many variables, Dynare makes use of the sparse matrix code .
Prepares a perfect foresight simulation, by extracting the information in the initval, endval and shocks blocks and converting them into simulation paths for exogenous and endogenous variables.
This command must always be called before running the simulation with perfect\_foresight\_solver.
The paths for the exogenous variables are stored into context.results.model_resultst[1].simulations.
The initial and terminal conditions for the endogenous variables and the initial guess for the path of endogenous variables are stored into context.results.model_results[1].simulations.
Determines the maximum number of iterations used in the non-linear solver. The default value of maxit is 50.
tolf = DOUBLE
Convergence criterion for termination based on the function value. Iteration will cease when it proves impossible to improve the function value by more than tolf. Default: 1e-5
tolx = DOUBLE
Convergence criterion for termination based on the change in the function argument. Iteration will cease when the solver attempts to take a step that is smaller than tolx. Default: 1e-5
noprint
Don't print anything. Useful for loops.
print
Print results (opposite of noprint).
lmmcp
Solves mixed complementarity problems (the term refers to the LMMCP solver (Kanzow and Petra, 2004), that is used by DynareMatlab. DynareJulia uses the PATHSovler package)
endogenous_terminal_period
The number of periods is not constant across Newton iterations when solving the perfect foresight model. The size of the nonlinear system of equations is reduced by removing the portion of the paths (and associated equations) for which the solution has already been identified (up to the tolerance parameter). This strategy can be interpreted as a mix of the shooting and relaxation approaches. Note that round off errors are more important with this mixed strategy (user should check the reported value of the maximum absolute error). Only available with option stack_solve_algo==0.
When the framework is deterministic, Dynare can be used for models with the assumption of perfect foresight. The system is supposed to be in a given state before a period 1 (often a steady state) when the news of a contemporaneous or of a future shock is learned by the agents in the model. The purpose of the simulation is to describe the reaction in anticipation of, then in reaction to the shock, until the system returns to equilibrium. This return to equilibrium is only an asymptotic phenomenon, which one must approximate by an horizon of simulation far enough in the future. Another exercise for which Dynare is well suited is to study the transition path to a new equilibrium following a permanent shock. For deterministic simulations, the numerical problem consists of solving a nonlinear system of simultaneous equations in n endogenous variables in T periods. Dynare uses a Newton-type method to solve the simultaneous equation system. Because the resulting Jacobian is in the order of n by T and hence will be very large for long simulations with many variables, Dynare makes use of the sparse matrix code .
Prepares a perfect foresight simulation, by extracting the information in the initval, endval and shocks blocks and converting them into simulation paths for exogenous and endogenous variables.
This command must always be called before running the simulation with perfect\_foresight\_solver.
The paths for the exogenous variables are stored into context.results.model_resultst[1].simulations.
The initial and terminal conditions for the endogenous variables and the initial guess for the path of endogenous variables are stored into context.results.model_results[1].simulations.
Determines the maximum number of iterations used in the non-linear solver. The default value of maxit is 50.
tolf = DOUBLE
Convergence criterion for termination based on the function value. Iteration will cease when it proves impossible to improve the function value by more than tolf. Default: 1e-5
tolx = DOUBLE
Convergence criterion for termination based on the change in the function argument. Iteration will cease when the solver attempts to take a step that is smaller than tolx. Default: 1e-5
noprint
Don't print anything. Useful for loops.
print
Print results (opposite of noprint).
lmmcp
Solves mixed complementarity problems (the term refers to the LMMCP solver (Kanzow and Petra, 2004), that is used by DynareMatlab. DynareJulia uses the PATHSovler package)
endogenous_terminal_period
The number of periods is not constant across Newton iterations when solving the perfect foresight model. The size of the nonlinear system of equations is reduced by removing the portion of the paths (and associated equations) for which the solution has already been identified (up to the tolerance parameter). This strategy can be interpreted as a mix of the shooting and relaxation approaches. Note that round off errors are more important with this mixed strategy (user should check the reported value of the maximum absolute error). Only available with option stack_solve_algo==0.
Be careful when employing auxiliary variables in the context of perfect
foresight computations. The same model may work for stochastic
simulations, but fail for perfect foresight simulations. The issue
arises when an equation suddenly only contains variables dated `t+1` (or
@@ -8,9 +8,9 @@
Jacobian singular.
Consider the following specification of an Euler equation with log utility:
Lambda = beta*C(-1)/C;
Lambda(+1)*R(+1)= 1;
Clearly, the derivative of the second equation with respect to all endogenous variables at time t is zero, causing perfect_foresight_solver to generally fail. This is due to the use of the Lagrange multiplier Lambda as an auxiliary variable. Instead, employing the identical
periods::Int: number of periods in the simulation [required]
context::Context=context: context in which the simulation is computed
display::Bool=true: whether to display the results
linear_solve_algo::LinearSolveAlgo=ilu: algorithm used for the solution of the linear problem. Either ilu or pardiso. ilu is the sparse linear solver used by default in Julia. To use the Pardiso solver, write using Pardiso before running Dynare.
maxit::Int=50 maximum number of iterations
mcp::Bool=falseL whether to solve a mixed complementarity problem with occasionally binding constraints
tolf::Float64=1e-5: tolerance for the norm of residualts
tolx::Float64=1e-5: tolerance for the norm of the change in the result
The simulated endogenous variables are available in context.results.model_results[1].simulations. This is a vector of AxisArrayTable, one for each simulations stored in context. Each AxisArrayTable contains the trajectories for endogenous and exogenous variables
requires a particular model setup as the goal is to get rid of any min/max operators and complementary slackness conditions that might introduce a singularity into the Jacobian. This is done by attaching an equation tag (see model-decl) with the mcp keyword to affected equations. The format of the mcp tag is
[mcp = 'VARIABBLENAME OP CONSTANT']
where VARIABLENAME is an endogenous variable and OP is either > or <. For complicated occasionally binding constraints, it may be necessary to declare a new endogenous variable.
This tag states that the equation to which the tag is attached has to hold unless the expression within the tag is binding. For instance, a ZLB on the nominal interest rate would be specified as follows in the model block:
model;
+ tolf = 1e-5, tolx = 1e-5)
Keyword arguments
periods::Int: number of periods in the simulation [required]
context::Context=context: context in which the simulation is computed
display::Bool=true: whether to display the results
linear_solve_algo::LinearSolveAlgo=ilu: algorithm used for the solution of the linear problem. Either ilu or pardiso. ilu is the sparse linear solver used by default in Julia. To use the Pardiso solver, write using Pardiso before running Dynare.
maxit::Int=50 maximum number of iterations
mcp::Bool=falseL whether to solve a mixed complementarity problem with occasionally binding constraints
tolf::Float64=1e-5: tolerance for the norm of residualts
tolx::Float64=1e-5: tolerance for the norm of the change in the result
The simulated endogenous variables are available in context.results.model_results[1].simulations. This is a vector of AxisArrayTable, one for each simulations stored in context. Each AxisArrayTable contains the trajectories for endogenous and exogenous variables
requires a particular model setup as the goal is to get rid of any min/max operators and complementary slackness conditions that might introduce a singularity into the Jacobian. This is done by attaching an equation tag (see model-decl) with the mcp keyword to affected equations. The format of the mcp tag is
[mcp = 'VARIABBLENAME OP CONSTANT']
where VARIABLENAME is an endogenous variable and OP is either > or <. For complicated occasionally binding constraints, it may be necessary to declare a new endogenous variable.
This tag states that the equation to which the tag is attached has to hold unless the expression within the tag is binding. For instance, a ZLB on the nominal interest rate would be specified as follows in the model block:
where r is the nominal interest rate in deviation from the steady state. This construct implies that the Taylor rule is operative, unless the implied interest rate r<=-1.94478, in which case the r is fixed at -1.94478. This is equavalant to
By restricting the value of r coming out of this equation, the mcp tag also avoids using max(r,-1.94478) for other occurrences of r in the rest of the model. It is important to keep in mind that, because the mcp tag effectively replaces a complementary slackness condition, it cannot be simply attached to any equation.
Note that in the current implementation, the content of the mcp equation tag is not parsed by the preprocessor. The inequalities must therefore be as simple as possible: an endogenous variable, followed by a relational operator, followed by a number (not a variable, parameter or expression).
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
+ end;
where r is the nominal interest rate in deviation from the steady state. This construct implies that the Taylor rule is operative, unless the implied interest rate r<=-1.94478, in which case the r is fixed at -1.94478. This is equavalant to
By restricting the value of r coming out of this equation, the mcp tag also avoids using max(r,-1.94478) for other occurrences of r in the rest of the model. It is important to keep in mind that, because the mcp tag effectively replaces a complementary slackness condition, it cannot be simply attached to any equation.
Note that in the current implementation, the content of the mcp equation tag is not parsed by the preprocessor. The inequalities must therefore be as simple as possible: an endogenous variable, followed by a relational operator, followed by a number (not a variable, parameter or expression).
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
Provided that you have observations on some endogenous variables, it is possible to use Dynare to estimate some or all parameters. Bayesian techniques (as in Fernández-Villaverde and Rubio-Ramírez (2004), Rabanal and Rubio-Ramirez (2003), Schorfheide (2000) or Smets and Wouters (2003)) are available. Using Bayesian methods, it is possible to estimate DSGE models.
Note that in order to avoid stochastic singularity, you must have at least as many shocks or measurement errors in your model as you have observed variables.
Before using the estimation commands described below, you need to define some elements of the state space representation of the model. At the minimum, you need to declare the observed variables with var_obs and, possibly, deterministic trends with observation_trends (see the previous section: State space, filtering and smoothing)
Provided that you have observations on some endogenous variables, it is possible to use Dynare to estimate some or all parameters. Bayesian techniques (as in Fernández-Villaverde and Rubio-Ramírez (2004), Rabanal and Rubio-Ramirez (2003), Schorfheide (2000) or Smets and Wouters (2003)) are available. Using Bayesian methods, it is possible to estimate DSGE models.
Note that in order to avoid stochastic singularity, you must have at least as many shocks or measurement errors in your model as you have observed variables.
Before using the estimation commands described below, you need to define some elements of the state space representation of the model. At the minimum, you need to declare the observed variables with var_obs and, possibly, deterministic trends with observation_trends (see the previous section: State space, filtering and smoothing)
It is possible to have several estimated_params blocks. By default, subsequent blocks are concatenated with the previous ones; this can be useful when building models in a modular fashion (see also estimated_params_remove for that use case). However, if an estimated_params block has the overwrite option, its contents becomes the new list of estimated parameters, cancelling previous blocks; this can be useful when doing several estimations in a single .mod file.
This block declares numerical initial values for the optimizer when these ones are different from the prior mean. It should be specified after the estimated_params block as otherwise the specified starting values are overwritten by the latter.
The number of observations following first_obs to be used. Default: all observations in the file after first_obs.
first_obs = INTEGER
The number of the first observation to be used. In case of estimating a DSGE-VAR, first_obs needs to be larger than the number of lags. Default: 1.
plot_priors = INTEGER: Control the plotting of priors, 0, no prior plot, 1, pPrior density for each estimated parameter is plotted. It is important to check that the actual shape of prior densities matches what you have in mind. Ill-chosen values for the prior standard density can result in absurd prior densities (default valueL 1).
mh_replic = INTEGER
Number of replications for each chain of the Metropolis-Hastings algorithm. The number of draws should be sufficient to achieve convergence of the MCMC and to meaningfully compute posterior objects. Default: 20000.
mh_nblocks = INTEGER
Number of parallel chains for Metropolis-Hastings algorithm. Default: 2.
mh_jscale = DOUBLE
The scale parameter of the jumping distribution's covariance matrix. The default value is rarely satisfactory. This option must be tuned to obtain, ideally, an acceptance ratio of 25%-33%. Basically, the idea is to increase the variance of the jumping distribution if the acceptance ratio is too high, and decrease the same variance if the acceptance ratio is too low. In some situations it may help to consider parameter-specific values for this scale parameter. This can be done in the estimated_params block. Default: 0.2.
It is possible to have several estimated_params blocks. By default, subsequent blocks are concatenated with the previous ones; this can be useful when building models in a modular fashion (see also estimated_params_remove for that use case). However, if an estimated_params block has the overwrite option, its contents becomes the new list of estimated parameters, cancelling previous blocks; this can be useful when doing several estimations in a single .mod file.
This block declares numerical initial values for the optimizer when these ones are different from the prior mean. It should be specified after the estimated_params block as otherwise the specified starting values are overwritten by the latter.
The number of observations following first_obs to be used. Default: all observations in the file after first_obs.
first_obs = INTEGER
The number of the first observation to be used. In case of estimating a DSGE-VAR, first_obs needs to be larger than the number of lags. Default: 1.
plot_priors = INTEGER: Control the plotting of priors, 0, no prior plot, 1, pPrior density for each estimated parameter is plotted. It is important to check that the actual shape of prior densities matches what you have in mind. Ill-chosen values for the prior standard density can result in absurd prior densities (default valueL 1).
mh_replic = INTEGER
Number of replications for each chain of the Metropolis-Hastings algorithm. The number of draws should be sufficient to achieve convergence of the MCMC and to meaningfully compute posterior objects. Default: 20000.
mh_nblocks = INTEGER
Number of parallel chains for Metropolis-Hastings algorithm. Default: 2.
mh_jscale = DOUBLE
The scale parameter of the jumping distribution's covariance matrix. The default value is rarely satisfactory. This option must be tuned to obtain, ideally, an acceptance ratio of 25%-33%. Basically, the idea is to increase the variance of the jumping distribution if the acceptance ratio is too high, and decrease the same variance if the acceptance ratio is too low. In some situations it may help to consider parameter-specific values for this scale parameter. This can be done in the estimated_params block. Default: 0.2.
generates a prior for a symbol of a parameter, the standard deviation (stdev) or the variance (variance) of an exogenous variable or an endogenous variable (measurement error) or the correlation (corr) between 2 endogenous or exogenous variables
Keywor arguments
shape <: Distributions: the shape of the prior distribution (Beta, InvertedGamma, InvertedGamma1, Gamma, Normal, Uniform, Weibull) [required]
context::Context=context: context in which the prior is declared
domain::Vector{<:Real}=Float64[]: domain for a uniform distribution
initialvalue::Union{Real,Missing}=missing: initialvalue for mode finding or MCMC iterations
mean::Union{Real,Missing}=missing: mean of the prior distribution
stdev::Union{Real,Missing}=missing: stdev of the prior distribution
variance::Union{Real,Missing}=missing: variance of the prior distribution
generates a prior for a symbol of a parameter, the standard deviation (stdev) or the variance (variance) of an exogenous variable or an endogenous variable (measurement error) or the correlation (corr) between 2 endogenous or exogenous variables
Keywor arguments
shape <: Distributions: the shape of the prior distribution (Beta, InvertedGamma, InvertedGamma1, Gamma, Normal, Uniform, Weibull) [required]
context::Context=context: context in which the prior is declared
domain::Vector{<:Real}=Float64[]: domain for a uniform distribution
initialvalue::Union{Real,Missing}=missing: initialvalue for mode finding or MCMC iterations
mean::Union{Real,Missing}=missing: mean of the prior distribution
stdev::Union{Real,Missing}=missing: stdev of the prior distribution
variance::Union{Real,Missing}=missing: variance of the prior distribution
From a statistical point of view, DSGE models are unobserved components models: only a few variables are observed. Filtering or smoothing provide estimate of the unobserved variables given the observations.
From a statistical point of view, DSGE models are unobserved components models: only a few variables are observed. Filtering or smoothing provide estimate of the unobserved variables given the observations.
where $y^o_t$ represents observed variable at period t. The coefficient matrices of the transition equation, T and R are provided by the solution of the linear(-isze) rational expectation model. $\epsilon_t$ are possible measurement errors and $\eta_t$ the structural shocks. Most often matrix M is a selection matrix.
Filtering provides estimates conditional only on past observations:
\[\mathbb{E}(y^{no}_t|Y^o_{t-1})\]
where $y^{no}_t$ are unobserved variables at period t and $Y^o_{t-1}$ represent the set observations until period t-1 included.
Smoothing provides estimates of unobserved variables conditional on the entire sample of observations:
\[\mathbb{E}(y^{no}_t|Y^o_T)\]
where $Y^o_T$ represents the all observations in the sample.
Observed variables are declared with the varobs command
Command: varobs VARIABLE_NAME...;
This command lists the name of observed endogenous variables for the estimation procedure. These variables must be available in the data file (see estimation_cmd <estim-comm>).
Alternatively, this command is also used in conjunction with the partial_information option of stoch_simul, for declaring the set of observed variables when solving the model under partial information.
Only one instance of varobs is allowed in a model file. If one needs to declare observed variables in a loop, the macro processor can be used as shown in the second example below.
It is possible to declare a deterministic linear trend that is removed for the computations and added back in the results
Block: observation_trends ;
This block specifies linear trends for observed variables as functions of model parameters. In case the loglinear option is used, this corresponds to a linear trend in the logged observables, i.e. an exponential trend in the level of the observables.
Each line inside of the block should be of the form:
VARIABLE_NAME(EXPRESSION);
In most cases, variables shouldn't be centered when observation_trends is used.
computes an unconditional forecast of the variables of the model
Keyword arguments
periods::Integer: number of forecasted periods [required]
forecast_mode::ForecastModes: one of histval or calibsmoother [required]
datafile::String: file with the observations for the smoother
first_obs::PeriodsSinceEpoch: first period used by smoother (default: first observation in the file)
first_period::PeriodsSinceEpoch: initial_period for the forecast (default when histval: Undated(0), default when calibsmoother: last period of the smoother)
last_obs::PeriodsSinceEpoch: last period used by smoother (default: last observation in the file)
function recursiveforecasting!(; Np::Integer, firstperiod::PeriodsSinceEpoch, lastperiod::PeriodsSinceEpoch, context::Context=context, datafile::String="", firstobs::PeriodsSinceEpoch=Undated(1), last_obs::PeriodsSinceEpoch=Undated(0), order::Integer=1) computes an unconditional recursive forecast for one variable by adding one period to the sample used for the smoother before forecasting over Np periods.
Keyword arguments
Np::Integer: number of forecasted periods [required]
first_period::PeriodsSinceEpoch: initial period of first forecast [required]
last_period::PeriodsSinceEpoch: initial period of last forecast [required]
datafile::String: file with the observations for the smoother
first_obs::PeriodsSinceEpoch: first period used by smoother (default: first observation in the file)
last_obs::PeriodsSinceEpoch: last period used by smoother (default: last observation in the file)
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
+ order::Integer=1)
computes an unconditional forecast of the variables of the model
Keyword arguments
periods::Integer: number of forecasted periods [required]
forecast_mode::ForecastModes: one of histval or calibsmoother [required]
datafile::String: file with the observations for the smoother
first_obs::PeriodsSinceEpoch: first period used by smoother (default: first observation in the file)
first_period::PeriodsSinceEpoch: initial_period for the forecast (default when histval: Undated(0), default when calibsmoother: last period of the smoother)
last_obs::PeriodsSinceEpoch: last period used by smoother (default: last observation in the file)
function recursiveforecasting!(; Np::Integer, firstperiod::PeriodsSinceEpoch, lastperiod::PeriodsSinceEpoch, context::Context=context, datafile::String="", firstobs::PeriodsSinceEpoch=Undated(1), last_obs::PeriodsSinceEpoch=Undated(0), order::Integer=1) computes an unconditional recursive forecast for one variable by adding one period to the sample used for the smoother before forecasting over Np periods.
Keyword arguments
Np::Integer: number of forecasted periods [required]
first_period::PeriodsSinceEpoch: initial period of first forecast [required]
last_period::PeriodsSinceEpoch: initial period of last forecast [required]
datafile::String: file with the observations for the smoother
first_obs::PeriodsSinceEpoch: first period used by smoother (default: first observation in the file)
last_obs::PeriodsSinceEpoch: last period used by smoother (default: last observation in the file)
In a stochastic context, Dynare computes one or several simulations corresponding to a random draw of the shocks.
The main algorithm for solving stochastic models relies on a Taylor approximation, up to second order, of the solution function (see Judd (1996), Collard and Juillard (2001a, 2001b), and Schmitt-Grohé and Uríbe (2004)). The details of the Dynare implementation of the first order solution are given in Villemot (2011). Such a solution is computed using the stoch_simul command.
Solves a stochastic (i.e. rational expectations) model, using perturbation techniques.
More precisely, stoch_simul computes a Taylor approximation of the model around the deterministic steady state and solves of the the decision and transition functions for the approximated model. Using this, it computes impulse response functions and various descriptive statistics (moments, variance decomposition, correlation and autocorrelation coefficients). For correlated shocks, the variance decomposition is computed as in the VAR literature through a Cholesky decomposition of the covariance matrix of the exogenous variables. When the shocks are correlated, the variance decomposition depends upon the order of the variables in the varexo command.
The IRFs are computed as the difference between the trajectory of a variable following a shock at the beginning of period 1 and its steady state value. More details on the computation of IRFs can be found at https://archives.dynare.org/DynareWiki/IrFs.
Variance decomposition, correlation, autocorrelation are only displayed for variables with strictly positive variance. Impulse response functions are only plotted for variables with response larger than $10^{-10}$.
Variance decomposition is computed relative to the sum of the contribution of each shock. Normally, this is of course equal to aggregate variance, but if a model generates very large variances, it may happen that, due to numerical error, the two differ by a significant amount. Dynare issues a warning if the maximum relative difference between the sum of the contribution of each shock and aggregate variance is larger than 0.01%.
The covariance matrix of the shocks is specified with the shocks command (see shocks-exo).
Order of autocorrelation coefficients to compute. Default: 5
irf = INTEGER
Number of periods on which to compute the IRFs. Setting irf=0 suppresses the plotting of IRFs. Default: 40.
nonstationary: declares the model as nonstationary.
noprint: don't print the results
order = INTEGER
Order of Taylor approximation. Note that for third order and above, the k_order_solver option is implied and only empirical moments are available (you must provide a value for periods option). Default: 2
periods = INTEGER
If different from zero, empirical moments will be computed instead of theoretical moments. The value of the option specifies the number of periods to use in the simulations. Values of the initval block, possibly recomputed by steady, will be used as starting point for the simulation. The simulated endogenous variables are made available to the user in Julia variable context.results.model_results[1].simulation. Default: 0.
dr = OPTION
Determines the method used to compute the decision rule. Possible values for OPTION are:
default
Uses the default method to compute the decision rule based on the generalized Schur decomposition (see Villemot (2011) for more information).
cycle_reduction
Uses the cycle reduction algorithm to solve the polynomial equation for retrieving the coefficients associated to the endogenous variables in the decision rule. This method is faster than the default one for large scale models.
The derivatives of the approximated solution function are availabe in the vector of matrices context.results.model_results[1].solution_derivatives. The first element contains the matrix of first order derivatives. The second element, the matrix of second order derivatives.
The matrix of first order derivatives is a $n x (n_s + n_x + 1)$ matrix where n is the number of endogenous variables, $n_s$, the number of state variables (variables appearing in the model with a lag), and $n_x$, the number of exogenous variables. An element of this matrix is
In a stochastic context, Dynare computes one or several simulations corresponding to a random draw of the shocks.
The main algorithm for solving stochastic models relies on a Taylor approximation, up to second order, of the solution function (see Judd (1996), Collard and Juillard (2001a, 2001b), and Schmitt-Grohé and Uríbe (2004)). The details of the Dynare implementation of the first order solution are given in Villemot (2011). Such a solution is computed using the stoch_simul command.
Solves a stochastic (i.e. rational expectations) model, using perturbation techniques.
More precisely, stoch_simul computes a Taylor approximation of the model around the deterministic steady state and solves of the the decision and transition functions for the approximated model. Using this, it computes impulse response functions and various descriptive statistics (moments, variance decomposition, correlation and autocorrelation coefficients). For correlated shocks, the variance decomposition is computed as in the VAR literature through a Cholesky decomposition of the covariance matrix of the exogenous variables. When the shocks are correlated, the variance decomposition depends upon the order of the variables in the varexo command.
The IRFs are computed as the difference between the trajectory of a variable following a shock at the beginning of period 1 and its steady state value. More details on the computation of IRFs can be found at https://archives.dynare.org/DynareWiki/IrFs.
Variance decomposition, correlation, autocorrelation are only displayed for variables with strictly positive variance. Impulse response functions are only plotted for variables with response larger than $10^{-10}$.
Variance decomposition is computed relative to the sum of the contribution of each shock. Normally, this is of course equal to aggregate variance, but if a model generates very large variances, it may happen that, due to numerical error, the two differ by a significant amount. Dynare issues a warning if the maximum relative difference between the sum of the contribution of each shock and aggregate variance is larger than 0.01%.
The covariance matrix of the shocks is specified with the shocks command (see shocks-exo).
Order of autocorrelation coefficients to compute. Default: 5
irf = INTEGER
Number of periods on which to compute the IRFs. Setting irf=0 suppresses the plotting of IRFs. Default: 40.
nonstationary: declares the model as nonstationary.
noprint: don't print the results
order = INTEGER
Order of Taylor approximation. Note that for third order and above, the k_order_solver option is implied and only empirical moments are available (you must provide a value for periods option). Default: 2
periods = INTEGER
If different from zero, empirical moments will be computed instead of theoretical moments. The value of the option specifies the number of periods to use in the simulations. Values of the initval block, possibly recomputed by steady, will be used as starting point for the simulation. The simulated endogenous variables are made available to the user in Julia variable context.results.model_results[1].simulation. Default: 0.
dr = OPTION
Determines the method used to compute the decision rule. Possible values for OPTION are:
default
Uses the default method to compute the decision rule based on the generalized Schur decomposition (see Villemot (2011) for more information).
cycle_reduction
Uses the cycle reduction algorithm to solve the polynomial equation for retrieving the coefficients associated to the endogenous variables in the decision rule. This method is faster than the default one for large scale models.
The derivatives of the approximated solution function are availabe in the vector of matrices context.results.model_results[1].solution_derivatives. The first element contains the matrix of first order derivatives. The second element, the matrix of second order derivatives.
The matrix of first order derivatives is a $n x (n_s + n_x + 1)$ matrix where n is the number of endogenous variables, $n_s$, the number of state variables (variables appearing in the model with a lag), and $n_x$, the number of exogenous variables. An element of this matrix is
\[y_t = y^s + 0.5 \Delta^2 + A \phi(y_{t-1}) + B u_t + 0.5 C
(\phi(y_{t-1})\otimes \phi(y_{t-1})) + 0.5 D (u_t \otimes u_t) + E
-(\phi(y_{t-1}) \otimes u_t)\]
where $y^s$ is the steady state value of $y$, $\phi(y_{t-1})=y_{t-1}-y^s$, and $\Delta^2$ is the shift effect of the variance of future shocks. Matrices of coefficients $A$, $B$, $C$, $D$ and $E$ are computed by Dynare.
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
+(\phi(y_{t-1}) \otimes u_t)\]
where $y^s$ is the steady state value of $y$, $\phi(y_{t-1})=y_{t-1}-y^s$, and $\Delta^2$ is the shift effect of the variance of future shocks. Matrices of coefficients $A$, $B$, $C$, $D$ and $E$ are computed by Dynare.
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
The equations of the model are written in a block delimited by model and end keywords.
There must be as many equations as there are endogenous variables in the model, except when computing the unconstrained optimal policy with ramsey_model, ramsey_policy or discretionary_policy.
The syntax of equations must follow the conventions for MODEL_EXPRESSION as described in expr. Each equation must be terminated by a semicolon (';'). A normal equation looks like:
MODEL_EXPRESSION = MODEL_EXPRESSION;
When the equations are written in homogenous form, it is possible to omit the '=0' part and write only the left hand side of the equation. A homogenous equation looks like:
MODEL_EXPRESSION;
Inside the model block, Dynare allows the creation of model-local variables, which constitute a simple way to share a common expression between several equations. The syntax consists of a pound sign (#) followed by the name of the new model local variable (which must not be declared as in var-decl, but may have been declared by model_local_variable), an equal sign, and the expression for which this new variable will stand. Later on, every time this variable appears in the model, Dynare will substitute it by the expression assigned to the variable. Note that the scope of this variable is restricted to the model block; it cannot be used outside. To assign a LaTeX name to the model local variable, use the declaration syntax outlined by model_local_variable. A model local variable declaration looks like:
#VARIABLE_NAME = MODEL_EXPRESSION;
It is possible to tag equations written in the model block. A tag can serve different purposes by allowing the user to attach arbitrary informations to each equation and to recover them at runtime. For instance, it is possible to name the equations with a name-tag, using a syntax like:
The equations of the model are written in a block delimited by model and end keywords.
There must be as many equations as there are endogenous variables in the model, except when computing the unconstrained optimal policy with ramsey_model, ramsey_policy or discretionary_policy.
The syntax of equations must follow the conventions for MODEL_EXPRESSION as described in expr. Each equation must be terminated by a semicolon (';'). A normal equation looks like:
MODEL_EXPRESSION = MODEL_EXPRESSION;
When the equations are written in homogenous form, it is possible to omit the '=0' part and write only the left hand side of the equation. A homogenous equation looks like:
MODEL_EXPRESSION;
Inside the model block, Dynare allows the creation of model-local variables, which constitute a simple way to share a common expression between several equations. The syntax consists of a pound sign (#) followed by the name of the new model local variable (which must not be declared as in var-decl, but may have been declared by model_local_variable), an equal sign, and the expression for which this new variable will stand. Later on, every time this variable appears in the model, Dynare will substitute it by the expression assigned to the variable. Note that the scope of this variable is restricted to the model block; it cannot be used outside. To assign a LaTeX name to the model local variable, use the declaration syntax outlined by model_local_variable. A model local variable declaration looks like:
#VARIABLE_NAME = MODEL_EXPRESSION;
It is possible to tag equations written in the model block. A tag can serve different purposes by allowing the user to attach arbitrary informations to each equation and to recover them at runtime. For instance, it is possible to name the equations with a name-tag, using a syntax like:
The model which is solved internally by Dynare is not exactly the model declared by the user. In some cases, Dynare will introduce auxiliary endogenous variables–-along with corresponding auxiliary equations–-which will appear in the final output.
The main transformation concerns leads and lags. Dynare will perform a transformation of the model so that there is only one lead and one lag on endogenous variables and no leads/lags on exogenous variables.
This transformation is achieved by the creation of auxiliary variables and corresponding equations. For example, if x(+2) exists in the model, Dynare will create one auxiliary variable AUX_ENDO_LEAD = x(+1), and replace x(+2) by AUX_ENDO_LEAD(+1).
A similar transformation is done for lags greater than 2 on endogenous (auxiliary variables will have a name beginning with AUX_ENDO_LAG), and for exogenous with leads and lags (auxiliary variables will have a name beginning with AUX_EXO_LEAD or AUX_EXO_LAG respectively).
Another transformation is done for the EXPECTATION operator. For each occurrence of this operator, Dynare creates an auxiliary variable defined by a new equation, and replaces the expectation operator by a reference to the new auxiliary variable. For example, the expression EXPECTATION(-1)(x(+1)) is replaced by AUX_EXPECT_LAG_1(-1), and the new auxiliary variable is declared as AUX_EXPECT_LAG_1 = x(+2).
Auxiliary variables are also introduced by the preprocessor for the ramsey_model and ramsey_policy commands. In this case, they are used to represent the Lagrange multipliers when first order conditions of the Ramsey problem are computed. The new variables take the form MULT_i, where i represents the constraint with which the multiplier is associated (counted from the order of declaration in the model block).
Auxiliary variables are also introduced by the differentiate_forward_vars option of the model block. The new variables take the form AUX_DIFF_FWRD_i, and are equal to x-x(-1) for some endogenous variable x.
Finally, auxiliary variables will arise in the context of employing the diff-operator.
Once created, all auxiliary variables are included in the set of endogenous variables. The output of decision rules (see below) is such that auxiliary variable names are replaced by the original variables they refer to.
The number of endogenous variables before the creation of auxiliary variables is stored in context.models[1].orig_endo_nbr, and the number of endogenous variables after the creation of auxiliary variables is stored in context.models[1].endogenous_nbr.
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
+end;
In the above example, the dummy equation is replaced by a proper Euler equation.
The model which is solved internally by Dynare is not exactly the model declared by the user. In some cases, Dynare will introduce auxiliary endogenous variables–-along with corresponding auxiliary equations–-which will appear in the final output.
The main transformation concerns leads and lags. Dynare will perform a transformation of the model so that there is only one lead and one lag on endogenous variables and no leads/lags on exogenous variables.
This transformation is achieved by the creation of auxiliary variables and corresponding equations. For example, if x(+2) exists in the model, Dynare will create one auxiliary variable AUX_ENDO_LEAD = x(+1), and replace x(+2) by AUX_ENDO_LEAD(+1).
A similar transformation is done for lags greater than 2 on endogenous (auxiliary variables will have a name beginning with AUX_ENDO_LAG), and for exogenous with leads and lags (auxiliary variables will have a name beginning with AUX_EXO_LEAD or AUX_EXO_LAG respectively).
Another transformation is done for the EXPECTATION operator. For each occurrence of this operator, Dynare creates an auxiliary variable defined by a new equation, and replaces the expectation operator by a reference to the new auxiliary variable. For example, the expression EXPECTATION(-1)(x(+1)) is replaced by AUX_EXPECT_LAG_1(-1), and the new auxiliary variable is declared as AUX_EXPECT_LAG_1 = x(+2).
Auxiliary variables are also introduced by the preprocessor for the ramsey_model and ramsey_policy commands. In this case, they are used to represent the Lagrange multipliers when first order conditions of the Ramsey problem are computed. The new variables take the form MULT_i, where i represents the constraint with which the multiplier is associated (counted from the order of declaration in the model block).
Auxiliary variables are also introduced by the differentiate_forward_vars option of the model block. The new variables take the form AUX_DIFF_FWRD_i, and are equal to x-x(-1) for some endogenous variable x.
Finally, auxiliary variables will arise in the context of employing the diff-operator.
Once created, all auxiliary variables are included in the set of endogenous variables. The output of decision rules (see below) is such that auxiliary variable names are replaced by the original variables they refer to.
The number of endogenous variables before the creation of auxiliary variables is stored in context.models[1].orig_endo_nbr, and the number of endogenous variables after the creation of auxiliary variables is stored in context.models[1].endogenous_nbr.
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
To study the effects of a temporary shock after which the system goes back to the original equilibrium (if the model is stable...) one uses a temporary shock. A temporary shock is a temporary change of value of one or several exogenous variables in the model. Temporary shocks are specified with the command shocks.
In a deterministic context, when one wants to study the transition of one equilibrium position to another, it is equivalent to analyze the consequences of a permanent shock. In Dynare this is done with initval, endval and steady.
In a stochastic framework, the exogenous variables take random values in each period. In Dynare, these random values follow a normal distribution with zero mean, but it belongs to the user to specify the variability of these shocks. The non-zero elements of the matrix of variance-covariance of the shocks can be entered with the shocks command.
overwrite: By default, if there are several shocks blocks
in the same .mod file, then they are cumulative: all the shocks declared in all the blocks are considered; however, if a shocks block is declared with the overwrite option, then it replaces all the previous shocks blocks.
For deterministic simulations, the shocks block specifies temporary changes in the value of exogenous variables. For permanent shocks, use an endval block.
The block should contain one or more occurrences of the following group of three lines:
var VARIABLE_NAME;
+Shocks on exgogenous variables · Dynare.jl
To study the effects of a temporary shock after which the system goes back to the original equilibrium (if the model is stable...) one uses a temporary shock. A temporary shock is a temporary change of value of one or several exogenous variables in the model. Temporary shocks are specified with the command shocks.
In a deterministic context, when one wants to study the transition of one equilibrium position to another, it is equivalent to analyze the consequences of a permanent shock. In Dynare this is done with initval, endval and steady.
In a stochastic framework, the exogenous variables take random values in each period. In Dynare, these random values follow a normal distribution with zero mean, but it belongs to the user to specify the variability of these shocks. The non-zero elements of the matrix of variance-covariance of the shocks can be entered with the shocks command.
overwrite: By default, if there are several shocks blocks
in the same .mod file, then they are cumulative: all the shocks declared in all the blocks are considered; however, if a shocks block is declared with the overwrite option, then it replaces all the previous shocks blocks.
For deterministic simulations, the shocks block specifies temporary changes in the value of exogenous variables. For permanent shocks, use an endval block.
The block should contain one or more occurrences of the following group of three lines:
var VARIABLE_NAME;
periods INTEGER[:INTEGER] [[,] INTEGER[:INTEGER]]...;
values DOUBLE | (EXPRESSION) [[,] DOUBLE | (EXPRESSION) ]...;
It is possible to specify shocks which last several periods and which can vary over time. The periods keyword accepts a list of several dates or date ranges, which must be matched by as many shock values in the values keyword. Note that a range in the periods keyword can be matched by only one value in the values keyword. If values represents a scalar, the same value applies to the whole range. If values represents a vector, it must have as many elements as there are periods in the range.
Note that shock values are not restricted to numerical constants: arbitrary expressions are also allowed, but you have to enclose them inside parentheses.
Exogenous variable e, takes value 0.1 in period 2.
scenario!(name = :y, value = 0.2, period=2, exogenous = :u)
Endogenous variable y is set to 0.2 in period 2 and exogenous variable u is treated as endogenous in the same period. Agents in the model know at the beginning of period 1 that this will happen.
scenario!(infoperiod = 2, name = :y, value = 0.2, period = 2,
- exogenous = :u)
Endogenous variable y is set to 0.2 in period 2 and exogenous variable u is treated as endogenous in the same period. Agents in the model only learn at the beginning of period 2 that this will happen.
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
Exogenous variable e, takes value 0.1 in period 2.
scenario!(name = :y, value = 0.2, period=2, exogenous = :u)
Endogenous variable y is set to 0.2 in period 2 and exogenous variable u is treated as endogenous in the same period. Agents in the model know at the beginning of period 1 that this will happen.
scenario!(infoperiod = 2, name = :y, value = 0.2, period = 2,
+ exogenous = :u)
Endogenous variable y is set to 0.2 in period 2 and exogenous variable u is treated as endogenous in the same period. Agents in the model only learn at the beginning of period 2 that this will happen.
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
diff --git a/dev/model-file/steady-state/index.html b/dev/model-file/steady-state/index.html
index 2df8710..34a6e41 100644
--- a/dev/model-file/steady-state/index.html
+++ b/dev/model-file/steady-state/index.html
@@ -1,5 +1,5 @@
-Steady state · Dynare.jl
There are three ways of computing the steady state (i.e. the static equilibrium) of a model. The first way is to provide the equations of the steady state in a steady_state_model block. When it is possible to derive the steady state by hand, this is the recommended way as it faster and more accurate.
The second way is to provide only a partial solution in the steady_state_model block and to compute the solution for the other variables numerically. Guess values for these other variables must be declared in a initval block. The less variables the better.
The third way is to compute the steady state value of all variables numerically. There is no steady_state_model block and a guess value must be declared for all variables. A guess value of 0 can be omitted, but be careful with variables appearing at the denominator of a fraction.
If you know how to compute the steady state for your model, you can provide a steady_state_model block, which is described below in more details. The steady state file generated by Dynare will be called +FILENAME/output/julia/FILENAME_steadystate2.jl.
Note that this block allows for updating the parameters in each call of the function. This allows for example to calibrate a model to a labor supply of 0.2 in steady state by setting the labor disutility parameter to a corresponding value. They can also be used in estimation where some parameter may be a function of an estimated parameter and needs to be updated for every parameter draw. For example, one might want to set the capital utilization cost parameter as a function of the discount rate to ensure that capacity utilization is 1 in steady state. Treating both parameters as independent or not updating one as a function of the other would lead to wrong results. But this also means that care is required. Do not accidentally overwrite your parameters with new values as it will lead to wrong results.
When the analytical solution of the model is known, this command can be used to help Dynare find the steady state in a more efficient and reliable way, especially during estimation where the steady state has to be recomputed for every point in the parameter space.
Each line of this block consists of a variable (either an endogenous, a temporary variable or a parameter) which is assigned an expression (which can contain parameters, exogenous at the steady state, or any endogenous or temporary variable already declared above). Each line therefore looks like:
VARIABLE_NAME = EXPRESSION;
Note that it is also possible to assign several variables at the same time, if the main function in the right hand side is a MATLAB/Octave function returning several arguments:
[ VARIABLE_NAME, VARIABLE_NAME... ] = EXPRESSION;
The steady_state_model block also works with deterministic models. An initval block and, when necessary, an endval block, is used to set the value of the exogenous variables. Each initval or endval block must be followed by steady to execute the function created by steady_state_model and set the initial, respectively terminal, steady state.
There are three ways of computing the steady state (i.e. the static equilibrium) of a model. The first way is to provide the equations of the steady state in a steady_state_model block. When it is possible to derive the steady state by hand, this is the recommended way as it faster and more accurate.
The second way is to provide only a partial solution in the steady_state_model block and to compute the solution for the other variables numerically. Guess values for these other variables must be declared in a initval block. The less variables the better.
The third way is to compute the steady state value of all variables numerically. There is no steady_state_model block and a guess value must be declared for all variables. A guess value of 0 can be omitted, but be careful with variables appearing at the denominator of a fraction.
If you know how to compute the steady state for your model, you can provide a steady_state_model block, which is described below in more details. The steady state file generated by Dynare will be called +FILENAME/output/julia/FILENAME_steadystate2.jl.
Note that this block allows for updating the parameters in each call of the function. This allows for example to calibrate a model to a labor supply of 0.2 in steady state by setting the labor disutility parameter to a corresponding value. They can also be used in estimation where some parameter may be a function of an estimated parameter and needs to be updated for every parameter draw. For example, one might want to set the capital utilization cost parameter as a function of the discount rate to ensure that capacity utilization is 1 in steady state. Treating both parameters as independent or not updating one as a function of the other would lead to wrong results. But this also means that care is required. Do not accidentally overwrite your parameters with new values as it will lead to wrong results.
When the analytical solution of the model is known, this command can be used to help Dynare find the steady state in a more efficient and reliable way, especially during estimation where the steady state has to be recomputed for every point in the parameter space.
Each line of this block consists of a variable (either an endogenous, a temporary variable or a parameter) which is assigned an expression (which can contain parameters, exogenous at the steady state, or any endogenous or temporary variable already declared above). Each line therefore looks like:
VARIABLE_NAME = EXPRESSION;
Note that it is also possible to assign several variables at the same time, if the main function in the right hand side is a MATLAB/Octave function returning several arguments:
[ VARIABLE_NAME, VARIABLE_NAME... ] = EXPRESSION;
The steady_state_model block also works with deterministic models. An initval block and, when necessary, an endval block, is used to set the value of the exogenous variables. Each initval or endval block must be followed by steady to execute the function created by steady_state_model and set the initial, respectively terminal, steady state.
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
@@ -85,11 +85,11 @@
steady(homotopy_mode = 1, homotopy_steps = 50);
When there is no steady state file, Dynare computes the steady state by solving the static model, i.e. the model from the .mod file from which leads and lags have been removed.
In some specific cases, one may want to have more control over the way this static model is created. Dynare therefore offers the possibility to explicitly give the form of equations that should be in the static model.
More precisely, if an equation is prepended by a [static] tag, then it will appear in the static model used for steady state computation, but that equation will not be used for other computations. For every equation tagged in this way, you must tag another equation with [dynamic]: that equation will not be used for steady state computation, but will be used for other computations.
This functionality can be useful on models with a unit root, where there is an infinity of steady states. An equation (tagged [dynamic]) would give the law of motion of the nonstationary variable (like a random walk). To pin down one specific steady state, an equation tagged [static] would affect a constant value to the nonstationary variable. Another situation where the [static] tag can be useful is when one has only a partial closed form solution for the steady state.
When there is no steady state file, Dynare computes the steady state by solving the static model, i.e. the model from the .mod file from which leads and lags have been removed.
In some specific cases, one may want to have more control over the way this static model is created. Dynare therefore offers the possibility to explicitly give the form of equations that should be in the static model.
More precisely, if an equation is prepended by a [static] tag, then it will appear in the static model used for steady state computation, but that equation will not be used for other computations. For every equation tagged in this way, you must tag another equation with [dynamic]: that equation will not be used for steady state computation, but will be used for other computations.
This functionality can be useful on models with a unit root, where there is an infinity of steady states. An equation (tagged [dynamic]) would give the law of motion of the nonstationary variable (like a random walk). To pin down one specific steady state, an equation tagged [static] would affect a constant value to the nonstationary variable. Another situation where the [static] tag can be useful is when one has only a partial closed form solution for the steady state.
A model file contains a list of commands and of blocks. Each command and each element of a block is terminated by a semicolon (;). Blocks are terminated by end;.
If Dynare encounters an unknown expression at the beginning of a line or after a semicolon, it will parse the rest of that line as native Julia code, even if there are more statements separated by semicolons present. To prevent cryptic error messages, it is strongly recommended to always only put one statement/command into each line and start a new line after each semicolon.[1]
Lines of codes can be commented out line by line or as a block. Single-line comments begin with // and stop at the end of the line. Multiline comments are introduced by /* and terminated by */.
Examples
// This is a single line comment
+Syntax elements · Dynare.jl
A model file contains a list of commands and of blocks. Each command and each element of a block is terminated by a semicolon (;). Blocks are terminated by end;.
If Dynare encounters an unknown expression at the beginning of a line or after a semicolon, it will parse the rest of that line as native Julia code, even if there are more statements separated by semicolons present. To prevent cryptic error messages, it is strongly recommended to always only put one statement/command into each line and start a new line after each semicolon.[1]
Lines of codes can be commented out line by line or as a block. Single-line comments begin with // and stop at the end of the line. Multiline comments are introduced by /* and terminated by */.
Examples
// This is a single line comment
var x; // This is a comment about x
@@ -15,4 +15,4 @@
0 &\quad\text{if }x=0\\
1 &\quad\text{if }x>0
\end{cases}
- \end{aligned}\]
Note that this function is not continuous, hence not differentiable, at $x=0$. However, for facilitating convergence of Newton-type methods, Dynare assumes that the derivative at $x=0$ is equal to $0$. This assumption comes from the observation that both the right- and left-derivatives at this point exist and are equal to $0$, so we can remove the singularity by postulating that the derivative at $x=0$ is $0$.
Function: abs(x)
Absolute value.
Note that this continuous function is not differentiable at $x=0$. However, for facilitating convergence of Newton-type methods, Dynare assumes that the derivative at $x=0$ is equal to $0$ (even if the derivative does not exist). The rational for this mathematically unfounded definition, rely on the observation that the derivative of $\mathrm{abs}(x)$ is equal to $\mathrm{sign}(x)$ for any $x\neq 0$ in $\mathbb R$ and from the convention for the value of $\mathrm{sign}(x)$ at $x=0$).
Function: sin(x)
Function: cos(x)
Function: tan(x)
Function: asin(x)
Function: acos(x)
Function: atan(x)
Trigonometric functions.
Function: sinh(x)
Function: cosh(x)
Function: tanh(x)
Function: asinh(x)
Function: acosh(x)
Function: atanh(x)
Hyperbolic functions.
Function: max(a, b)
Function: min(a, b)
Maximum and minimum of two reals.
Note that these functions are differentiable everywhere except on a line of the 2-dimensional real plane defined by $a=b$. However for facilitating convergence of Newton-type methods, Dynare assumes that, at the points of non-differentiability, the partial derivative of these functions with respect to the first (resp. the second) argument is equal to $1$ (resp. to $0$) (i.e. the derivatives at the kink are equal to the derivatives observed on the half-plane where the function is equal to its first argument).
Function: normcdf(x)
Function: normcdf(x, mu, sigma)
Gaussian cumulative density function, with mean mu and standard deviation sigma. Note that normcdf(x) is equivalent to normcdf(x,0,1).
The use of the following functions and operators is strongly discouraged in a stochastic context: max, min, abs, sign, <, >, <=, >=, ==, !=.
The reason is that the local approximation used by stoch_simul or estimation will by nature ignore the non-linearities introduced by these functions if the steady state is away from the kink. And, if the steady state is exactly at the kink, then the approximation will be bogus because the derivative of these functions at the kink is bogus (as explained in the respective documentations of these functions and operators).
Note that extended_path is not affected by this problem, because it does not rely on a local approximation of the mode.
Footnotes
1A .mod file must have lines that end with a line feed character, which is not commonly visible in text editors. Files created on Windows and Unix-based systems have always conformed to this requirement, as have files created on OS X and macOS. Files created on old, pre-OS X Macs used carriage returns as end of line characters. If you get a Dynare parsing error of the form ERROR: <<mod file>>: line 1, cols 341-347: syntax error,... and there's more than one line in your .mod file, know that it uses the carriage return as an end of line character. To get more helpful error messages, the carriage returns should be changed to line feeds.
2Note that arbitrary Julia expressions can be put in a .mod file, but those expressions have to be on separate lines, generally at the end of the file for post-processing purposes. They are not interpreted by Dynare, and are simply passed on unmodified to Julia. Those constructions are not addresses in this section.
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
+ \end{aligned}\]
Note that this function is not continuous, hence not differentiable, at $x=0$. However, for facilitating convergence of Newton-type methods, Dynare assumes that the derivative at $x=0$ is equal to $0$. This assumption comes from the observation that both the right- and left-derivatives at this point exist and are equal to $0$, so we can remove the singularity by postulating that the derivative at $x=0$ is $0$.
Function: abs(x)
Absolute value.
Note that this continuous function is not differentiable at $x=0$. However, for facilitating convergence of Newton-type methods, Dynare assumes that the derivative at $x=0$ is equal to $0$ (even if the derivative does not exist). The rational for this mathematically unfounded definition, rely on the observation that the derivative of $\mathrm{abs}(x)$ is equal to $\mathrm{sign}(x)$ for any $x\neq 0$ in $\mathbb R$ and from the convention for the value of $\mathrm{sign}(x)$ at $x=0$).
Function: sin(x)
Function: cos(x)
Function: tan(x)
Function: asin(x)
Function: acos(x)
Function: atan(x)
Trigonometric functions.
Function: sinh(x)
Function: cosh(x)
Function: tanh(x)
Function: asinh(x)
Function: acosh(x)
Function: atanh(x)
Hyperbolic functions.
Function: max(a, b)
Function: min(a, b)
Maximum and minimum of two reals.
Note that these functions are differentiable everywhere except on a line of the 2-dimensional real plane defined by $a=b$. However for facilitating convergence of Newton-type methods, Dynare assumes that, at the points of non-differentiability, the partial derivative of these functions with respect to the first (resp. the second) argument is equal to $1$ (resp. to $0$) (i.e. the derivatives at the kink are equal to the derivatives observed on the half-plane where the function is equal to its first argument).
Function: normcdf(x)
Function: normcdf(x, mu, sigma)
Gaussian cumulative density function, with mean mu and standard deviation sigma. Note that normcdf(x) is equivalent to normcdf(x,0,1).
The use of the following functions and operators is strongly discouraged in a stochastic context: max, min, abs, sign, <, >, <=, >=, ==, !=.
The reason is that the local approximation used by stoch_simul or estimation will by nature ignore the non-linearities introduced by these functions if the steady state is away from the kink. And, if the steady state is exactly at the kink, then the approximation will be bogus because the derivative of these functions at the kink is bogus (as explained in the respective documentations of these functions and operators).
Note that extended_path is not affected by this problem, because it does not rely on a local approximation of the mode.
Footnotes
1A .mod file must have lines that end with a line feed character, which is not commonly visible in text editors. Files created on Windows and Unix-based systems have always conformed to this requirement, as have files created on OS X and macOS. Files created on old, pre-OS X Macs used carriage returns as end of line characters. If you get a Dynare parsing error of the form ERROR: <<mod file>>: line 1, cols 341-347: syntax error,... and there's more than one line in your .mod file, know that it uses the carriage return as an end of line character. To get more helpful error messages, the carriage returns should be changed to line feeds.
2Note that arbitrary Julia expressions can be put in a .mod file, but those expressions have to be on separate lines, generally at the end of the file for post-processing purposes. They are not interpreted by Dynare, and are simply passed on unmodified to Julia. Those constructions are not addresses in this section.
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
While Dynare allows the user to choose their own variable names, there are some restrictions to be kept in mind. First, variables and parameters must not have the same name as Dynare commands or built-in functions. In this respect, Dynare is not case-sensitive. For example, do not use Ln or Sigma_e to name your variable. Not conforming to this rule might yield hard-to-debug error messages or crashes.
var VAR_NAME [$TEX_NAME$][(long_name=QUOTED_STRINGNAME=QUOTED_STRING)]...;
var (deflator=MODEL_EXPR) VAR_NAME (... same options apply) var(log,deflator=MODEL_EXPR) VAR_NAME (... same options apply)
var (log_deflator=MODEL_EXPR) VAR_NAME (... same options apply)
This required command declares the endogenous variables in the model. Optionally it is possible to give a LaTeX name to the variable or, if it is nonstationary, provide information regarding its deflator. The variables in the list can be separated by spaces or by commas. var commands can appear several times in the file and Dynare will concatenate them.
If the model is nonstationary and is to be written as such in the model block, Dynare will need the trend deflator for the appropriate endogenous variables in order to stationarize the model. The trend deflator must be provided alongside the variables that follow this trend.
Options
log
In addition to the endogenous variable(s) thus declared, this option also triggers the creation of auxiliary variable(s) equal to the log of the corresponding endogenous variable(s). For example, given a var(log) y statement, two endogenous will be created (y and LOG_y), and an auxiliary equation linking the two will also be added (equal to LOG_y = log(y)). Moreover, every occurence of y in the model will be replaced by exp(LOG_y). This option is for example useful when one wants to perform a loglinear approximation of some variable(s) in the context of a first-order stochastic approximation; or when one wants to ensure the variable(s) stay(s) in the definition domain of the function defining the steady state or the dynamic residuals when the nonlinear solver is used.
deflator = MODEL_EXPR
The expression used to detrend an endogenous variable. All trend variables, endogenous variables and parameters referenced in MODEL_EXPR must already have been declared by the trend_var, log_trend_var, var and parameters commands. The deflator is assumed to be multiplicative; for an additive deflator, use log_deflator. This option can be used together with the log option (the latter must come first).
log_deflator = MODEL_EXPR
Same as deflator, except that the deflator is assumed to be additive instead of multiplicative (or, to put it otherwise, the declared variable is equal to the log of a variable with a multiplicative trend). This option cannot be used together with the log option, because it would not make much sense from an economic point of view (the corresponding auxiliary variable would correspond to the log taken two times on a variable with a multiplicative trend).
long_name = QUOTED_STRING
This is the long version of the variable name. Its value is stored in M_.endo_names_long (a column cell array, in the same order as M_.endo_names). In case multiple long_name options are provided, the last one will be used. Default: VAR_NAME.
Example
var c gnp cva
+Variables and parameters declaration · Dynare.jl
While Dynare allows the user to choose their own variable names, there are some restrictions to be kept in mind. First, variables and parameters must not have the same name as Dynare commands or built-in functions. In this respect, Dynare is not case-sensitive. For example, do not use Ln or Sigma_e to name your variable. Not conforming to this rule might yield hard-to-debug error messages or crashes.
var VAR_NAME [$TEX_NAME$][(long_name=QUOTED_STRINGNAME=QUOTED_STRING)]...;
var (deflator=MODEL_EXPR) VAR_NAME (... same options apply) var(log,deflator=MODEL_EXPR) VAR_NAME (... same options apply)
var (log_deflator=MODEL_EXPR) VAR_NAME (... same options apply)
This required command declares the endogenous variables in the model. Optionally it is possible to give a LaTeX name to the variable or, if it is nonstationary, provide information regarding its deflator. The variables in the list can be separated by spaces or by commas. var commands can appear several times in the file and Dynare will concatenate them.
If the model is nonstationary and is to be written as such in the model block, Dynare will need the trend deflator for the appropriate endogenous variables in order to stationarize the model. The trend deflator must be provided alongside the variables that follow this trend.
Options
log
In addition to the endogenous variable(s) thus declared, this option also triggers the creation of auxiliary variable(s) equal to the log of the corresponding endogenous variable(s). For example, given a var(log) y statement, two endogenous will be created (y and LOG_y), and an auxiliary equation linking the two will also be added (equal to LOG_y = log(y)). Moreover, every occurence of y in the model will be replaced by exp(LOG_y). This option is for example useful when one wants to perform a loglinear approximation of some variable(s) in the context of a first-order stochastic approximation; or when one wants to ensure the variable(s) stay(s) in the definition domain of the function defining the steady state or the dynamic residuals when the nonlinear solver is used.
deflator = MODEL_EXPR
The expression used to detrend an endogenous variable. All trend variables, endogenous variables and parameters referenced in MODEL_EXPR must already have been declared by the trend_var, log_trend_var, var and parameters commands. The deflator is assumed to be multiplicative; for an additive deflator, use log_deflator. This option can be used together with the log option (the latter must come first).
log_deflator = MODEL_EXPR
Same as deflator, except that the deflator is assumed to be additive instead of multiplicative (or, to put it otherwise, the declared variable is equal to the log of a variable with a multiplicative trend). This option cannot be used together with the log option, because it would not make much sense from an economic point of view (the corresponding auxiliary variable would correspond to the log taken two times on a variable with a multiplicative trend).
long_name = QUOTED_STRING
This is the long version of the variable name. Its value is stored in M_.endo_names_long (a column cell array, in the same order as M_.endo_names). In case multiple long_name options are provided, the last one will be used. Default: VAR_NAME.
Example
var c gnp cva
cca (long_name=`Consumption CA');
var(deflator=A) i b;
var c $C$ (long_name=`Consumption');
This optional command declares the exogenous variables in the model. Optionally it is possible to give a LaTeX name to the variable. Exogenous variables are required if the user wants to be able to apply shocks to her model. The variables in the list can be separated by spaces or by commas. varexo commands can appear several times in the file and Dynare will concatenate them.
Options
long_name = QUOTED_STRING
Example
varexo m gov;
Remarks
An exogenous variable is an innovation, in the sense that this
@@ -55,4 +55,4 @@
k(1) = i|e + (1-delta|p)*k;
y|e = k|e^alpha|p;
...
-end;
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
+end;
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.
In order to give instructions to Dynare, the user has to write a model file whose filename extension must be .mod. This file contains the description of the model and the computing tasks required by the user. Its contents are described in The model file
Once the model file is written, Dynare is invoked using the @dynare Julia macro (with the filename of the .mod given as argument).
In practice, the handling of the model file is done in two steps: in the first one, the model and the processing instructions written by the user in a model file are interpreted and the proper Julia instructions are generated; in the second step, the program actually runs the computations. Both steps are triggered automatically by the @dynare macro:
This command launches Dynare and executes the instructions included in FILENAME.mod. This user-supplied file contains the model and the processing instructions, as described in The model file. The options, listed below, can be passed on the command line, following the name of the .mod file or in the first line of the .mod file itself (see below).
Dynare begins by launching the preprocessor on the .mod file.
Instructs the preprocessor to write some debugging information about the scanning and parsing of the .mod file.
notmpterms
Instructs the preprocessor to omit temporary terms in the static and dynamic files; this generally decreases performance, but is used for debugging purposes since it makes the static and dynamic files more readable.
savemacro\[=FILENAME\]
Instructs Dynare to save the intermediary file which is obtained after macro processing (see (@ref "Macro processing language")); the saved output will go in the file specified, or if no file is specified in FILENAME-macroexp.mod. See the (@ref "note on quotes") for info on passing a FILENAME argument containing spaces.
onlymacro
Instructs the preprocessor to only perform the macro processing step, and stop just after. Useful for debugging purposes or for using the macro processor independently of the rest of Dynare toolbox.
linemacro
Instructs the macro preprocessor include @#line directives specifying the line on which macro directives were encountered and expanded from. Only useful in conjunction with savemacro <savemacro[=FILENAME]>.
onlymodel
Instructs the preprocessor to print only information about the model in the driver file; no Dynare commands (other than the shocks statement and parameter initializations) are printed and hence no computational tasks performed. The same ancillary files are created as would otherwise be created (dynamic, static files, etc.).
nolog
Instructs Dynare to no create a logfile of this run in FILENAME.log. The default is to create the logfile.
output=second\|third
Instructs the preprocessor to output derivatives of the dynamic model at least up to the given order.
language=matlab\|julia
Instructs the preprocessor to write output for MATLAB or Julia. Default: MATLAB
params\_derivs\_order=0\|1\|2
When (@ref "identification"), (@ref "dynaresensitivity") (with identification), or (@ref "estimationcmd") are present, this option is used to limit the order of the derivatives with respect to the parameters that are calculated by the preprocessor. 0 means no derivatives, 1 means first derivatives, and 2 means second derivatives. Default: 2
transform\_unary\_ops
Transform the following operators in the model block into auxiliary variables: exp, log, log10, cos, sin, tan, acos, asin, atan, cosh, sinh, tanh, acosh, asinh, atanh, sqrt, cbrt, abs, sign, erf. Default: no obligatory transformation
json = parse\|transform\|compute
Causes the preprocessor to output a version of the .mod file in JSON format to <<M_.fname>>/model/json/. When the JSON output is created depends on the value passed. These values represent various steps of processing in the preprocessor.
If parse is passed, the output will be written after the parsing of the .mod file to a file called FILENAME.json but before file has been checked (e.g. if there are unused exogenous in the model block, the JSON output will be created before the preprocessor exits).
If check is passed, the output will be written to a file called FILENAME.json after the model has been checked.
If transform is passed, the JSON output of the transformed model (maximum lead of 1, minimum lag of -1, expectation operators substituted, etc.) will be written to a file called FILENAME.json and the original, untransformed model will be written in FILENAME_original.json.
And if compute is passed, the output is written after the computing pass. In this case, the transformed model is written to FILENAME.json, the original model is written to FILENAME_original.json, and the dynamic and static files are written to FILENAME_dynamic.json and FILENAME_static.json.
jsonstdout
Instead of writing output requested by json to files, write to standard out, i.e. to the Julia command window (and the log-file).
onlyjson
Quit processing once the output requested by json has been written.
jsonderivsimple
Print a simplified version (excluding variable name(s) and lag information) of the static and dynamic files in FILENAME_static.json and FILENAME_dynamic..
warn\_uninit
Display a warning for each variable or parameter which is not initialized. See (@ref "Parameter initialization"), or (@ref "loadparamsandsteadystate") for initialization of parameters. See (@ref "Initial and Terminal conditions"), or (@ref "loadparamsandsteadystate") for initialization of endogenous and exogenous variables.
nopreprocessoroutput
Prevent Dynare from printing the output of the steps leading up to the preprocessor as well as the preprocessor output itself.
-DMACRO\_VARIABLE\[=MACRO\_EXPRESSION\]
Defines a macro-variable from the command line (the same effect as using the Macro directive @#define in a model file, see (@ref "Macro processing language")). See the (@ref "note on quotes") for info on passing a MACRO_EXPRESSION argument containing spaces. Note that an expression passed on the command line can reference variables defined before it. If MACRO_EXPRESSION is omitted, the variable is assigned the true logical value.
Example
Call dynare with command line defines
julia julia> @dynare <<modfile.mod>> -DA=true '-DB="A string with space"' -DC=[1,2,3] '-DD=[ i in C when i > 1 ]' -DE;
-I\<\<path\>\>
Defines a path to search for files to be included by the macro processor (using the @#include command). Multiple -I flags can be passed on the command line. The paths will be searched in the order that the -I flags are passed and the first matching file will be used. The flags passed here take priority over those passed to @#includepath. See the (@ref "note on quotes") for info on passing a <<path>> argument containing spaces.
nostrict
Allows Dynare to issue a warning and continue processing when
there are more endogenous variables than equations.
an undeclared symbol is assigned in initval or endval.
an undeclared symbol is found in the model block in this case, it is automatically declared exogenous.
exogenous variables were declared but not used in the model block.
stochastic
Tells Dynare that the model to be solved is stochastic. If no Dynare commands related to stochastic models (stoch_simul, estimation, ...) are present in the .mod file, Dynare understands by default that the model to be solved is deterministic.
exclude\_eqs=\<\<equation\_tags\_to\_exclude\>\>
Tells Dynare to exclude all equations specified by the argument. As a .mod file must have the same number of endogenous variables as equations, when ***exclude_eqs*** is passed, certain rules are followed for excluding endogenous variables. If the endogenous tag has been set for the excluded equation, the variable it specifies is excluded. Otherwise, if the left hand side of the excluded equation is an expression that contains only one endogenous variable, that variable is excluded. If neither of these conditions hold, processing stops with an error. If an endogenous variable has been excluded by the ***exclude_eqs*** option and it exists in an equation that has not been excluded, it is transformed into an exogenous variable.
To specify which equations to exclude, you must pass the argument <<equation_tags_to_exclude>>. This argument takes either a list of equation tags specifying the equations to be excluded or a filename that contains those tags.
If <<equation_tags_to_exclude>> is a list of equation tags, it can take one of the following forms:
Given a single argument, e.g. exclude_eqs=eq1, the equation with the tag [name='eq1'] will be excluded. Note that if there is a file called eq1 in the current directory, Dynare will instead try to open this and read equations to exclude from it (see info on filename argument to exclude_eqs below). Further note that if the tag value contains a space, you must use the variant specified in 2 below, i.e. exclude_eqs=[eq 1].
Given two or more arguments, e.g. exclude_eqs=[eq1, eq 2], the equations with the tags [name='eq1'] and [name='eq 2'] will be excluded.
If you\'d like to exclude equations based on another tag name (as opposed to the default name), you can pass the argument as either e.g. exclude_eqs=[tagname=a tag] if a single equation with tag [tagname='a tag'] is to be excluded or as e.g. exclude_eqs=[tagname=(a tag, 'a tag with a, comma')] if more than one equation with tags [tagname='a tag'] and [tagname='a tag with a, comma'] will be excluded (note the parenthesis, which are required when more than one equation is specified). Note that if the value of a tag contains a comma, it must be included inside single quotes.
If <<equation_tags_to_exclude>> is a filename, the file can take one of the following forms:
One equation per line of the file, where every line represents the value passed to the name tag. e.g., a file such as: julia eq1 eq 2 would exclude equations with tags [name='eq1'] and [name='eq 2'].
One equation per line of the file, where every line after the first line represents the value passed to the tag specified by the first line. e.g., a file such as: julia tagname= a tag a tag with a, comma would exclude equations with tags [tagname='a tag'] and [tagname='a tag with a, comma']. Here note that the first line must end in an equal sign.
include\_eqs=\<\<equation\_tags\_to\_include\>\>
Tells Dynare to run with only those equations specified by the argument; in other words, Dynare will exclude all equations not specified by the argument. The argument <<equation_tags_to_include>> is specified in the same way as the argument to exclude_eqs <exclude_eqs>. The functionality of include_eqs is to find which equations to exclude then take actions in accord with (@ref "exclude_eqs").
nocommutativity
This option tells the preprocessor not to use the commutativity of addition and multiplication when looking for common subexpressions. As a consequence, when using this option, equations in various outputs (LaTeX, JSON...) will appear as the user entered them (without terms or factors swapped). Note that using this option may have a performance impact on the preprocessing stage, though it is likely to be small.
These options can be passed to the preprocessor by listing them after the name of the .mod file. They can alternatively be defined in the first line of the .mod file, this avoids typing them on the command line each time a .mod file is to be run. This line must be a Dynare one-line comment (i.e. must begin with //) and the options must be whitespace separated between --+ options: and +--. Note that any text after the +-- will be discarded. As in the command line, if an option admits a value the equal symbol must not be surrounded by spaces. For instance json = compute is not correct, and should be written json=compute. The nopathchange option cannot be specified in this way, it must be passed on the command-line.
If the preprocessor runs into an error while processing your .mod file, it will issue an error. Due to the way that a parser works, sometimes these errors can be misleading. Here, we aim to demystify these error messages.
The preprocessor issues error messages of the form:
ERROR: <<file.mod>>: line A, col B: <<error message>>
ERROR: <<file.mod>>: line A, cols B-C: <<error message>>
ERROR: <<file.mod>>: line A, col B - line C, col D: <<error message>>
The first two errors occur on a single line, with error two spanning multiple columns. Error three spans multiple rows.
Often, the line and column numbers are precise, leading you directly to the offending syntax. Infrequently however, because of the way the parser works, this is not the case. The most common example of misleading line and column numbers (and error message for that matter) is the case of a missing semicolon, as seen in the following example:
varexo a, b
-parameters c, ...;
In this case, the parser doesn't know a semicolon is missing at the end of the varexo command until it begins parsing the second line and bumps into the parameters command. This is because we allow commands to span multiple lines and, hence, the parser cannot know that the second line will not have a semicolon on it until it gets there. Once the parser begins parsing the second line, it realizes that it has encountered a keyword, parameters, which it did not expect. Hence, it throws an error of the form: ERROR: <<file.mod>>: line 2, cols 0-9: syntax error, unexpected PARAMETERS. In this case, you would simply place a semicolon at the end of line one and the parser would continue processing.
Settings
This document was generated with Documenter.jl version 1.3.0 on Monday 25 March 2024. Using Julia version 1.9.4.
In order to give instructions to Dynare, the user has to write a model file whose filename extension must be .mod. This file contains the description of the model and the computing tasks required by the user. Its contents are described in The model file
Once the model file is written, Dynare is invoked using the @dynare Julia macro (with the filename of the .mod given as argument).
In practice, the handling of the model file is done in two steps: in the first one, the model and the processing instructions written by the user in a model file are interpreted and the proper Julia instructions are generated; in the second step, the program actually runs the computations. Both steps are triggered automatically by the @dynare macro:
This command launches Dynare and executes the instructions included in FILENAME.mod. This user-supplied file contains the model and the processing instructions, as described in The model file. The options, listed below, can be passed on the command line, following the name of the .mod file or in the first line of the .mod file itself (see below).
Dynare begins by launching the preprocessor on the .mod file.
Instructs the preprocessor to write some debugging information about the scanning and parsing of the .mod file.
notmpterms
Instructs the preprocessor to omit temporary terms in the static and dynamic files; this generally decreases performance, but is used for debugging purposes since it makes the static and dynamic files more readable.
savemacro\[=FILENAME\]
Instructs Dynare to save the intermediary file which is obtained after macro processing (see (@ref "Macro processing language")); the saved output will go in the file specified, or if no file is specified in FILENAME-macroexp.mod. See the (@ref "note on quotes") for info on passing a FILENAME argument containing spaces.
onlymacro
Instructs the preprocessor to only perform the macro processing step, and stop just after. Useful for debugging purposes or for using the macro processor independently of the rest of Dynare toolbox.
linemacro
Instructs the macro preprocessor include @#line directives specifying the line on which macro directives were encountered and expanded from. Only useful in conjunction with savemacro <savemacro[=FILENAME]>.
onlymodel
Instructs the preprocessor to print only information about the model in the driver file; no Dynare commands (other than the shocks statement and parameter initializations) are printed and hence no computational tasks performed. The same ancillary files are created as would otherwise be created (dynamic, static files, etc.).
nolog
Instructs Dynare to no create a logfile of this run in FILENAME.log. The default is to create the logfile.
output=second\|third
Instructs the preprocessor to output derivatives of the dynamic model at least up to the given order.
language=matlab\|julia
Instructs the preprocessor to write output for MATLAB or Julia. Default: MATLAB
params\_derivs\_order=0\|1\|2
When (@ref "identification"), (@ref "dynaresensitivity") (with identification), or (@ref "estimationcmd") are present, this option is used to limit the order of the derivatives with respect to the parameters that are calculated by the preprocessor. 0 means no derivatives, 1 means first derivatives, and 2 means second derivatives. Default: 2
transform\_unary\_ops
Transform the following operators in the model block into auxiliary variables: exp, log, log10, cos, sin, tan, acos, asin, atan, cosh, sinh, tanh, acosh, asinh, atanh, sqrt, cbrt, abs, sign, erf. Default: no obligatory transformation
json = parse\|transform\|compute
Causes the preprocessor to output a version of the .mod file in JSON format to <<M_.fname>>/model/json/. When the JSON output is created depends on the value passed. These values represent various steps of processing in the preprocessor.
If parse is passed, the output will be written after the parsing of the .mod file to a file called FILENAME.json but before file has been checked (e.g. if there are unused exogenous in the model block, the JSON output will be created before the preprocessor exits).
If check is passed, the output will be written to a file called FILENAME.json after the model has been checked.
If transform is passed, the JSON output of the transformed model (maximum lead of 1, minimum lag of -1, expectation operators substituted, etc.) will be written to a file called FILENAME.json and the original, untransformed model will be written in FILENAME_original.json.
And if compute is passed, the output is written after the computing pass. In this case, the transformed model is written to FILENAME.json, the original model is written to FILENAME_original.json, and the dynamic and static files are written to FILENAME_dynamic.json and FILENAME_static.json.
jsonstdout
Instead of writing output requested by json to files, write to standard out, i.e. to the Julia command window (and the log-file).
onlyjson
Quit processing once the output requested by json has been written.
jsonderivsimple
Print a simplified version (excluding variable name(s) and lag information) of the static and dynamic files in FILENAME_static.json and FILENAME_dynamic..
warn\_uninit
Display a warning for each variable or parameter which is not initialized. See (@ref "Parameter initialization"), or (@ref "loadparamsandsteadystate") for initialization of parameters. See (@ref "Initial and Terminal conditions"), or (@ref "loadparamsandsteadystate") for initialization of endogenous and exogenous variables.
nopreprocessoroutput
Prevent Dynare from printing the output of the steps leading up to the preprocessor as well as the preprocessor output itself.
-DMACRO\_VARIABLE\[=MACRO\_EXPRESSION\]
Defines a macro-variable from the command line (the same effect as using the Macro directive @#define in a model file, see (@ref "Macro processing language")). See the (@ref "note on quotes") for info on passing a MACRO_EXPRESSION argument containing spaces. Note that an expression passed on the command line can reference variables defined before it. If MACRO_EXPRESSION is omitted, the variable is assigned the true logical value.
Example
Call dynare with command line defines
julia julia> @dynare <<modfile.mod>> -DA=true '-DB="A string with space"' -DC=[1,2,3] '-DD=[ i in C when i > 1 ]' -DE;
-I\<\<path\>\>
Defines a path to search for files to be included by the macro processor (using the @#include command). Multiple -I flags can be passed on the command line. The paths will be searched in the order that the -I flags are passed and the first matching file will be used. The flags passed here take priority over those passed to @#includepath. See the (@ref "note on quotes") for info on passing a <<path>> argument containing spaces.
nostrict
Allows Dynare to issue a warning and continue processing when
there are more endogenous variables than equations.
an undeclared symbol is assigned in initval or endval.
an undeclared symbol is found in the model block in this case, it is automatically declared exogenous.
exogenous variables were declared but not used in the model block.
stochastic
Tells Dynare that the model to be solved is stochastic. If no Dynare commands related to stochastic models (stoch_simul, estimation, ...) are present in the .mod file, Dynare understands by default that the model to be solved is deterministic.
exclude\_eqs=\<\<equation\_tags\_to\_exclude\>\>
Tells Dynare to exclude all equations specified by the argument. As a .mod file must have the same number of endogenous variables as equations, when ***exclude_eqs*** is passed, certain rules are followed for excluding endogenous variables. If the endogenous tag has been set for the excluded equation, the variable it specifies is excluded. Otherwise, if the left hand side of the excluded equation is an expression that contains only one endogenous variable, that variable is excluded. If neither of these conditions hold, processing stops with an error. If an endogenous variable has been excluded by the ***exclude_eqs*** option and it exists in an equation that has not been excluded, it is transformed into an exogenous variable.
To specify which equations to exclude, you must pass the argument <<equation_tags_to_exclude>>. This argument takes either a list of equation tags specifying the equations to be excluded or a filename that contains those tags.
If <<equation_tags_to_exclude>> is a list of equation tags, it can take one of the following forms:
Given a single argument, e.g. exclude_eqs=eq1, the equation with the tag [name='eq1'] will be excluded. Note that if there is a file called eq1 in the current directory, Dynare will instead try to open this and read equations to exclude from it (see info on filename argument to exclude_eqs below). Further note that if the tag value contains a space, you must use the variant specified in 2 below, i.e. exclude_eqs=[eq 1].
Given two or more arguments, e.g. exclude_eqs=[eq1, eq 2], the equations with the tags [name='eq1'] and [name='eq 2'] will be excluded.
If you\'d like to exclude equations based on another tag name (as opposed to the default name), you can pass the argument as either e.g. exclude_eqs=[tagname=a tag] if a single equation with tag [tagname='a tag'] is to be excluded or as e.g. exclude_eqs=[tagname=(a tag, 'a tag with a, comma')] if more than one equation with tags [tagname='a tag'] and [tagname='a tag with a, comma'] will be excluded (note the parenthesis, which are required when more than one equation is specified). Note that if the value of a tag contains a comma, it must be included inside single quotes.
If <<equation_tags_to_exclude>> is a filename, the file can take one of the following forms:
One equation per line of the file, where every line represents the value passed to the name tag. e.g., a file such as: julia eq1 eq 2 would exclude equations with tags [name='eq1'] and [name='eq 2'].
One equation per line of the file, where every line after the first line represents the value passed to the tag specified by the first line. e.g., a file such as: julia tagname= a tag a tag with a, comma would exclude equations with tags [tagname='a tag'] and [tagname='a tag with a, comma']. Here note that the first line must end in an equal sign.
include\_eqs=\<\<equation\_tags\_to\_include\>\>
Tells Dynare to run with only those equations specified by the argument; in other words, Dynare will exclude all equations not specified by the argument. The argument <<equation_tags_to_include>> is specified in the same way as the argument to exclude_eqs <exclude_eqs>. The functionality of include_eqs is to find which equations to exclude then take actions in accord with (@ref "exclude_eqs").
nocommutativity
This option tells the preprocessor not to use the commutativity of addition and multiplication when looking for common subexpressions. As a consequence, when using this option, equations in various outputs (LaTeX, JSON...) will appear as the user entered them (without terms or factors swapped). Note that using this option may have a performance impact on the preprocessing stage, though it is likely to be small.
These options can be passed to the preprocessor by listing them after the name of the .mod file. They can alternatively be defined in the first line of the .mod file, this avoids typing them on the command line each time a .mod file is to be run. This line must be a Dynare one-line comment (i.e. must begin with //) and the options must be whitespace separated between --+ options: and +--. Note that any text after the +-- will be discarded. As in the command line, if an option admits a value the equal symbol must not be surrounded by spaces. For instance json = compute is not correct, and should be written json=compute. The nopathchange option cannot be specified in this way, it must be passed on the command-line.
If the preprocessor runs into an error while processing your .mod file, it will issue an error. Due to the way that a parser works, sometimes these errors can be misleading. Here, we aim to demystify these error messages.
The preprocessor issues error messages of the form:
ERROR: <<file.mod>>: line A, col B: <<error message>>
ERROR: <<file.mod>>: line A, cols B-C: <<error message>>
ERROR: <<file.mod>>: line A, col B - line C, col D: <<error message>>
The first two errors occur on a single line, with error two spanning multiple columns. Error three spans multiple rows.
Often, the line and column numbers are precise, leading you directly to the offending syntax. Infrequently however, because of the way the parser works, this is not the case. The most common example of misleading line and column numbers (and error message for that matter) is the case of a missing semicolon, as seen in the following example:
varexo a, b
+parameters c, ...;
In this case, the parser doesn't know a semicolon is missing at the end of the varexo command until it begins parsing the second line and bumps into the parameters command. This is because we allow commands to span multiple lines and, hence, the parser cannot know that the second line will not have a semicolon on it until it gets there. Once the parser begins parsing the second line, it realizes that it has encountered a keyword, parameters, which it did not expect. Hence, it throws an error of the form: ERROR: <<file.mod>>: line 2, cols 0-9: syntax error, unexpected PARAMETERS. In this case, you would simply place a semicolon at the end of line one and the parser would continue processing.
Settings
This document was generated with Documenter.jl version 1.3.0 on Thursday 28 March 2024. Using Julia version 1.9.4.