dynare issues https://git.dynare.org/Dynare/dynare/issues 2019-10-10T08:24:42Z https://git.dynare.org/Dynare/dynare/issues/825 Fix using steady state operator on exogenous variables 2019-10-10T08:24:42Z Johannes Pfeifer Fix using steady state operator on exogenous variables 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. 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. MichelJuillard Houtan Bastani FerhatMihoubi MichelJuillard https://git.dynare.org/Dynare/dynare/issues/819 Support DSGE-VAR forecasts 2018-09-11T15:00:44Z Johannes Pfeifer Support DSGE-VAR forecasts Currently, 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/713 Block recursive prior definitions 2018-09-11T15:00:44Z Johannes Pfeifer Block recursive prior definitions 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? 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/709 Preprocessor: Allow reusage of model local variable names in steady_state_mod... 2018-09-11T15:00:44Z Tom Holden Preprocessor: 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/674 Improve error message in Dynare++ for BK-Violation 2019-08-14T12:25:02Z Johannes Pfeifer Improve error message in Dynare++ for BK-Violation See 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 Villemot Sébastien Villemot https://git.dynare.org/Dynare/dynare/issues/526 Support the estimation of static models 2018-11-08T11:49:07Z Johannes Pfeifer Support the estimation of static models See 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/444 Document nonlinear filters on a wiki page 2019-09-20T09:51:02Z Stéphane Adjemian stepan@dynare.org Document nonlinear filters on a wiki page 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). 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 Adjemian stepan@dynare.org Stéphane Adjemian stepan@dynare.org https://git.dynare.org/Dynare/dynare/issues/326 Change color scheme of figures to be readable on monochrome printouts 2019-06-19T15:37:41Z Johannes Pfeifer Change color scheme of figures to be readable on monochrome printouts More information will be provided soon. More information will be provided soon. https://git.dynare.org/Dynare/dynare/issues/312 Allow User to choose Mean or Median statistics 2019-06-19T15:37:41Z Johannes Pfeifer Allow User to choose Mean or Median statistics 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. 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/295 offer a quiet and a verbose mode 2019-06-19T15:37:41Z Sébastien Villemot offer a quiet and a verbose mode 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. 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/285 Allow user-specified path for exogenous in extended_path 2019-06-19T15:37:42Z Sébastien Villemot Allow user-specified path for exogenous in extended_path That could be implemented with the shocks blocks. That could be implemented with the shocks blocks. https://git.dynare.org/Dynare/dynare/issues/263 latex variable with exponent causes compilation error 2019-06-19T15:37:42Z Sébastien Villemot latex variable with exponent causes compilation error 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 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 Bastani Houtan Bastani https://git.dynare.org/Dynare/dynare/issues/251 SMM: create preprocessor interface, make it compatible with Octave 2019-06-19T15:37:42Z Sébastien Villemot SMM: create preprocessor interface, make it compatible with Octave In 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/248 Add tests for the parallelization engine 2019-06-19T15:37:42Z Sébastien Villemot Add tests for the parallelization engine Marco Ratto Marco Ratto https://git.dynare.org/Dynare/dynare/issues/240 rewrite getPowerDeriv assignments in temporary terms 2019-06-19T15:37:42Z Sébastien Villemot rewrite getPowerDeriv assignments in temporary terms 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 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/226 New estimation 2019-06-19T15:37:42Z Sébastien Villemot New estimation 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). 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 Adjemian stepan@dynare.org Stéphane Adjemian stepan@dynare.org https://git.dynare.org/Dynare/dynare/issues/172 improve derivation engine for derivatives of STEADY_STATE wrt parameters 2019-06-19T15:37:42Z Sébastien Villemot improve derivation engine for derivatives of STEADY_STATE wrt parameters 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. 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/163 Finish first version of internal documentation 2019-06-19T15:37:43Z Sébastien Villemot Finish first version of internal documentation See 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/162 Global method: stochastic simulation approach 2019-06-19T15:37:43Z Sébastien Villemot Global method: stochastic simulation approach As 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/149 Handle missing values in block decomposed version of Kalman filter 2019-06-19T15:37:43Z Sébastien Villemot Handle missing values in block decomposed version of Kalman filter