dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:37:41Zhttps://git.dynare.org/Dynare/dynare/issues/1555Allow mod files to be read from stdin2019-06-19T15:37:41ZHoutan BastaniAllow mod files to be read from stdinAllow a .mod file to be piped into the preprocessor.
For the GUIAllow a .mod file to be piped into the preprocessor.
For the GUI5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1550Support in-line comments in macroprocessor2019-06-19T15:37:41ZTom HoldenSupport in-line comments in macroprocessorThis page: http://www.dynare.org/manual/Macro_002dprocessing-language.html#Macro_002dprocessing-language
contains an example in which a pre-processor definition is followed by a // comment. This generates an error in reality. Try e.g.
```
@#define x = 5 // Integer
parameters a;
a = 1;
```
This is something that should be supported though. The simplest solution would be for the pre-processor to remove all // comments in the generated -macroexp.mod.
This page: http://www.dynare.org/manual/Macro_002dprocessing-language.html#Macro_002dprocessing-language
contains an example in which a pre-processor definition is followed by a // comment. This generates an error in reality. Try e.g.
```
@#define x = 5 // Integer
parameters a;
a = 1;
```
This is something that should be supported though. The simplest solution would be for the pre-processor to remove all // comments in the generated -macroexp.mod.
5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1414command options should be made local, and a new syntax should provide persist...2019-01-15T10:52:35ZHoutan Bastanicommand options should be made local, and a new syntax should provide persistent optionsAllow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)Allow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1208updated2histval2018-11-08T10:17:14ZMarco Rattoupdated2histvalfor real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
for real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
5.0https://git.dynare.org/Dynare/dynare/issues/1204Crash in unstable mex when called from parallel workers2018-11-08T10:16:48ZTom HoldenCrash in unstable mex when called from parallel workersI'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
I'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1195Fix parallel error/warning on Windows systems2019-06-19T15:37:50ZJohannes Pfeifer Fix parallel error/warning on Windows systems`dynareParallelDelete.m` has in line 51 a delete statment containing a `$` sign, which is not valid Windows code.
`dynareParallelDelete.m` has in line 51 a delete statment containing a `$` sign, which is not valid Windows code.
5.0Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1173Support estimation under optimal policy2019-09-20T06:36:13ZJohannes Pfeifer Support estimation under optimal policySee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
5.0https://git.dynare.org/Dynare/dynare/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2018-09-11T15:00:44ZTom HoldenNon-bayesian estimation should use quasi-Maximum likelihood standard errorsAt present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
At present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
5.0Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1162Handling of trends2018-09-11T15:00:44ZMichelJuillardHandling of trendsCurrently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
Currently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
5.0https://git.dynare.org/Dynare/dynare/issues/1160Implement filter_covariance option in Bayesian estimation2019-06-19T15:37:51ZJohannes Pfeifer Implement filter_covariance option in Bayesian estimationCurrently only possible in ML and calibrated smoother
Currently only possible in ML and calibrated smoother
5.0https://git.dynare.org/Dynare/dynare/issues/1154Investigate crash of Octave under Windows2019-06-19T15:37:51ZJohannes Pfeifer Investigate crash of Octave under WindowsThere are two problems with the following mod-file under Octave
```
var ygap pinf i u p a r_nat;
varexo eu ea;
parameters csigma cbeta crhou ckappa cweightygap crpinf cry clambda cepsilon ctheta cphi crhoa calfa;
csigma = 1.0;
cbeta = 0.99;
crhou = 0.8 ;
cweightygap = .1;
crpinf = 1.5;
cry = 0.125;
cepsilon = 6;
ctheta = 2/3;
calfa = 0.33;
cphi = 1;
clambda = (1-ctheta)*(1-ctheta*cbeta)/ctheta *(1-calfa)/(1-calfa+calfa*cepsilon);
ckappa = clambda*(csigma+(cphi+calfa)/(1-calfa));
calphax = ckappa/cepsilon;
crhoa =0.9;
model(linear);
ygap = ygap(+1) - (1/csigma)*(i-pinf(+1) - r_nat);
pinf = cbeta*pinf(+1) + ckappa*ygap + u;
u = crhou*u(-1) + eu;
p=p(-1)+pinf;
// the exogenous processes for productivity
a = crhoa*a(-1) + ea;
// the process for the natural rate can be derived from the flexible economy solution
r_nat = csigma*(1+cphi)/((1-calfa)*csigma+cphi+calfa)*(crhoa-1)*a;
end;
shocks;
var eu; stderr 1;
var ea; stderr 1;
end;
// ramsey
planner_objective(ckappa/cepsilon*ygap^2+pinf^2);
ramsey_policy(planner_discount=0.99,order=1,instruments=(i),irf=12);
```
First of all, when no mex-files are present, `mjdgges.m` returns very different results than Matlab or the mex-file. While Octave then returns a rank failure, Matlab finds a small, but OK condition number and continues.
Second, when using the mex-files, Dynare crashes Octave 3.8.2 when computing theoretical moments. The culprit is the call to `ordschur.oct` in `lyap_symm`. The attached files allow to reproduce the error:
[crash_octave.zip](https://github.com/DynareTeam/dynare/files/193860/crash_octave.zip)
My guess is that the problem stems from `p`, which has a unit root and therefore non-finite second moments. This seems to be incorrectly handled.
There are two problems with the following mod-file under Octave
```
var ygap pinf i u p a r_nat;
varexo eu ea;
parameters csigma cbeta crhou ckappa cweightygap crpinf cry clambda cepsilon ctheta cphi crhoa calfa;
csigma = 1.0;
cbeta = 0.99;
crhou = 0.8 ;
cweightygap = .1;
crpinf = 1.5;
cry = 0.125;
cepsilon = 6;
ctheta = 2/3;
calfa = 0.33;
cphi = 1;
clambda = (1-ctheta)*(1-ctheta*cbeta)/ctheta *(1-calfa)/(1-calfa+calfa*cepsilon);
ckappa = clambda*(csigma+(cphi+calfa)/(1-calfa));
calphax = ckappa/cepsilon;
crhoa =0.9;
model(linear);
ygap = ygap(+1) - (1/csigma)*(i-pinf(+1) - r_nat);
pinf = cbeta*pinf(+1) + ckappa*ygap + u;
u = crhou*u(-1) + eu;
p=p(-1)+pinf;
// the exogenous processes for productivity
a = crhoa*a(-1) + ea;
// the process for the natural rate can be derived from the flexible economy solution
r_nat = csigma*(1+cphi)/((1-calfa)*csigma+cphi+calfa)*(crhoa-1)*a;
end;
shocks;
var eu; stderr 1;
var ea; stderr 1;
end;
// ramsey
planner_objective(ckappa/cepsilon*ygap^2+pinf^2);
ramsey_policy(planner_discount=0.99,order=1,instruments=(i),irf=12);
```
First of all, when no mex-files are present, `mjdgges.m` returns very different results than Matlab or the mex-file. While Octave then returns a rank failure, Matlab finds a small, but OK condition number and continues.
Second, when using the mex-files, Dynare crashes Octave 3.8.2 when computing theoretical moments. The culprit is the call to `ordschur.oct` in `lyap_symm`. The attached files allow to reproduce the error:
[crash_octave.zip](https://github.com/DynareTeam/dynare/files/193860/crash_octave.zip)
My guess is that the problem stems from `p`, which has a unit root and therefore non-finite second moments. This seems to be incorrectly handled.
5.0https://git.dynare.org/Dynare/dynare/issues/1114create contributions.md describing how to contribute to dynare2018-11-08T11:54:36ZHoutan Bastanicreate contributions.md describing how to contribute to dynare5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1113Make Dynare compatible with Octave 4.22019-06-19T15:37:52ZJohannes Pfeifer Make Dynare compatible with Octave 4.2Requires among other things dealing with the mex-files, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7570
Requires among other things dealing with the mex-files, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7570
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1112treatment of auxiliary variables2018-09-11T15:00:44ZHoutan Bastanitreatment of auxiliary variablesAuxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.
Auxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.
5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1081Add Chandrasekhar Recursion Kalman Filter2019-06-19T15:37:53ZJohannes Pfeifer Add Chandrasekhar Recursion Kalman FilterAs discussed during the 2015 Dynare conference, this might be a nice addition for larger models. See
Herbst (2015): "Using the “Chandrasekhar Recursions” for Likelihood Evaluation of DSGE Models", Comput Econ (2015) 45:693–705
As discussed during the 2015 Dynare conference, this might be a nice addition for larger models. See
Herbst (2015): "Using the “Chandrasekhar Recursions” for Likelihood Evaluation of DSGE Models", Comput Econ (2015) 45:693–705
5.0https://git.dynare.org/Dynare/dynare/issues/1078Make lyapunov_symm compatible with sparse matrices2018-11-08T10:30:59ZJohannes Pfeifer Make lyapunov_symm compatible with sparse matricesAs discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
As discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
5.0https://git.dynare.org/Dynare/dynare/issues/1077Integrate doubling algorithm into lyapunov_symm2019-06-19T15:37:53ZJohannes Pfeifer Integrate doubling algorithm into lyapunov_symmFollowing #988 and the discussions at the 2015 Dynare conference, we should integrate `disclyap_fast.m` into `lyapunov_symm` to have one solver only. The question is whether we want to integrate this as a call to `disclyap_fast.m`as an external function or whether to make `disclyap_fast.m` a nested function within `lyapunov_symm`. I would prefer the latter, because it makes the function with the doubling algorithm reusable as a standalone in the way Herbst (2015) and Schmitt-Grohé/Uribe already use it.
When doing this, we also need to discuss the option handling as we currently do not pass the doubling tolerance to `lyapunov_symm`. Currently, we pass `lyapunov_fixed_point_tol`. I would propose to use this input argument as the tolerance criterion if the doubling algorithm is selected.
Following #988 and the discussions at the 2015 Dynare conference, we should integrate `disclyap_fast.m` into `lyapunov_symm` to have one solver only. The question is whether we want to integrate this as a call to `disclyap_fast.m`as an external function or whether to make `disclyap_fast.m` a nested function within `lyapunov_symm`. I would prefer the latter, because it makes the function with the doubling algorithm reusable as a standalone in the way Herbst (2015) and Schmitt-Grohé/Uribe already use it.
When doing this, we also need to discuss the option handling as we currently do not pass the doubling tolerance to `lyapunov_symm`. Currently, we pass `lyapunov_fixed_point_tol`. I would propose to use this input argument as the tolerance criterion if the doubling algorithm is selected.
5.0https://git.dynare.org/Dynare/dynare/issues/1066Skip dynare initialization when run with noclearall when dynare has previousl...2019-06-19T15:37:54ZTom HoldenSkip dynare initialization when run with noclearall when dynare has previously runThe below is a feature request which seems particularly pertinent in light of https://github.com/DynareTeam/dynare/issues/1057 :
In code that calls dynare repeatedly with noclearall, the time spent in Dynare's initialization can be a non-trivial contribution.
Can we set a global flag when Dynare is initialized (e.g. paths set, mex files found, etc.), and skip as much as possible on subsequent runs?
The below is a feature request which seems particularly pertinent in light of https://github.com/DynareTeam/dynare/issues/1057 :
In code that calls dynare repeatedly with noclearall, the time spent in Dynare's initialization can be a non-trivial contribution.
Can we set a global flag when Dynare is initialized (e.g. paths set, mex files found, etc.), and skip as much as possible on subsequent runs?
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1063Make output of dsge_var_likelihood accessible2019-06-19T15:37:54ZJohannes Pfeifer Make output of dsge_var_likelihood accessibleSee the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
See the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
5.0https://git.dynare.org/Dynare/dynare/issues/1060Add capabilities for pseudo out of sample forecasting2018-09-11T15:00:44ZJohannes Pfeifer Add capabilities for pseudo out of sample forecastingAllow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
Allow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
5.0