dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-10-10T08:24:42Zhttps://git.dynare.org/Dynare/dynare/issues/825Fix using steady state operator on exogenous variables2019-10-10T08:24:42ZJohannes Pfeifer Fix using steady state operator on exogenous variablesThe mod-file
```
var c, h, pi, w, R, r_e, y, gdp, gdp_hat, k, g, w_tilde, w_eq, w_min;
varexo d, z, eta;
parameters beta, sigma, gamma, theta, ni, tau_w, phi_p, phi_y, rho, alpha;
beta = 0.997;
sigma = 1;
gamma = 458.4;
theta = 6.1;
tau_w = 0.2;
ni = 0.28;
phi_p = 1.5;
phi_y = 0.125;
rho = 0.3;
alpha = 0.064;
model;
w_tilde=rho/(1+pi)*w(-1)+(1-rho)*w_eq;
w_eq =(1-alpha)*steady_state(z)*steady_state(h)^(-alpha);
w_min =w(-1)/(1+pi);
//mrs=c^sigma*h^ni/(1-tau_w);
gdp_hat =log(gdp)-log(steady_state(gdp));
r_e=1/(beta*d(+1))-1;
//FOC labor
c^sigma*h^ni=max(w_tilde,w_min)*(1-tau_w);
//Euler equation 1
1=beta*d(+1)*(1+R)/(1+pi(+1))*(c/c(+1))^sigma;
//Euler equation 2
0=(1/(1-alpha))*max(w_tilde,w_min)/z*h^alpha-1-gamma/theta*pi*(1+pi)+beta*d(+1)*(c/c(+1))^sigma * y(+1)/y*gamma/theta*pi(+1)*(1+pi(+1));
// Taylor rule with ZLB
R=max(0,r_e+phi_p*pi+phi_y*gdp_hat);
//output
y=z*h^(1-alpha);
//aggregate resource constraint
c=(1-k-eta)*y;
// resource cost of price adjustment
k=(gamma/2)*(pi^2);
//government purchases
g=eta*y;
// GDP
gdp=(1-k)*y;
//utility
//u=(c^(1-sigma))/(1-sigma)-(h^(1+ni))/(1+ni);
end;
initval;
z=1;
d=1;
pi=0;
k=(gamma/2)*(pi^2);
r_e=1/(beta*d)-1;
h=1;
y=z*h^(1-alpha);
g=eta*y;
c=(1-k-eta)*y;
//w=z;
//w=(1-alpha)/(h^alpha);
gdp=(1-k)*y;
R=r_e;
eta=0.2;
end;
steady;
check;
```
uses `steady_state(z)` where `z` is an exogenous variable. In the `_dynamic` file, the preprocessor translates this to `oo_.exo_steady_state(2)` which does not exist in the `_dynamic` file, leading to a crash. We should either disallow using the steady state operator on exogenous variables or simply enforce that the steady state of exogenous variables is 0. I would prefer the first one as the second would only be viable for stochastic simulations.
The mod-file
```
var c, h, pi, w, R, r_e, y, gdp, gdp_hat, k, g, w_tilde, w_eq, w_min;
varexo d, z, eta;
parameters beta, sigma, gamma, theta, ni, tau_w, phi_p, phi_y, rho, alpha;
beta = 0.997;
sigma = 1;
gamma = 458.4;
theta = 6.1;
tau_w = 0.2;
ni = 0.28;
phi_p = 1.5;
phi_y = 0.125;
rho = 0.3;
alpha = 0.064;
model;
w_tilde=rho/(1+pi)*w(-1)+(1-rho)*w_eq;
w_eq =(1-alpha)*steady_state(z)*steady_state(h)^(-alpha);
w_min =w(-1)/(1+pi);
//mrs=c^sigma*h^ni/(1-tau_w);
gdp_hat =log(gdp)-log(steady_state(gdp));
r_e=1/(beta*d(+1))-1;
//FOC labor
c^sigma*h^ni=max(w_tilde,w_min)*(1-tau_w);
//Euler equation 1
1=beta*d(+1)*(1+R)/(1+pi(+1))*(c/c(+1))^sigma;
//Euler equation 2
0=(1/(1-alpha))*max(w_tilde,w_min)/z*h^alpha-1-gamma/theta*pi*(1+pi)+beta*d(+1)*(c/c(+1))^sigma * y(+1)/y*gamma/theta*pi(+1)*(1+pi(+1));
// Taylor rule with ZLB
R=max(0,r_e+phi_p*pi+phi_y*gdp_hat);
//output
y=z*h^(1-alpha);
//aggregate resource constraint
c=(1-k-eta)*y;
// resource cost of price adjustment
k=(gamma/2)*(pi^2);
//government purchases
g=eta*y;
// GDP
gdp=(1-k)*y;
//utility
//u=(c^(1-sigma))/(1-sigma)-(h^(1+ni))/(1+ni);
end;
initval;
z=1;
d=1;
pi=0;
k=(gamma/2)*(pi^2);
r_e=1/(beta*d)-1;
h=1;
y=z*h^(1-alpha);
g=eta*y;
c=(1-k-eta)*y;
//w=z;
//w=(1-alpha)/(h^alpha);
gdp=(1-k)*y;
R=r_e;
eta=0.2;
end;
steady;
check;
```
uses `steady_state(z)` where `z` is an exogenous variable. In the `_dynamic` file, the preprocessor translates this to `oo_.exo_steady_state(2)` which does not exist in the `_dynamic` file, leading to a crash. We should either disallow using the steady state operator on exogenous variables or simply enforce that the steady state of exogenous variables is 0. I would prefer the first one as the second would only be viable for stochastic simulations.
MichelJuillardHoutan BastaniFerhatMihoubiMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/819Support DSGE-VAR forecasts2018-09-11T15:00:44ZJohannes Pfeifer Support DSGE-VAR forecastsCurrently, forecasts are based on the DSGE model and not the DSGE-VAR
Currently, forecasts are based on the DSGE model and not the DSGE-VAR
https://git.dynare.org/Dynare/dynare/issues/713Block recursive prior definitions2018-09-11T15:00:44ZJohannes Pfeifer Block recursive prior definitionsRecursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
Recursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
https://git.dynare.org/Dynare/dynare/issues/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2018-09-11T15:00:44ZTom HoldenPreprocessor: Allow reusage of model local variable names in steady_state_model block (wishlist)At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
https://git.dynare.org/Dynare/dynare/issues/674Improve error message in Dynare++ for BK-Violation2019-08-14T12:25:02ZJohannes Pfeifer Improve error message in Dynare++ for BK-ViolationSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5790
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5790
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/526Support the estimation of static models2018-11-08T11:49:07ZJohannes Pfeifer Support the estimation of static modelsSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5120
It seems not all variables are correctly initialized
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5120
It seems not all variables are correctly initialized
https://git.dynare.org/Dynare/dynare/issues/444Document nonlinear filters on a wiki page2019-09-20T09:51:02ZStéphane Adjemianstepan@dynare.orgDocument nonlinear filters on a wiki pageWe need to describe and discuss all the available options in `options_.particle` (there is still no interface for these options because the set of options is not yet stable).
We need to describe and discuss all the available options in `options_.particle` (there is still no interface for these options because the set of options is not yet stable).
Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/326Change color scheme of figures to be readable on monochrome printouts2019-06-19T15:37:41ZJohannes Pfeifer Change color scheme of figures to be readable on monochrome printoutsMore information will be provided soon.
More information will be provided soon.
https://git.dynare.org/Dynare/dynare/issues/312Allow User to choose Mean or Median statistics2019-06-19T15:37:41ZJohannes Pfeifer Allow User to choose Mean or Median statisticsCurrently the posterior IRFs make hardcoded use of the Mean IRFs,although we also compute the median. It might be good to let the user decide. This mainly affects PosteriorIRF and PosteriorIRF_core2, but could also be relevant at other places in the code.
Currently the posterior IRFs make hardcoded use of the Mean IRFs,although we also compute the median. It might be good to let the user decide. This mainly affects PosteriorIRF and PosteriorIRF_core2, but could also be relevant at other places in the code.
https://git.dynare.org/Dynare/dynare/issues/295offer a quiet and a verbose mode2019-06-19T15:37:41ZSébastien Villemotoffer a quiet and a verbose modeSome users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
Some users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
https://git.dynare.org/Dynare/dynare/issues/285Allow user-specified path for exogenous in extended_path2019-06-19T15:37:42ZSébastien VillemotAllow user-specified path for exogenous in extended_pathThat could be implemented with the shocks blocks.
That could be implemented with the shocks blocks.
https://git.dynare.org/Dynare/dynare/issues/263latex variable with exponent causes compilation error2019-06-19T15:37:42ZSébastien Villemotlatex variable with exponent causes compilation errorSee: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3846
Quick fix is to require users to place brackets around latex
variables containing exponents (and probably underscores)
Complete fix is to place braces around variables with lead/lags and those variables with no lead/lag but that are followed by an exponent. In the user's case, we would output: B^problem_t-1^\rho
See: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3846
Quick fix is to require users to place brackets around latex
variables containing exponents (and probably underscores)
Complete fix is to place braces around variables with lead/lags and those variables with no lead/lag but that are followed by an exponent. In the user's case, we would output: B^problem_t-1^\rho
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/251SMM: create preprocessor interface, make it compatible with Octave2019-06-19T15:37:42ZSébastien VillemotSMM: create preprocessor interface, make it compatible with OctaveIn particular, the current code is not compatible with Octave since it uses RandStream at several places.
In particular, the current code is not compatible with Octave since it uses RandStream at several places.
https://git.dynare.org/Dynare/dynare/issues/248Add tests for the parallelization engine2019-06-19T15:37:42ZSébastien VillemotAdd tests for the parallelization engineMarco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/240rewrite getPowerDeriv assignments in temporary terms2019-06-19T15:37:42ZSébastien Villemotrewrite getPowerDeriv assignments in temporary termsFrom Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
From Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
https://git.dynare.org/Dynare/dynare/issues/226New estimation2019-06-19T15:37:42ZSébastien VillemotNew estimationWrite the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).
Write the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).
Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/172improve derivation engine for derivatives of STEADY_STATE wrt parameters2019-06-19T15:37:42ZSébastien Villemotimprove derivation engine for derivatives of STEADY_STATE wrt parametersCurrently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
Currently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
https://git.dynare.org/Dynare/dynare/issues/163Finish first version of internal documentation2019-06-19T15:37:43ZSébastien VillemotFinish first version of internal documentationSee doc/internals/dynare-internals.org for the first draft.
For the IMF.
See doc/internals/dynare-internals.org for the first draft.
For the IMF.
https://git.dynare.org/Dynare/dynare/issues/162Global method: stochastic simulation approach2019-06-19T15:37:43ZSébastien VillemotGlobal method: stochastic simulation approachAs advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
As advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
https://git.dynare.org/Dynare/dynare/issues/149Handle missing values in block decomposed version of Kalman filter2019-06-19T15:37:43ZSébastien VillemotHandle missing values in block decomposed version of Kalman filter