dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:44Zhttps://git.dynare.org/Dynare/dynare/-/issues/1453Fix bug introduced in issue 13362019-06-19T15:37:44ZJohannes Pfeifer Fix bug introduced in issue 1336In 7829a252387d6da559b37b37797bf5fa4330f6ad related to https://github.com/DynareTeam/dynare/issues/1336 we set `order=1` locally in `stochastic_solvers`. While that speeds up the solution, the subsequent functions do not know that `order` was locally changed. That crashes e.g. `disp_dr` and `th_autocovariances`, because they are looking for `dr.ghs2` which would be there at `order=2`In 7829a252387d6da559b37b37797bf5fa4330f6ad related to https://github.com/DynareTeam/dynare/issues/1336 we set `order=1` locally in `stochastic_solvers`. While that speeds up the solution, the subsequent functions do not know that `order` was locally changed. That crashes e.g. `disp_dr` and `th_autocovariances`, because they are looking for `dr.ghs2` which would be there at `order=2`https://git.dynare.org/Dynare/dynare/-/issues/1452Update info for building from source2019-06-19T15:37:44ZJohannes Pfeifer Update info for building from sourceParticularly on Mac when not using homebrew (e.g. for own branches), some package versions may be too new. For example, Bison 3 does not work. Instead one needs 2.7 or so. According to @houtanb one can use
```
brew tap homebrew/versions
brew install homebrew/versions/bison27
brew link --force bison27
```
But the `readme.md` only states one needs `Bison, version 2.5 or later`, which is not correct. A similar issue may be true for `Flex`
Particularly on Mac when not using homebrew (e.g. for own branches), some package versions may be too new. For example, Bison 3 does not work. Instead one needs 2.7 or so. According to @houtanb one can use
```
brew tap homebrew/versions
brew install homebrew/versions/bison27
brew link --force bison27
```
But the `readme.md` only states one needs `Bison, version 2.5 or later`, which is not correct. A similar issue may be true for `Flex`
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1439Fix bytecode memory problem introduced in #14202019-06-19T15:37:44ZJohannes Pfeifer Fix bytecode memory problem introduced in #1420#1420 changed the memory allocation. Since then `ramst_normcdf_and_friends_static` fails with
```
Fatal error in bytecode: mxMalloc: out of memory 352 bytes required at line 1915 in function Init_GE (file ../../../sources/bytecode/SparseMatrix.cc
```#1420 changed the memory allocation. Since then `ramst_normcdf_and_friends_static` fails with
```
Fatal error in bytecode: mxMalloc: out of memory 352 bytes required at line 1915 in function Init_GE (file ../../../sources/bytecode/SparseMatrix.cc
```FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/-/issues/1437Speed of Kalman filter in unstable vs 4.4.32019-06-19T15:37:44ZJohannes Pfeifer Speed of Kalman filter in unstable vs 4.4.3Joris reports at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6373&start=15#p37426 that 4.4.3 runs Bayesian estimation a lot faster than the current master. Profiling `fs2000.mod`, the culprit seems to be https://github.com/DynareTeam/dynare/pull/1088/commits/05fc096569e15e89d8d13b08799321c0313b168d where we made the Kalman filter more robust against ill-conditioned matrices. This seems to have considerable computational costs, because the function is called so often. I wonder if switching to the univariate filter if problems appear is not the better default.
Joris reports at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6373&start=15#p37426 that 4.4.3 runs Bayesian estimation a lot faster than the current master. Profiling `fs2000.mod`, the culprit seems to be https://github.com/DynareTeam/dynare/pull/1088/commits/05fc096569e15e89d8d13b08799321c0313b168d where we made the Kalman filter more robust against ill-conditioned matrices. This seems to have considerable computational costs, because the function is called so often. I wonder if switching to the univariate filter if problems appear is not the better default.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1438Write a unit test for mjdgges (m implementation)2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euWrite a unit test for mjdgges (m implementation)Based on matrices E and D from the example contributed by @JohannesPfeifer in #1154.Based on matrices E and D from the example contributed by @JohannesPfeifer in #1154.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1434Check ksstat option of sensitivity2019-06-19T15:37:44ZJohannes Pfeifer Check ksstat option of sensitivityIt seems to be superseded by e.g. `pvalue_ks`. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=17952
While it appears in `stab_map_.m` is seems to not be used at all.It seems to be superseded by e.g. `pvalue_ks`. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=17952
While it appears in `stab_map_.m` is seems to not be used at all.https://git.dynare.org/Dynare/dynare/-/issues/1431Port write_equation_tags to write_latex_static_model and write_latex_original...2020-02-04T14:35:04ZJohannes Pfeifer Port write_equation_tags to write_latex_static_model and write_latex_original_modelSee https://github.com/DynareTeam/dynare/commit/14f4544a29eac182ff1f5840e5f9cc78b9efa7e0#commitcomment-21632978See https://github.com/DynareTeam/dynare/commit/14f4544a29eac182ff1f5840e5f9cc78b9efa7e0#commitcomment-216329784.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1425create interface for initial_condition_decomposition2019-06-19T15:37:44ZHoutan Bastanicreate interface for initial_condition_decompositionSee #1421See #14214.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1414command options should be made local, and a new syntax should provide persist...2020-05-07T17:45:59ZHoutan 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.)https://git.dynare.org/Dynare/dynare/-/issues/1415rewrite dyn_saveas, dyn_figure to take the options they need as arguments2019-06-19T15:37:44ZHoutan Bastanirewrite dyn_saveas, dyn_figure to take the options they need as argumentsThis is a first step in the long road to completing #1414This is a first step in the long road to completing #14144.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1409Add an interface for setting initial condition of the Kalman filter2019-06-19T15:37:44ZStéphane Adjemianstepan@adjemian.euAdd an interface for setting initial condition of the Kalman filterSee discussion in #1395.See discussion in #1395.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1410Make master mex-files compatible with Matlab R2017a and adjust installer for ...2019-06-19T15:37:44ZJohannes Pfeifer Make master mex-files compatible with Matlab R2017a and adjust installer for WindowsFollowing the discussion in #1225, Matlab R2017a seems to require a change in mex-file compilation.
This also implies that the commit https://github.com/DynareTeam/dynare/commit/4f3b35acbaaa23ad81d5200f68eacbbd9c9b98b6 is not correct, because we need a different set of 64bit mex-files going forward, starting with version `9.2`.Following the discussion in #1225, Matlab R2017a seems to require a change in mex-file compilation.
This also implies that the commit https://github.com/DynareTeam/dynare/commit/4f3b35acbaaa23ad81d5200f68eacbbd9c9b98b6 is not correct, because we need a different set of 64bit mex-files going forward, starting with version `9.2`.https://git.dynare.org/Dynare/dynare/-/issues/1407Keep track of whether smoother results are in logs and adjust smoother2histva...2019-11-26T15:21:02ZJohannes Pfeifer Keep track of whether smoother results are in logs and adjust smoother2histval accordinglySee !1396 See !1396 https://git.dynare.org/Dynare/dynare/-/issues/1406Add interface for #13722019-06-19T15:37:44ZStéphane Adjemianstepan@adjemian.euAdd interface for #1372@houtanb To identify the needed modifications look at #1372 and the new entries in the reference manual.@houtanb To identify the needed modifications look at #1372 and the new entries in the reference manual.4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1404Fix bug in sim1_linear2019-09-10T09:41:11ZJohannes Pfeifer Fix bug in sim1_linear`sim1_linear.m` seems to return wrong results. The following mod-file calls different solvers in sequence, using the previous result as the respective starting value.
```
//Endogenous variables
var piV rV yV rrstarV zV Rshock;
//Exogenous variables
varexo epsFG shock epsR;
//Parameters
parameters alpha beta eta phipi phiy rho sig lambda; //
//Initialization of parameter values
beta =0.99; //Discount factor (=inverse nominal interest rate)
alpha =0.033; //sensivity of inflation to output gap, parameter determining marginal cost,
eta =1; //sensivity of inflation to output gap, parameter determining price rigidity
phipi =1.5; //parameter determining monetary reaction to inflation
phiy =0.125; //parameter determining monetary reaction to output
rho =0.9; //AR(1) natural rate
sig =1; //intertemporal rate of substitution
lambda=0.25; // prob. of new info arrival
//model equations
model;
// z Variable
zV = alpha*(yV-yV(-1))+piV;//(pV-pV(-1));
piV= (lambda*alpha/ (1-lambda)) *yV
+lambda*EXPECTATION(-1)(zV)
+lambda*(1-lambda)*EXPECTATION(-2)(zV)
+lambda*(1-lambda)^2*EXPECTATION(-3)(zV)
+lambda*(1-lambda)^3*EXPECTATION(-4)(zV)
+lambda*(1-lambda)^4*EXPECTATION(-5)(zV)
+lambda*(1-lambda)^5*EXPECTATION(-6)(zV)
+lambda*(1-lambda)^6*EXPECTATION(-7)(zV)
+lambda*(1-lambda)^7*EXPECTATION(-8)(zV)
+lambda*(1-lambda)^8*EXPECTATION(-9)(zV)
; //marginal cost is proportional to gap, gap is driver of inflation
//piV=0.99*piV(+1)+0.033*yV;
//IS curve (Output Euler) from Kiley code
yV = yV(+1)-sig*(rV-piV(+1) - rrstarV);
//monetary policy' reaction function
rV = min((1-shock), phipi*(piV(+1) + phiy*yV + epsFG));
//rV = phipi*piV + phiy*yV+Rshock;
Rshock=0.5*Rshock(-1)+epsR;
//Natural real interest rate
rrstarV = rho*rrstarV(-1);
end;
initval;
rV=0;
yV=0;
rrstarV=0;
piV=0;
zV=0;
end;
steady;
check;
shocks;
var shock;
periods 1:15;
values 1;
var epsFG;
periods 16 ;
values -0.0117;
end;
perfect_foresight_setup(periods=30);
perfect_foresight_solver(solve_algo=0);
nonlinear=oo_.endo_simul;
options_.linear=1;
perfect_foresight_solver(solve_algo=0);
linear=oo_.endo_simul;
perfect_foresight_solver(solve_algo=0);
options_.linear=0;
perfect_foresight_solver(solve_algo=0);
perfect_foresight_solver(solve_algo=4);
```
But the result of the nonlinear solvers has non-zero residuals in the linear solver and vice versa, while the nonlinear solvers seem to have consistent results.
`sim1_linear.m` seems to return wrong results. The following mod-file calls different solvers in sequence, using the previous result as the respective starting value.
```
//Endogenous variables
var piV rV yV rrstarV zV Rshock;
//Exogenous variables
varexo epsFG shock epsR;
//Parameters
parameters alpha beta eta phipi phiy rho sig lambda; //
//Initialization of parameter values
beta =0.99; //Discount factor (=inverse nominal interest rate)
alpha =0.033; //sensivity of inflation to output gap, parameter determining marginal cost,
eta =1; //sensivity of inflation to output gap, parameter determining price rigidity
phipi =1.5; //parameter determining monetary reaction to inflation
phiy =0.125; //parameter determining monetary reaction to output
rho =0.9; //AR(1) natural rate
sig =1; //intertemporal rate of substitution
lambda=0.25; // prob. of new info arrival
//model equations
model;
// z Variable
zV = alpha*(yV-yV(-1))+piV;//(pV-pV(-1));
piV= (lambda*alpha/ (1-lambda)) *yV
+lambda*EXPECTATION(-1)(zV)
+lambda*(1-lambda)*EXPECTATION(-2)(zV)
+lambda*(1-lambda)^2*EXPECTATION(-3)(zV)
+lambda*(1-lambda)^3*EXPECTATION(-4)(zV)
+lambda*(1-lambda)^4*EXPECTATION(-5)(zV)
+lambda*(1-lambda)^5*EXPECTATION(-6)(zV)
+lambda*(1-lambda)^6*EXPECTATION(-7)(zV)
+lambda*(1-lambda)^7*EXPECTATION(-8)(zV)
+lambda*(1-lambda)^8*EXPECTATION(-9)(zV)
; //marginal cost is proportional to gap, gap is driver of inflation
//piV=0.99*piV(+1)+0.033*yV;
//IS curve (Output Euler) from Kiley code
yV = yV(+1)-sig*(rV-piV(+1) - rrstarV);
//monetary policy' reaction function
rV = min((1-shock), phipi*(piV(+1) + phiy*yV + epsFG));
//rV = phipi*piV + phiy*yV+Rshock;
Rshock=0.5*Rshock(-1)+epsR;
//Natural real interest rate
rrstarV = rho*rrstarV(-1);
end;
initval;
rV=0;
yV=0;
rrstarV=0;
piV=0;
zV=0;
end;
steady;
check;
shocks;
var shock;
periods 1:15;
values 1;
var epsFG;
periods 16 ;
values -0.0117;
end;
perfect_foresight_setup(periods=30);
perfect_foresight_solver(solve_algo=0);
nonlinear=oo_.endo_simul;
options_.linear=1;
perfect_foresight_solver(solve_algo=0);
linear=oo_.endo_simul;
perfect_foresight_solver(solve_algo=0);
options_.linear=0;
perfect_foresight_solver(solve_algo=0);
perfect_foresight_solver(solve_algo=4);
```
But the result of the nonlinear solvers has non-zero residuals in the linear solver and vice versa, while the nonlinear solvers seem to have consistent results.
4.6https://git.dynare.org/Dynare/dynare/-/issues/1403Decide on changing prior in fs2000.mod2019-06-19T15:37:44ZJohannes Pfeifer Decide on changing prior in fs2000.modhttps://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://git.dynare.org/Dynare/dynare/-/issues/1401Dynare should give warnings when priors are unbounded2019-02-08T08:31:18ZTom HoldenDynare should give warnings when priors are unboundedIt is generally a bad idea to have a prior with unbounded density, as even with reasonably tight identification, such a prior can easily swamp the likelihood. This is particularly problematic when the prior is unbounded at the edges of its support, as then the mode will be driven to the edge, causing further problems with Hessian computation.
At present in Dynare, it is a bit too easy to inadvertently specify such a prior, given the mean and std. dev. specification of the beta distribution. I would suggest that Dynare should give a warning when such are encountered.
For the beta distribution, the prior has bounded support providing alpha>=1 and beta>=1. This means that the variance of the prior must be less or equal to `min(m*(1-m)^2/(1+1-m), (1-m)*m^2/(1+m))`, where `m` is the mean of the distribution.It is generally a bad idea to have a prior with unbounded density, as even with reasonably tight identification, such a prior can easily swamp the likelihood. This is particularly problematic when the prior is unbounded at the edges of its support, as then the mode will be driven to the edge, causing further problems with Hessian computation.
At present in Dynare, it is a bit too easy to inadvertently specify such a prior, given the mean and std. dev. specification of the beta distribution. I would suggest that Dynare should give a warning when such are encountered.
For the beta distribution, the prior has bounded support providing alpha>=1 and beta>=1. This means that the variance of the prior must be less or equal to `min(m*(1-m)^2/(1+1-m), (1-m)*m^2/(1+m))`, where `m` is the mean of the distribution.https://git.dynare.org/Dynare/dynare/-/issues/1398replace equation cross references with those done for json2019-06-19T15:37:44ZHoutan Bastanireplace equation cross references with those done for jsonReplace original version done in 4976b2b3359688e9b1d000bdf05f95d5b6071ac3, f546368252 with those done in 0ccc82300c3046d159554c24027ded09a93b687e
The changes in 0ccc82300c3046d159554c24027ded09a93b687e contain information on lags whereas the original ones don'tReplace original version done in 4976b2b3359688e9b1d000bdf05f95d5b6071ac3, f546368252 with those done in 0ccc82300c3046d159554c24027ded09a93b687e
The changes in 0ccc82300c3046d159554c24027ded09a93b687e contain information on lags whereas the original ones don't4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1400Investigate dseries problems in parallel execution2018-11-08T10:15:22ZJohannes Pfeifer Investigate dseries problems in parallel executionWhen executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
When executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1397preprocessor: static params derivatives don't use temporary terms2019-06-19T15:37:44ZHoutan Bastanipreprocessor: static params derivatives don't use temporary termssee `kim2_static_params_derivs.m` produced by `identification/kim/kim2.mod`see `kim2_static_params_derivs.m` produced by `identification/kim/kim2.mod`Houtan BastaniHoutan Bastani