dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:47Zhttps://git.dynare.org/Dynare/dynare/-/issues/1302calib_smoother doesn't recognize diffuse_filter2019-06-19T15:37:47ZMichelJuillardcalib_smoother doesn't recognize diffuse_filterIt should be possible to run the smoother with calibrated parameters for a model with non-stationary variables
It should be possible to run the smoother with calibrated parameters for a model with non-stationary variables
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1300When using gnuplot on octave, most graphs titles are cut2019-06-19T15:37:47ZStéphane Adjemianstepan@adjemian.euWhen using gnuplot on octave, most graphs titles are cut*Created by: felipeboralli*
When using gnuplot on octave, most graphs titles are cut a bit.
It seems the titles are shifted upwards, because when there is a second row of graphs in the window, their titles seem to invade the upper row.
![2](https://cloud.githubusercontent.com/assets/22381123/19123477/32dd3916-8b05-11e6-8af1-172438cf9051.png)
![3](https://cloud.githubusercontent.com/assets/22381123/19123478/32de3348-8b05-11e6-958c-8d22213691d4.png)
![4](https://cloud.githubusercontent.com/assets/22381123/19123479/32e291ea-8b05-11e6-8edf-01b68f995c46.png)
*Created by: felipeboralli*
When using gnuplot on octave, most graphs titles are cut a bit.
It seems the titles are shifted upwards, because when there is a second row of graphs in the window, their titles seem to invade the upper row.
![2](https://cloud.githubusercontent.com/assets/22381123/19123477/32dd3916-8b05-11e6-8af1-172438cf9051.png)
![3](https://cloud.githubusercontent.com/assets/22381123/19123478/32de3348-8b05-11e6-958c-8d22213691d4.png)
![4](https://cloud.githubusercontent.com/assets/22381123/19123479/32e291ea-8b05-11e6-8edf-01b68f995c46.png)
https://git.dynare.org/Dynare/dynare/-/issues/1299The plot of recursive forecasts is wrong when prefilter=12019-06-19T15:37:47ZStéphane Adjemianstepan@adjemian.euThe plot of recursive forecasts is wrong when prefilter=1*Created by: felipeboralli*
GNU Octave, version 3.8.1 "i686-w64-mingw32".
Dynare unstable (version 2016-08-23).
When the variables are prefiltered, the plot of recursive forecast is made mixing a filtered realized variable with a defiltered forecasted variable.
In the window below, this is very visible in the juros variable, but happens in all of them.
What I woud expect is all of them to be in the defiltered mode.
![1](https://cloud.githubusercontent.com/assets/22381123/19122621/aface774-8b01-11e6-9a6e-5bc81023bd68.png)
*Created by: felipeboralli*
GNU Octave, version 3.8.1 "i686-w64-mingw32".
Dynare unstable (version 2016-08-23).
When the variables are prefiltered, the plot of recursive forecast is made mixing a filtered realized variable with a defiltered forecasted variable.
In the window below, this is very visible in the juros variable, but happens in all of them.
What I woud expect is all of them to be in the defiltered mode.
![1](https://cloud.githubusercontent.com/assets/22381123/19122621/aface774-8b01-11e6-9a6e-5bc81023bd68.png)
https://git.dynare.org/Dynare/dynare/-/issues/1296Decide on whether to save intermediate draws2019-06-19T15:37:47ZJohannes Pfeifer Decide on whether to save intermediate drawsWith the move to `posterior_sampling_core` we now by default save the MCMC draws every 50 draws into a temporary file, because we by default set
`posterior_sampler_options.save_tmp_file=1;`
I think this is very inefficient and therefore should be 0 by default (same behavior as before the move), with an interface provided to change the option.
@rattoma You added this behavior. Was the reason that `slice` should be treated differently?
With the move to `posterior_sampling_core` we now by default save the MCMC draws every 50 draws into a temporary file, because we by default set
`posterior_sampler_options.save_tmp_file=1;`
I think this is very inefficient and therefore should be 0 by default (same behavior as before the move), with an interface provided to change the option.
@rattoma You added this behavior. Was the reason that `slice` should be treated differently?
https://git.dynare.org/Dynare/dynare/-/issues/1293xlswrite and xlsopen on Octave no longer work on .xls files, only .xlsx files2019-06-19T15:37:47ZHoutan Bastanixlswrite and xlsopen on Octave no longer work on .xls files, only .xlsx filesSee: http://savannah.gnu.org/bugs/?44109
This causes `tests/data/mod1a.mod` to crash in the test suite on Octave
See: http://savannah.gnu.org/bugs/?44109
This causes `tests/data/mod1a.mod` to crash in the test suite on Octave
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1294Introduce proper check for stochastic singularity2019-06-19T15:37:47ZJohannes Pfeifer Introduce proper check for stochastic singularityIn `initial_estimation_checks` we should introduce a proper check for stochastic singularity by setting `options_.use_univariate_filters_if_singularity_is_detected=0` and then providing an informative error message when `info(1) == 50`.
This prevents user errors where the model has a fundamental stochastic singularity, because Dynare by default will resort to the univariate filter without warning.
In `initial_estimation_checks` we should introduce a proper check for stochastic singularity by setting `options_.use_univariate_filters_if_singularity_is_detected=0` and then providing an informative error message when `info(1) == 50`.
This prevents user errors where the model has a fundamental stochastic singularity, because Dynare by default will resort to the univariate filter without warning.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1290Provide local nograph option to shock_decomposition2019-06-19T15:37:47ZJohannes Pfeifer Provide local nograph option to shock_decompositionIt should translate `shock_decomposition(nograph)` to the last input of
`shock_decomposition(M_,oo_,options_,varlist,nograph)`
with the default being 0. Alternatively, only if the `nograph` option is specified, we call `shock_decomposition` with a fifth input. Related to #1280
It should translate `shock_decomposition(nograph)` to the last input of
`shock_decomposition(M_,oo_,options_,varlist,nograph)`
with the default being 0. Alternatively, only if the `nograph` option is specified, we call `shock_decomposition` with a fifth input. Related to #1280
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1288bug with use_dll, k_order_perturbation2019-06-19T15:37:47ZHoutan Bastanibug with use_dll, k_order_perturbationThe following tests fail:
```
| * k_order_perturbation/fs2000k2_use_dll.mod
| * k_order_perturbation/fs2000k_1_use_dll.mod
| * k_order_perturbation/fs2000k3_use_dll.mod
```
with the error:`dynare:k_order_perturbation: Caught KordDynare exception: ../../../sources/k_order_perturbation/dynamic_dll.cc:70: Error when loading ./fs2000k2_use_dll_dynamic.mexa64 (can't locate the 'Dynamic' symbol)`
We first found this on Matlab R2016a, though it may have existed earlier. This bug exists on OS X, Linux and Windows with MinGW (thanks @JohannesPfeifer ). This does not exist on Windows with MSVC.
Can possibly fix with `extern "C"` or by creating C++ mex files. Should see in which version of Matlab this problem started and why.
The following tests fail:
```
| * k_order_perturbation/fs2000k2_use_dll.mod
| * k_order_perturbation/fs2000k_1_use_dll.mod
| * k_order_perturbation/fs2000k3_use_dll.mod
```
with the error:`dynare:k_order_perturbation: Caught KordDynare exception: ../../../sources/k_order_perturbation/dynamic_dll.cc:70: Error when loading ./fs2000k2_use_dll_dynamic.mexa64 (can't locate the 'Dynamic' symbol)`
We first found this on Matlab R2016a, though it may have existed earlier. This bug exists on OS X, Linux and Windows with MinGW (thanks @JohannesPfeifer ). This does not exist on Windows with MSVC.
Can possibly fix with `extern "C"` or by creating C++ mex files. Should see in which version of Matlab this problem started and why.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1287mex files not found by dynare_config2019-06-19T15:37:47ZHoutan Bastanimex files not found by dynare_configIn Matlab R2016b, `dynare_config` returns:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[no] k-order perturbation solver.
[mex] k-order solution simulation.
[no] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Then, if you type `which k_order_perturbation; dynare_config` you get:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[mex] k-order perturbation solver.
[mex] k-order solution simulation.
[mex] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Thanks to @JohannesPfeifer for pointing this out.
This problem exists on OS X, Windows, and Linux. Need to see with which version of Matlab this started
In Matlab R2016b, `dynare_config` returns:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[no] k-order perturbation solver.
[mex] k-order solution simulation.
[no] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Then, if you type `which k_order_perturbation; dynare_config` you get:
```
Configuring Dynare ...
[mex] Generalized QZ.
[mex] Sylvester equation solution.
[mex] Kronecker products.
[mex] Sparse kronecker products.
[mex] Local state space iteration (second order).
[mex] Bytecode evaluation.
[mex] k-order perturbation solver.
[mex] k-order solution simulation.
[mex] Quasi Monte-Carlo sequence (Sobol).
[mex] Markov Switching SBVAR.
```
Thanks to @JohannesPfeifer for pointing this out.
This problem exists on OS X, Windows, and Linux. Need to see with which version of Matlab this started
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1286issue undeclared model variable errors at the end of model parsing2019-06-19T15:37:47ZHoutan Bastaniissue undeclared model variable errors at the end of model parsingCurrently, when a variable is in an equation but not declared, the preprocessor issues an error and stops parsing. This is a problem during model development as a user can potentially need to run dynare several times before catching all undeclared variables. To fix this, `preprocessor/ParsingDriver.cc` needs to be modified to check the existence of variables at the end of the `model` block.
Currently, when a variable is in an equation but not declared, the preprocessor issues an error and stops parsing. This is a problem during model development as a user can potentially need to run dynare several times before catching all undeclared variables. To fix this, `preprocessor/ParsingDriver.cc` needs to be modified to check the existence of variables at the end of the `model` block.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1285bytecode crash in Octave2019-06-19T15:37:47ZHoutan Bastanibytecode crash in Octave`tests/conditional_forecasts/5/fs2000_cal.mod` causes Octave 4.0.3 to crash. Seems like a memory management problem as the error message is:
```
computing the first order solution of the model as initial guess...*** Error in '/usr/bin/octave-cli': double free or corruption (out): 0x00000000020b3630 ***
panic: Aborted -- stopping myself...
```
This may also be linked to the testsuite error in Matlab.
`tests/conditional_forecasts/5/fs2000_cal.mod` causes Octave 4.0.3 to crash. Seems like a memory management problem as the error message is:
```
computing the first order solution of the model as initial guess...*** Error in '/usr/bin/octave-cli': double free or corruption (out): 0x00000000020b3630 ***
panic: Aborted -- stopping myself...
```
This may also be linked to the testsuite error in Matlab.
4.5FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/-/issues/1278Clarify and debug macro processor arithmetic in define statements.2019-06-19T15:37:47ZJohannes Pfeifer Clarify and debug macro processor arithmetic in define statements.Using
```
@# define a=2
@# define b=3
@# define p= a/b
disp(@{p})
```
with `savemacro=temp onlymacro` results in
```
@#line "junk2.mod" 1
disp(0)
```
which is not the expected outcome.
```
@# define a=1
@# define b=2/3
@# define p= a/b
disp(@{p})
```
crashes the preprocessor on Windows
Using
```
@# define a=2
@# define b=3
@# define p= a/b
disp(@{p})
```
with `savemacro=temp onlymacro` results in
```
@#line "junk2.mod" 1
disp(0)
```
which is not the expected outcome.
```
@# define a=1
@# define b=2/3
@# define p= a/b
disp(@{p})
```
crashes the preprocessor on Windows
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1280grouping shocks in decompositions2019-06-19T15:37:47ZMarco Rattogrouping shocks in decompositionswould it be possible to allow a more flexible naming of the groups, allowing a sort of verbatim reading of what is before `=` .
the following syntax does not work
```
shock_groups;
...
Price Mark-up EA = emup;
Wage Mark-up EA = emuw;
...
end;
```
not sure if this can be modified, by allowing group names to be given inside brackets, as follows:
```
shock_groups;
...
(Price Mark-up EA) = emup;
(Wage Mark-up EA) = emuw;
...
end;
```
?
would it be possible to allow a more flexible naming of the groups, allowing a sort of verbatim reading of what is before `=` .
the following syntax does not work
```
shock_groups;
...
Price Mark-up EA = emup;
Wage Mark-up EA = emuw;
...
end;
```
not sure if this can be modified, by allowing group names to be given inside brackets, as follows:
```
shock_groups;
...
(Price Mark-up EA) = emup;
(Wage Mark-up EA) = emuw;
...
end;
```
?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1276bug in conditional forecast2019-06-19T15:37:47ZMarco Rattobug in conditional forecastThe conditional forecast is buggy.
Namely there is some inconsistency in indexing between decision rule and declaration order.
The way to fix it is to make sure that the pre-processor sets the vector of indices:
`constrained_vars_`
in decision rule order.
In fact, `imcforecast` assumes that `constrained_vars_` is in decision rule order
Moreover, one needs to fix `imcforecast` for the trend, since the latter is already defined in decision-rule ordering (so no need to use `inv_order_var`). I am going to make a pull request with the `imcforecast` fix, but I do not touch the pre-processor. If someone (@houtan?) could help with the latter.
Many thanks
The conditional forecast is buggy.
Namely there is some inconsistency in indexing between decision rule and declaration order.
The way to fix it is to make sure that the pre-processor sets the vector of indices:
`constrained_vars_`
in decision rule order.
In fact, `imcforecast` assumes that `constrained_vars_` is in decision rule order
Moreover, one needs to fix `imcforecast` for the trend, since the latter is already defined in decision-rule ordering (so no need to use `inv_order_var`). I am going to make a pull request with the `imcforecast` fix, but I do not touch the pre-processor. If someone (@houtan?) could help with the latter.
Many thanks
4.5Houtan BastaniMarco RattoHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1272Account for MAC in AnalyseComputationalEnvironment.m and GiveCPUnumber.m2019-06-19T15:37:49ZJohannes Pfeifer Account for MAC in AnalyseComputationalEnvironment.m and GiveCPUnumber.mThe call to
`[si0 de0]=system('grep processor /proc/cpuinfo');`
should be
`[si0 de0]=system('sysctl -a | grep machdep.cpu | grep core_count');` (see http://fortysomethinggeek.blogspot.de/2012/11/getting-cpu-info-from-command-line-in.html)
`GiveCPUnumber.m` then also needs to be adjusted to account for this.
Related to #838
The call to
`[si0 de0]=system('grep processor /proc/cpuinfo');`
should be
`[si0 de0]=system('sysctl -a | grep machdep.cpu | grep core_count');` (see http://fortysomethinggeek.blogspot.de/2012/11/getting-cpu-info-from-command-line-in.html)
`GiveCPUnumber.m` then also needs to be adjusted to account for this.
Related to #838
4.5https://git.dynare.org/Dynare/dynare/-/issues/1266bug with eig in Matlab R2012a2019-06-19T15:37:49ZHoutan Bastanibug with eig in Matlab R2012aOn line 197 of `matlab/identification_analysis.m`, we have `[V,D,W]=eig(cc);`. In older versions of Matlab, eig only has two output arguments and hence this causes an error. To calculate `W`, the left eigenvectors of cc, the documentation recommends `[W,junk] = eig(cc.'); W = conj(W)` separately.
On line 197 of `matlab/identification_analysis.m`, we have `[V,D,W]=eig(cc);`. In older versions of Matlab, eig only has two output arguments and hence this causes an error. To calculate `W`, the left eigenvectors of cc, the documentation recommends `[W,junk] = eig(cc.'); W = conj(W)` separately.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1264Block exogenous variables from being used in planner_objective2019-06-19T15:37:49ZJohannes Pfeifer Block exogenous variables from being used in planner_objectiveCurrently, exogenous variables in the `planner_objective` are simply ignored in the preprocessor. When using
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3; //Frisch elasticity
omega=17; //price stickyness
epsilon=8; //elasticity for each variety of consumption
phi=1; //coefficient associated to labor effort disutility
rho=0.95; //coefficient associated to productivity shock
model;
a=rho*(a(-1))+u;
1/c=beta*(1/(c(+1)))*(r/(pai(+1))); //euler
omega*pai*(pai-1)=beta*omega*(c/(c(+1)))*(pai(+1))*(pai(+1)-1)+epsilon*exp(a)*n*(c/exp(a)*phi*n^gamma-(epsilon-1)/epsilon); //NK pc
//pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega-exp(a)*n*(epsilon-1)/(omega*c); //NK pc
(exp(a))*n=c+(omega/2)*((pai-1)^2);
end;
initval;
pai=1;
r=1/beta;
c=0.9671684882;
n=0.9671684882;
a=0;
u=0;
end;
histval;
a(0)=0.9;
end;
shocks;
var u; stderr 0.008;
end;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma))*exp(u));
ramsey_policy(order=1,planner_discount=0.99);
```
the `exp(u)` does not appear in `_model_objective_static`. This is problematic, because in principle shocks at time t are part of the information set and should enter the objective. For that reason, @MichelJuillard agreed that we should block using exogenous variables in the objective and instead provide an error message like
`You cannot handle exogenous variables in the planner objective. Please define an auxiliary endogenous variable like eps_aux=epsilon and use it instead of the varexo`
Currently, exogenous variables in the `planner_objective` are simply ignored in the preprocessor. When using
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3; //Frisch elasticity
omega=17; //price stickyness
epsilon=8; //elasticity for each variety of consumption
phi=1; //coefficient associated to labor effort disutility
rho=0.95; //coefficient associated to productivity shock
model;
a=rho*(a(-1))+u;
1/c=beta*(1/(c(+1)))*(r/(pai(+1))); //euler
omega*pai*(pai-1)=beta*omega*(c/(c(+1)))*(pai(+1))*(pai(+1)-1)+epsilon*exp(a)*n*(c/exp(a)*phi*n^gamma-(epsilon-1)/epsilon); //NK pc
//pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega-exp(a)*n*(epsilon-1)/(omega*c); //NK pc
(exp(a))*n=c+(omega/2)*((pai-1)^2);
end;
initval;
pai=1;
r=1/beta;
c=0.9671684882;
n=0.9671684882;
a=0;
u=0;
end;
histval;
a(0)=0.9;
end;
shocks;
var u; stderr 0.008;
end;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma))*exp(u));
ramsey_policy(order=1,planner_discount=0.99);
```
the `exp(u)` does not appear in `_model_objective_static`. This is problematic, because in principle shocks at time t are part of the information set and should enter the objective. For that reason, @MichelJuillard agreed that we should block using exogenous variables in the objective and instead provide an error message like
`You cannot handle exogenous variables in the planner objective. Please define an auxiliary endogenous variable like eps_aux=epsilon and use it instead of the varexo`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1263Adjust apt-get build-dep2019-06-19T15:37:49ZJohannes Pfeifer Adjust apt-get build-depCurrently, the `texlive-fonts-extra` package containing `ccicons` for building the documentation is missing. The `README.md` must also be adjusted accordingly.
Currently, the `texlive-fonts-extra` package containing `ccicons` for building the documentation is missing. The `README.md` must also be adjusted accordingly.
https://git.dynare.org/Dynare/dynare/-/issues/1219Tabular output of variance decomposition after Bayesian MH estimation2019-06-19T15:37:49ZStéphane Adjemianstepan@adjemian.euTabular output of variance decomposition after Bayesian MH estimation*Created by: BenjaminBorn*
Dear all,
Johannes asked me to open this as an issue. Would it be possible to provide the output from the conditional variance decomposition after Bayesian estimation in tabular form?
Thanks,
Benjamin
*Created by: BenjaminBorn*
Dear all,
Johannes asked me to open this as an issue. Would it be possible to provide the output from the conditional variance decomposition after Bayesian estimation in tabular form?
Thanks,
Benjamin
4.5https://git.dynare.org/Dynare/dynare/-/issues/1259normcdf is not supported using MSVC for use_dll2019-06-19T15:37:49ZTom Holdennormcdf is not supported using MSVC for use_dllnormcdf has a one line implementation using standard library functions (included in MSVC), namely:
```
double normcdf(double value)
{
return 0.5 * erfc(-value * M_SQRT1_2);
}
```
It seems a little unnecessary for this not to be supported with MSVC.
normcdf has a one line implementation using standard library functions (included in MSVC), namely:
```
double normcdf(double value)
{
return 0.5 * erfc(-value * M_SQRT1_2);
}
```
It seems a little unnecessary for this not to be supported with MSVC.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1260cygwin command line option should be renamed to gcc2019-06-19T15:37:49ZTom Holdencygwin command line option should be renamed to gccMATLAB on Windows now supports the MinGW toolchain, and indeed adding it is just a few clicks via the "Add-Ins" button.
The MinGW toolchain seems to work fine with the cygwin command line option, as one would expect.
Renaming the command line option to GCC and documenting that it can use either Cygwin or MinGW installed via "Add-Ins" would seem to be sensible.
MATLAB on Windows now supports the MinGW toolchain, and indeed adding it is just a few clicks via the "Add-Ins" button.
The MinGW toolchain seems to work fine with the cygwin command line option, as one would expect.
Renaming the command line option to GCC and documenting that it can use either Cygwin or MinGW installed via "Add-Ins" would seem to be sensible.
https://git.dynare.org/Dynare/dynare/-/issues/1249Add preprocessor interface for setting perfect foresight tolerance2019-06-19T15:37:49ZJohannes Pfeifer Add preprocessor interface for setting perfect foresight toleranceCurrently, one must manually set `options_.dynatol.f`. I would suggest to use the name `TolFun` for the option.
While we are at it, I would also suggest to use an option `TolFun` for the `steady` command to set `options_.solve_tolf`
Currently, one must manually set `options_.dynatol.f`. I would suggest to use the name `TolFun` for the option.
While we are at it, I would also suggest to use an option `TolFun` for the `steady` command to set `options_.solve_tolf`
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1244Clarify Dynare++ timing convention2019-06-19T15:37:49ZJohannes Pfeifer Clarify Dynare++ timing conventionSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8393
Using time to build is confusing and should be clearly documented
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8393
Using time to build is confusing and should be clearly documented
https://git.dynare.org/Dynare/dynare/-/issues/1240user_has_matlab_license2019-06-19T15:37:49ZMarco Rattouser_has_matlab_licenseDynare checks license but for onsite licenses, toolboxes could be licensed but not installed on the current machine. This would be visible with `ver`, even if I am not sure of the overall behavior of ver ...
Dynare checks license but for onsite licenses, toolboxes could be licensed but not installed on the current machine. This would be visible with `ver`, even if I am not sure of the overall behavior of ver ...
https://git.dynare.org/Dynare/dynare/-/issues/1237Investigate identification problem2019-06-19T15:37:49ZJohannes Pfeifer Investigate identification problemhttp://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8234
Sent email with mod-file to @rattoma on June 1, 2016
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8234
Sent email with mod-file to @rattoma on June 1, 2016
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1234Check whether fast_kalman_filter is compatible with non-stationary states2019-06-19T15:37:49ZJohannes Pfeifer Check whether fast_kalman_filter is compatible with non-stationary statesFrom the Herbst (2015)-paper:
`This seems like a difficult problem, because the factorization is not obvious, and, in our
experience, even finding α consistently can be hard. Fortunately, the problem becomes
much easier once it is known that the states are stationary.`
In a nonstationary model I get a complex likelihood.
From the Herbst (2015)-paper:
`This seems like a difficult problem, because the factorization is not obvious, and, in our
experience, even finding α consistently can be hard. Fortunately, the problem becomes
much easier once it is known that the states are stationary.`
In a nonstationary model I get a complex likelihood.
https://git.dynare.org/Dynare/dynare/-/issues/1232Remove onlyclearglobals option2019-06-19T15:37:49ZJohannes Pfeifer Remove onlyclearglobals optionIt was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
It was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1231Fix remaining Kalman-filter problems after #7382019-06-19T15:37:49ZJohannes Pfeifer Fix remaining Kalman-filter problems after #738In particular, the univariate filter may return wrong results with measurement error
TBD from #738
- Fix all bugs that result in unit tests crashing
- Improve unit tests to compare likelihood results for consistency
- Update and enable other unit tests for Kalman filter in kalman/likelihood directory
Please assign the ticket to me. Milestone should be 4.5
In particular, the univariate filter may return wrong results with measurement error
TBD from #738
- Fix all bugs that result in unit tests crashing
- Improve unit tests to compare likelihood results for consistency
- Update and enable other unit tests for Kalman filter in kalman/likelihood directory
Please assign the ticket to me. Milestone should be 4.5
https://git.dynare.org/Dynare/dynare/-/issues/1229external functions and third order perturbation2019-06-19T15:37:49ZStéphane Adjemianstepan@adjemian.euexternal functions and third order perturbationIt appears that we did not implement the possibility to use external functions when solving DSGE models at third order. I thought that when the derivates are not provided by the user, Dynare computed the derivates numerically. It seems that this mechanism is not triggered at third order. Is this intentional?
It appears that we did not implement the possibility to use external functions when solving DSGE models at third order. I thought that when the derivates are not provided by the user, Dynare computed the derivates numerically. It seems that this mechanism is not triggered at third order. Is this intentional?
https://git.dynare.org/Dynare/dynare/-/issues/1227Solve use_dll-incompatibility problem on Windows in master2019-06-19T15:37:49ZJohannes Pfeifer Solve use_dll-incompatibility problem on Windows in masterAfter merging the `temporary_terms`-branch (https://github.com/DynareTeam/dynare/commit/127637ffd672fdd8143ee13f2a38234e597d94d3) the `c`-files created are not `C89`-compatible, but require `C99`. This is a problem for Windows machines as Visual Studio before version 2015 only supported `C89`, resulting in errors of the form
`error C2143: syntax error : missing ';' before 'type'`
Before Matlab version `R2014b` users could use the `cygwin`-option by using the provided `mexopts-win64.bat` from http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation, which should not have this restriction. Since `R2015b`, `mingw` is available, which also supports `C99` (#1226). Moreover, Visual Studio 2015 finally supports `C99` and has a free available version that is supported since `R2015b`. That leaves 64bit Matlab-versions between `R2014a` and `R2015a` unable to deal with the problem unless someone figures out how to solve #641 for `cygwin` (potentially following the advice on how to set up the `xml`-file at http://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler). Given that there seems to be not that much demand for `use_dll` on Windows, I would propose for 4.5 to focus on the `mingw`-support and state the above restrictions clearly in the release notes and the manual
After merging the `temporary_terms`-branch (https://github.com/DynareTeam/dynare/commit/127637ffd672fdd8143ee13f2a38234e597d94d3) the `c`-files created are not `C89`-compatible, but require `C99`. This is a problem for Windows machines as Visual Studio before version 2015 only supported `C89`, resulting in errors of the form
`error C2143: syntax error : missing ';' before 'type'`
Before Matlab version `R2014b` users could use the `cygwin`-option by using the provided `mexopts-win64.bat` from http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation, which should not have this restriction. Since `R2015b`, `mingw` is available, which also supports `C99` (#1226). Moreover, Visual Studio 2015 finally supports `C99` and has a free available version that is supported since `R2015b`. That leaves 64bit Matlab-versions between `R2014a` and `R2015a` unable to deal with the problem unless someone figures out how to solve #641 for `cygwin` (potentially following the advice on how to set up the `xml`-file at http://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler). Given that there seems to be not that much demand for `use_dll` on Windows, I would propose for 4.5 to focus on the `mingw`-support and state the above restrictions clearly in the release notes and the manual
4.5https://git.dynare.org/Dynare/dynare/-/issues/1226Support mingw-compiler on Windows2019-06-19T15:37:49ZJohannes Pfeifer Support mingw-compiler on WindowsSince Matlab2014a, the `mexopts.bat` cannot be used anymore to set the mex-compiler to `cygwin`, rendering it pretty much useless for most recent versions. However, Mathworks now has a MinGW-addon (http://de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html) that we should support.
For this, we need to
1. Allow for a `mingw` command line flag
2. Adjust `dyn_mex` with the respective case distinction and necessary flags
3. Update http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
Since Matlab2014a, the `mexopts.bat` cannot be used anymore to set the mex-compiler to `cygwin`, rendering it pretty much useless for most recent versions. However, Mathworks now has a MinGW-addon (http://de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html) that we should support.
For this, we need to
1. Allow for a `mingw` command line flag
2. Adjust `dyn_mex` with the respective case distinction and necessary flags
3. Update http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
4.5Johannes Pfeifer Houtan BastaniJohannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1215qz_criterium in estimation2019-06-19T15:37:49ZMarco Rattoqz_criterium in estimationI think it would be useful to allow option `qz_criterium` also in estimation, similarly to simulation. Would it be possible? Is there any strong reason for not allowing this?
I think it would be useful to allow option `qz_criterium` also in estimation, similarly to simulation. Would it be possible? Is there any strong reason for not allowing this?
4.5https://git.dynare.org/Dynare/dynare/-/issues/1209rework recent static model preprocessor changes2019-06-19T15:37:49ZHoutan Bastanirework recent static model preprocessor changesThe changes to the preprocessor made in 6e514b7d1bfc4b76fbc483da1da0ae7416de7cda have been made in the `computingPass` when they should have been made in the `transformPass`. Move these changes from `StaticModel::computingPass` to `DynamicModel::toStatic`
The changes to the preprocessor made in 6e514b7d1bfc4b76fbc483da1da0ae7416de7cda have been made in the `computingPass` when they should have been made in the `transformPass`. Move these changes from `StaticModel::computingPass` to `DynamicModel::toStatic`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1211Check newrat-implementation and potentially port Michel's changes2019-06-19T15:37:49ZJohannes Pfeifer Check newrat-implementation and potentially port Michel's changesDuring his first try of removing `objective_function_penalty_base` @MichelJuillard made various changes to `newrat` that were reverted, but potentially still need to be ported to `master`. But I am not entirely sure what these commits do. @rattoma Could you maybe have a look.
1. In the reverted commits https://github.com/DynareTeam/dynare/commit/fe077fc7103658aab7becba95167aa9d240b07f1 and https://github.com/DynareTeam/dynare/commit/f48a026d89828e9e322333263f56b733a719eb34 the initialization of `mr_hessian` was removed.
2. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the `newratflag`was passed to the optimizer, but this was reverted in https://github.com/DynareTeam/dynare/commit/d4cf3576e468202df9d1582a045dfcfd74e2e7db . What is the correct setting here?
3. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the part
```
if analytic_derivation,
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
was replaced by
`hhx=hh;`
But when I tried this, the program crashed in tests.
During his first try of removing `objective_function_penalty_base` @MichelJuillard made various changes to `newrat` that were reverted, but potentially still need to be ported to `master`. But I am not entirely sure what these commits do. @rattoma Could you maybe have a look.
1. In the reverted commits https://github.com/DynareTeam/dynare/commit/fe077fc7103658aab7becba95167aa9d240b07f1 and https://github.com/DynareTeam/dynare/commit/f48a026d89828e9e322333263f56b733a719eb34 the initialization of `mr_hessian` was removed.
2. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the `newratflag`was passed to the optimizer, but this was reverted in https://github.com/DynareTeam/dynare/commit/d4cf3576e468202df9d1582a045dfcfd74e2e7db . What is the correct setting here?
3. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the part
```
if analytic_derivation,
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
was replaced by
`hhx=hh;`
But when I tried this, the program crashed in tests.
4.5https://git.dynare.org/Dynare/dynare/-/issues/1203In the latest unstable, sparse_hessian_times_B_kronecker_C.mexw64 has a depen...2019-06-19T15:37:50ZTom HoldenIn the latest unstable, sparse_hessian_times_B_kronecker_C.mexw64 has a dependency on libgomp-1.dllI was getting errors about missing dependencies. Running Dependency Walker on it revealed libgomp-1.dll as the problem. Copying this across from MinGW fixed the issue.
I was getting errors about missing dependencies. Running Dependency Walker on it revealed libgomp-1.dll as the problem. Copying this across from MinGW fixed the issue.
4.5https://git.dynare.org/Dynare/dynare/-/issues/1201Depth issue2019-06-19T15:37:50ZStéphane Adjemianstepan@adjemian.euDepth issueLooking into #1175 , by reverting commit 3c7e60b744567f6f39a9c611bce6dcaadcd52bc6, I obtained the following error from matlab when trying to run Christiano-Motto-Rostagno model (the one in subfolder `figure4` of the archive available [here](http://faculty.wcas.northwestern.edu/~lchrist/research/ECB/risk_shocks/20100922_data.zip)
```
Error: File: cmr_static.m Line: 1292 Column: 16331
Nesting of {, [, and ( cannot exceed a depth of 32.
```
@MichelJuillard May this be a consequence of your patch about on auxiliary variables in steady state and static files (see #1133)?
Looking into #1175 , by reverting commit 3c7e60b744567f6f39a9c611bce6dcaadcd52bc6, I obtained the following error from matlab when trying to run Christiano-Motto-Rostagno model (the one in subfolder `figure4` of the archive available [here](http://faculty.wcas.northwestern.edu/~lchrist/research/ECB/risk_shocks/20100922_data.zip)
```
Error: File: cmr_static.m Line: 1292 Column: 16331
Nesting of {, [, and ( cannot exceed a depth of 32.
```
@MichelJuillard May this be a consequence of your patch about on auxiliary variables in steady state and static files (see #1133)?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1202Provide Windows cross compilation instructions2019-06-19T15:37:50ZTom HoldenProvide Windows cross compilation instructionsI know building on Windows is no-longer supported. Still, building for Windows ought to be supported.
Thus, it would be a great help if there were e.g. a script for cross compiling for Windows from Linux.
The dependencies make this rather painful.
I know building on Windows is no-longer supported. Still, building for Windows ought to be supported.
Thus, it would be a great help if there were e.g. a script for cross compiling for Windows from Linux.
The dependencies make this rather painful.
https://git.dynare.org/Dynare/dynare/-/issues/1199Check mode-file related options of slice2019-06-19T15:37:50ZJohannes Pfeifer Check mode-file related options of sliceAs discussed with @rattoma it is not clear the preprocessor can handle the necessary inputs which must be a set of vectors or an array of strings. We might need to delete the mode option from the manual and provide an example of the mode_files option
As discussed with @rattoma it is not clear the preprocessor can handle the necessary inputs which must be a set of vectors or an array of strings. We might need to delete the mode option from the manual and provide an example of the mode_files option
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1195Fix parallel error/warning on Windows systems2019-11-21T08:36:44ZJohannes 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.
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1194Allow for comments in parallel configuration files2019-06-19T15:37:50ZJohannes Pfeifer Allow for comments in parallel configuration filesWe would need a way to add comments to configuration files. @rattoma were thinking about using the hashtag # for this (unless someone envisions a role for it on Windows/MAC/Unix).
We would need a way to add comments to configuration files. @rattoma were thinking about using the hashtag # for this (unless someone envisions a role for it on Windows/MAC/Unix).
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1193Make preprocessor recognize state variables introduced by optimal policy2019-06-19T15:37:50ZJohannes Pfeifer Make preprocessor recognize state variables introduced by optimal policyIn the mod-file
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3;
omega=17;
epsilon=8;
phi=1;
rho=0.95;
model;
a = rho*a(-1)+u;
1/c = beta*r/(c(+1)*pai(+1));
pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega -exp(a)*n*(epsilon-1)/(omega*c);
exp(a)*n = c+(omega/2)*(pai-1)^2;
end;
initval;
r=1;
end;
histval;
a(0)=1;
r(0)=1;
end;
steady_state_model;
a = 0;
pai = beta*r;
c = find_c(0.96,pai,beta,epsilon,phi,gamma,omega);
n = c+(omega/2)*(pai-1)^2;
end;
shocks;
var u; stderr 0.008;
var u;
periods 1;
values 1;
end;
options_.dr_display_tol=0;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma)));
ramsey_policy(planner_discount=0.99,order=1,instruments=(r));
```
`r` becomes a state variable during Ramsey computations (albeit with 0 coefficients). As a state, one should be able to set its lagged value using `histval`. But this is not possible, as the preprocessor does not recognize `r` as a state.
In the mod-file
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3;
omega=17;
epsilon=8;
phi=1;
rho=0.95;
model;
a = rho*a(-1)+u;
1/c = beta*r/(c(+1)*pai(+1));
pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega -exp(a)*n*(epsilon-1)/(omega*c);
exp(a)*n = c+(omega/2)*(pai-1)^2;
end;
initval;
r=1;
end;
histval;
a(0)=1;
r(0)=1;
end;
steady_state_model;
a = 0;
pai = beta*r;
c = find_c(0.96,pai,beta,epsilon,phi,gamma,omega);
n = c+(omega/2)*(pai-1)^2;
end;
shocks;
var u; stderr 0.008;
var u;
periods 1;
values 1;
end;
options_.dr_display_tol=0;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma)));
ramsey_policy(planner_discount=0.99,order=1,instruments=(r));
```
`r` becomes a state variable during Ramsey computations (albeit with 0 coefficients). As a state, one should be able to set its lagged value using `histval`. But this is not possible, as the preprocessor does not recognize `r` as a state.
4.5.2Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1187allow to skip 2nd order param derivs2019-06-19T15:37:50ZMarco Rattoallow to skip 2nd order param derivsFor large models, computing the analytic Hessian just produces a too big `_params_derivs.m` file which is untractable.
For running identification or only computing scores, 2nd order derivs would be useless.
@houtanb Would it be possible to tell the pre-processor to only compute 1st order derivatives, i.e. stop writing the `param_derivs` file when it reaches
`if nargout >= 3 ...`
?
2nd order terms could be just defined as empty, and routines (`dsge_likelihood`) possibly asking for 2nd order ones will trap this and just stop.
For large models, computing the analytic Hessian just produces a too big `_params_derivs.m` file which is untractable.
For running identification or only computing scores, 2nd order derivs would be useless.
@houtanb Would it be possible to tell the pre-processor to only compute 1st order derivatives, i.e. stop writing the `param_derivs` file when it reaches
`if nargout >= 3 ...`
?
2nd order terms could be just defined as empty, and routines (`dsge_likelihood`) possibly asking for 2nd order ones will trap this and just stop.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1184Crash in preprocessor in unstable branch2019-06-19T15:37:50ZMarco RattoCrash in preprocessor in unstable branchI get a crash in the preprocessor in the unstable branch, since I rebased my local unstable branch onto the recent commits [pervious preprocessor versions I used date back October 2015 ...] when dealing with our Global Multicountry model.
I get the error both in Windows and MacOS.
In MacOS I get the following message:
`
dynare_m(554,0x7fff7411b300) malloc:
`
`
*** error for object 0x7fda6a60ccd0: pointer being freed was not allocated
`
`
*** set a breakpoint in malloc_error_break to debug
`
apparently what triggers the error is the use of `trend_var` and `deflator` instructions.
When I filter out detrending, pre-processing completes.
I can share a replication package privately.
with older versions of the unstable preprocessor everything went fine.
I get a crash in the preprocessor in the unstable branch, since I rebased my local unstable branch onto the recent commits [pervious preprocessor versions I used date back October 2015 ...] when dealing with our Global Multicountry model.
I get the error both in Windows and MacOS.
In MacOS I get the following message:
`
dynare_m(554,0x7fff7411b300) malloc:
`
`
*** error for object 0x7fda6a60ccd0: pointer being freed was not allocated
`
`
*** set a breakpoint in malloc_error_break to debug
`
apparently what triggers the error is the use of `trend_var` and `deflator` instructions.
When I filter out detrending, pre-processing completes.
I can share a replication package privately.
with older versions of the unstable preprocessor everything went fine.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1183Fix compatibility with matlab 2016a in installer and mex-folder2019-06-19T15:37:51ZStéphane Adjemianstepan@adjemian.euFix compatibility with matlab 2016a in installer and mex-folderI had to revert commit 6072aa0b462484da990ffa00ee39fb141fa9513f (which is PR #1144 by @JohannesPfeifer) because the snapshot build failed this evening. The generated mex files are not saved in the expected directory. They are saved in `mex/matlab/win64-7.8-8.6` instead of `mex/matlab/win64-7.8-9.0`. I did not find where the name of this directory is controlled. @houtanb can you fix this?
I had to revert commit 6072aa0b462484da990ffa00ee39fb141fa9513f (which is PR #1144 by @JohannesPfeifer) because the snapshot build failed this evening. The generated mex files are not saved in the expected directory. They are saved in `mex/matlab/win64-7.8-8.6` instead of `mex/matlab/win64-7.8-9.0`. I did not find where the name of this directory is controlled. @houtanb can you fix this?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1179Fix cross-compilation of Dynare++ for Windows2019-06-19T15:37:51ZJohannes Pfeifer Fix cross-compilation of Dynare++ for WindowsWith the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
With the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1178Ship Dynare++ example in Dynare++ folder2019-06-19T15:37:51ZJohannes Pfeifer Ship Dynare++ example in Dynare++ folderI would suggest we provide the example from the documentation, but with a lower order:
```
var Y, C, K, A, H, B;
varexo EPS, NU;
parameters beta, rho, alpha, delta, theta, psi, tau;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 1/(1.03^0.25);
delta = 0.025;
psi = 0;
theta = 2.95;
model;
C*theta*H^(1+psi) = (1-alpha)*Y;
beta*exp(B)*C/exp(B(1))/C(1)*
(exp(B(1))*alpha*Y(1)/K(1)+1-delta) = 1;
Y = exp(A)*K^alpha*H^(1-alpha);
K = exp(B(-1))*(Y(-1)-C(-1)) + (1-delta)*K(-1);
A = rho*A(-1) + tau*B(-1) + EPS;
B = tau*A(-1) + rho*B(-1) + NU;
end;
initval;
A = 0;
B = 0;
H = ((1-alpha)/(theta*(1-(delta*alpha)
/(1/beta-1+delta))))^(1/(1+psi));
Y = (alpha/(1/beta-1+delta))^(alpha/(1-alpha))*H;
K = alpha/(1/beta-1+delta)*Y;
C = Y - delta*K;
end;
vcov = [0.0002 0.00005;
0.00005 0.0001
];
order = 5;
```
I would suggest we provide the example from the documentation, but with a lower order:
```
var Y, C, K, A, H, B;
varexo EPS, NU;
parameters beta, rho, alpha, delta, theta, psi, tau;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 1/(1.03^0.25);
delta = 0.025;
psi = 0;
theta = 2.95;
model;
C*theta*H^(1+psi) = (1-alpha)*Y;
beta*exp(B)*C/exp(B(1))/C(1)*
(exp(B(1))*alpha*Y(1)/K(1)+1-delta) = 1;
Y = exp(A)*K^alpha*H^(1-alpha);
K = exp(B(-1))*(Y(-1)-C(-1)) + (1-delta)*K(-1);
A = rho*A(-1) + tau*B(-1) + EPS;
B = tau*A(-1) + rho*B(-1) + NU;
end;
initval;
A = 0;
B = 0;
H = ((1-alpha)/(theta*(1-(delta*alpha)
/(1/beta-1+delta))))^(1/(1+psi));
Y = (alpha/(1/beta-1+delta))^(alpha/(1-alpha))*H;
K = alpha/(1/beta-1+delta)*Y;
C = Y - delta*K;
end;
vcov = [0.0002 0.00005;
0.00005 0.0001
];
order = 5;
```
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1176Investigate crash in sim1_linear.m2019-06-19T15:37:51ZJohannes Pfeifer Investigate crash in sim1_linear.mThe following mod-file crashes Dynare in master
```
var pi y pi_annual;
varexo x;
parameters kappa beta sigma lambda rho phi_pi phi_y;
kappa=.025;
beta=.995;
sigma=1;
lambda=1;
rho=.8;
phi_pi=1.5;
phi_y=.5;
model(linear);
pi =(kappa/(1+beta*lambda))*(-1/sigma*x+1/kappa*pi(+1)-beta/kappa*pi(+2)+1/sigma*beta*pi(+1))+(beta/(1+beta*lambda))*pi(+1)+(lambda/(1+beta*lambda))*pi(-1);
x=sigma*(y(+1)-y)+pi(+1);
pi_annual=4*pi;
end;
shocks;
var x;
periods 1:1;
values -0.005;
end;
simul(periods=1);
```
Setting periods bigger than 1 solves the issue.
The following mod-file crashes Dynare in master
```
var pi y pi_annual;
varexo x;
parameters kappa beta sigma lambda rho phi_pi phi_y;
kappa=.025;
beta=.995;
sigma=1;
lambda=1;
rho=.8;
phi_pi=1.5;
phi_y=.5;
model(linear);
pi =(kappa/(1+beta*lambda))*(-1/sigma*x+1/kappa*pi(+1)-beta/kappa*pi(+2)+1/sigma*beta*pi(+1))+(beta/(1+beta*lambda))*pi(+1)+(lambda/(1+beta*lambda))*pi(-1);
x=sigma*(y(+1)-y)+pi(+1);
pi_annual=4*pi;
end;
shocks;
var x;
periods 1:1;
values -0.005;
end;
simul(periods=1);
```
Setting periods bigger than 1 solves the issue.
4.5https://git.dynare.org/Dynare/dynare/-/issues/1177Implement interface for posterior sampling methods2019-06-19T15:37:51ZJohannes Pfeifer Implement interface for posterior sampling methodsRelated to #1174 and #1065
I would propose to use this occasion to further clean up the `options_`-structure and create a field `options_.posterior_sampler_options` that stores as subfields the various options.
The preprocessor should have an option `posterior_sampling_method` that accepts a quoted string that can be `slice`, `random_walk_metropolis_hastings`, `independent_metropolis_hastings` or `tailored_random_block_metropolis_hastings`
It should map into `options_.posterior_sampler_options.posterior_sampling_method` with default
`random_walk_metropolis_hastings`, which replaces the current `options_.posterior_sampling_method`
In addition:
1. We need a subfields `options_.posterior_sampler_options.tarb`, `options_.posterior_sampler_options.rwmh`,`options_.posterior_sampler_options.slice`,
and `options_.posterior_sampler_options.imh` that store the default options for the respective sampler as we already do for different mode_computes.
2. We need the preprocessor to accept name/value pairs like in the already existing `optim`-option in the form of `posterior_sampler_options = (NAME, VALUE,...)`.
It should map into a string `options_.posterior_sampler_options.sampling_opt`, which can then be read out using `read_key_value_string` as we already do in `dynare_minimize_objective`.
3. The already existing but undocumented options `options_.proposal_distribution` and `options_.student_degrees_of_freedom` should now become sampler-specific subfields of the fields introduced in 1.
Related to #1174 and #1065
I would propose to use this occasion to further clean up the `options_`-structure and create a field `options_.posterior_sampler_options` that stores as subfields the various options.
The preprocessor should have an option `posterior_sampling_method` that accepts a quoted string that can be `slice`, `random_walk_metropolis_hastings`, `independent_metropolis_hastings` or `tailored_random_block_metropolis_hastings`
It should map into `options_.posterior_sampler_options.posterior_sampling_method` with default
`random_walk_metropolis_hastings`, which replaces the current `options_.posterior_sampling_method`
In addition:
1. We need a subfields `options_.posterior_sampler_options.tarb`, `options_.posterior_sampler_options.rwmh`,`options_.posterior_sampler_options.slice`,
and `options_.posterior_sampler_options.imh` that store the default options for the respective sampler as we already do for different mode_computes.
2. We need the preprocessor to accept name/value pairs like in the already existing `optim`-option in the form of `posterior_sampler_options = (NAME, VALUE,...)`.
It should map into a string `options_.posterior_sampler_options.sampling_opt`, which can then be read out using `read_key_value_string` as we already do in `dynare_minimize_objective`.
3. The already existing but undocumented options `options_.proposal_distribution` and `options_.student_degrees_of_freedom` should now become sampler-specific subfields of the fields introduced in 1.
4.5https://git.dynare.org/Dynare/dynare/-/issues/1172Remove or fix dsgevar_posterior_density.m2019-06-19T15:37:51ZJohannes Pfeifer Remove or fix dsgevar_posterior_density.mThe function is nowhere used and is totally buggy as it even does not reflect name changes in the header within the function (e.g. DynareOption instead of options_ )
The function is nowhere used and is totally buggy as it even does not reflect name changes in the header within the function (e.g. DynareOption instead of options_ )
4.5https://git.dynare.org/Dynare/dynare/-/issues/1165stochastic_solvers calls transition_matrix without passing M_2019-06-19T15:37:51ZTom Holdenstochastic_solvers calls transition_matrix without passing M_transition_matrix optionally takes M_ as an additional argument. If it doesn't get the extra argument, then it uses the global M_.
Given that stochastic_solvers takes M_ as an additional argument, it should also pass this to transition_matrix.
Without this, user code that calls Dynare internals in parallel can be messed up.
transition_matrix optionally takes M_ as an additional argument. If it doesn't get the extra argument, then it uses the global M_.
Given that stochastic_solvers takes M_ as an additional argument, it should also pass this to transition_matrix.
Without this, user code that calls Dynare internals in parallel can be messed up.
https://git.dynare.org/Dynare/dynare/-/issues/1160Implement filter_covariance option in Bayesian estimation2019-11-21T08:36:41ZJohannes Pfeifer Implement filter_covariance option in Bayesian estimationCurrently only possible in ML and calibrated smoother
Currently only possible in ML and calibrated smoother
https://git.dynare.org/Dynare/dynare/-/issues/1161Fix selected_variables_only option2019-06-19T15:37:51ZJohannes Pfeifer Fix selected_variables_only optionIn Dynare 4.4.3, we have in `dynare_estimation_1`
```
for i=bayestopt_.smoother_saved_var_list'
i1 = dr.order_var(bayestopt_.smoother_var_list(i));
eval(['oo_.SmoothedVariables.' deblank(M_.endo_names(i1,:)) ' = ' ...
'atT(i,:)'';']);
```
But `bayestopt_.smoother_saved_var_list` only saves the index of the variable in `bayestopt_.smoother_var_list`, not in the decision rules themselves. Therefore, we have to select `atT(bayestopt_.smoother_var_list(i),:)` instead of `atT(i,:)` if `bayestopt_.smoother_var_list` is not equal to `bayestopt_.smoother_saved_var_list`, which happens with `selected_variables_only`
In master the same problem has been ported to `write_smoother_results`
@MichelJuillard @stepan-a Should we try to fix this or should we get rid of the `selected_variables_only` option?
In Dynare 4.4.3, we have in `dynare_estimation_1`
```
for i=bayestopt_.smoother_saved_var_list'
i1 = dr.order_var(bayestopt_.smoother_var_list(i));
eval(['oo_.SmoothedVariables.' deblank(M_.endo_names(i1,:)) ' = ' ...
'atT(i,:)'';']);
```
But `bayestopt_.smoother_saved_var_list` only saves the index of the variable in `bayestopt_.smoother_var_list`, not in the decision rules themselves. Therefore, we have to select `atT(bayestopt_.smoother_var_list(i),:)` instead of `atT(i,:)` if `bayestopt_.smoother_var_list` is not equal to `bayestopt_.smoother_saved_var_list`, which happens with `selected_variables_only`
In master the same problem has been ported to `write_smoother_results`
@MichelJuillard @stepan-a Should we try to fix this or should we get rid of the `selected_variables_only` option?
https://git.dynare.org/Dynare/dynare/-/issues/1157Save kurtosis and skewness when using simulated moments2019-06-19T15:37:51ZJohannes Pfeifer Save kurtosis and skewness when using simulated momentshttps://git.dynare.org/Dynare/dynare/-/issues/1154Investigate crash of Octave under Windows2019-11-21T08:36:40ZJohannes 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.
https://git.dynare.org/Dynare/dynare/-/issues/1150derivation with respect to the parameters2019-06-19T15:37:52ZMichelJuillardderivation with respect to the parametersWhen modifying <fname>_static.m in order to address problems with auxiliary variables (see #1133), I realized that the creation of <fname>_params_derivs.m and the code for analytical derivatives of the likelihood function assume that the static model is the static version of the <fname>_dynamic, equation by equation.
This is not obvious in the preprocessor where the static model is stored and handled in a different tree and it stops me to find an efficient solution to the computation of the steady state of auxiliary variables.
For this reason, I will introduce two files for the computation of the derivatives with respect to the parameters: <fname>_params_derivs_static and <fname>_derivs_dynamic
I will also change all calling sequences throughout the code
When modifying <fname>_static.m in order to address problems with auxiliary variables (see #1133), I realized that the creation of <fname>_params_derivs.m and the code for analytical derivatives of the likelihood function assume that the static model is the static version of the <fname>_dynamic, equation by equation.
This is not obvious in the preprocessor where the static model is stored and handled in a different tree and it stops me to find an efficient solution to the computation of the steady state of auxiliary variables.
For this reason, I will introduce two files for the computation of the derivatives with respect to the parameters: <fname>_params_derivs_static and <fname>_derivs_dynamic
I will also change all calling sequences throughout the code
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1149Harmonize output of objective functions passed to minimizers2019-06-19T15:37:52ZJohannes Pfeifer Harmonize output of objective functions passed to minimizersPrerequisite for eliminating the global variable `objective_function_penalty_base` (#1051) and to avoid introducing another layer of functions as in reverted commit https://github.com/DynareTeam/dynare/commit/1ad8df4635d99ba775e22f5693bf18c2cbb6c0aa (see also the discussion there)
Prerequisite for eliminating the global variable `objective_function_penalty_base` (#1051) and to avoid introducing another layer of functions as in reverted commit https://github.com/DynareTeam/dynare/commit/1ad8df4635d99ba775e22f5693bf18c2cbb6c0aa (see also the discussion there)
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1147Do remaining tasks for trends and prefiltering changes2019-06-19T15:37:52ZJohannes Pfeifer Do remaining tasks for trends and prefiltering changesLeft after #1145:
- Check treatment of various options and trends in smoother used in `imcforecast.m`
- Check treatment of these issues in `identification`
- Adjust `convert_dyn_45_to_44` to reflect these changes
- Add trend estimate to output from `prior_posterior_statistics_core`
Left after #1145:
- Check treatment of various options and trends in smoother used in `imcforecast.m`
- Check treatment of these issues in `identification`
- Adjust `convert_dyn_45_to_44` to reflect these changes
- Add trend estimate to output from `prior_posterior_statistics_core`
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1133auxiliary variables in steady state and static model2019-06-19T15:37:52ZMichelJuillardauxiliary variables in steady state and static modelCurrently, in static model and set_auxiliary_variables.m, auxiliary variables may appear in the RHS of equations. This is problematic for two reasons:
1. assignments may not be recurice in set_auxiliary_variables.m which leads to errors
2. <fname>_static.m may not be solved independently from set_auxiliary_variables.m
In the static deterministic model, any auxiliary variable, except Lagrange multipliers for Ramsey policy, can be replaced with an expression using only original variables.
In the preprocessor, I want to rewrite <fname>_static.m and <fname>_set_auxiliary_variables.m along these lines.
I expect this changes to solve #1119 and #633
Currently, in static model and set_auxiliary_variables.m, auxiliary variables may appear in the RHS of equations. This is problematic for two reasons:
1. assignments may not be recurice in set_auxiliary_variables.m which leads to errors
2. <fname>_static.m may not be solved independently from set_auxiliary_variables.m
In the static deterministic model, any auxiliary variable, except Lagrange multipliers for Ramsey policy, can be replaced with an expression using only original variables.
In the preprocessor, I want to rewrite <fname>_static.m and <fname>_set_auxiliary_variables.m along these lines.
I expect this changes to solve #1119 and #633
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1128Extended Path disagreeing with OccBin and DynareOBC on linear models2019-06-19T15:37:52ZTom HoldenExtended Path disagreeing with OccBin and DynareOBC on linear modelsDynareOBC contains tests which solve the same otherwise linear model with the Extended Path, OccBin, and with DynareOBC. OccBin and DynareOBC agree (up to the order of 10^(-8)), but the extended path is way off (e.g. responses 10 times larger).
(It's just possible that there's something up with my version of Dynare, but the fact that running `git diff upstream/master -- matlab/ep/` produces no output suggests that this probably isn't the problem at least.)
The tests are in this folder: https://github.com/tholden/dynareOBC/tree/master/Tests/ComparisonOfPerfectForesightSolutionsForLinearModels
You could just compare OccBin vs ExtendedPath by commenting out the appropriate lines of RunAllAndCompare.m, saving you the trouble of setting up DynareOBC.
DynareOBC contains tests which solve the same otherwise linear model with the Extended Path, OccBin, and with DynareOBC. OccBin and DynareOBC agree (up to the order of 10^(-8)), but the extended path is way off (e.g. responses 10 times larger).
(It's just possible that there's something up with my version of Dynare, but the fact that running `git diff upstream/master -- matlab/ep/` produces no output suggests that this probably isn't the problem at least.)
The tests are in this folder: https://github.com/tholden/dynareOBC/tree/master/Tests/ComparisonOfPerfectForesightSolutionsForLinearModels
You could just compare OccBin vs ExtendedPath by commenting out the appropriate lines of RunAllAndCompare.m, saving you the trouble of setting up DynareOBC.
https://git.dynare.org/Dynare/dynare/-/issues/1125make xref more efficient, write to .m file2019-06-19T15:37:52ZHoutan Bastanimake xref more efficient, write to .m fileFrom @MichelJuillard
For large models it is really slow. I think that we should
1) add an Dynare option to compute them and write them in `*.m` file
(unless it is required for a particular computation, but it is not yet
the case)
2) change the Matlab code: `{end+1}` is very elegant but very inefficient
because Matlab makes memory allocations several times. It is better to
initialize first the cellarray and use an index for the assignment. The
size is `M_.endo_nbr` and `M_.eq_nbr`
From @MichelJuillard
For large models it is really slow. I think that we should
1) add an Dynare option to compute them and write them in `*.m` file
(unless it is required for a particular computation, but it is not yet
the case)
2) change the Matlab code: `{end+1}` is very elegant but very inefficient
because Matlab makes memory allocations several times. It is better to
initialize first the cellarray and use an index for the assignment. The
size is `M_.endo_nbr` and `M_.eq_nbr`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1119Investigate potential bug introduced by 15716124fa6f061ca21e8f6c5a4907a4b0c525622019-06-19T15:37:52ZHoutan BastaniInvestigate potential bug introduced by 15716124fa6f061ca21e8f6c5a4907a4b0c52562The change introduced in 15716124fa6f061ca21e8f6c5a4907a4b0c52562 was meant to fix the existing bug in `aux_equations` that did not recursively substitute variables in `aux_equations` even though they were substituted in `equations`. We must see if this commit introduced a bug or if there is a bug in the way ramsey code deals with auxiliary equations.
@JohannesPfeifer pointed this out due to the failure of `optimal_policy/Ramsey/ramsey_ex_aux.mod` introduced by this commit
The change introduced in 15716124fa6f061ca21e8f6c5a4907a4b0c52562 was meant to fix the existing bug in `aux_equations` that did not recursively substitute variables in `aux_equations` even though they were substituted in `equations`. We must see if this commit introduced a bug or if there is a bug in the way ramsey code deals with auxiliary equations.
@JohannesPfeifer pointed this out due to the failure of `optimal_policy/Ramsey/ramsey_ex_aux.mod` introduced by this commit
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1121Fix compilation flags in the build system2019-06-19T15:37:52ZStéphane Adjemianstepan@adjemian.euFix compilation flags in the build systemCompilation flags (`CFLAGS` and `CXXFLAGS`) specified with the `configure` script are not passed correctly when building the mex files (the preprocessor and dynare++ honour the flags). So the mex files are always compiled with debug symbols and it is not possible to use more aggressive optimizations (ie `-O3`).
Compilation flags (`CFLAGS` and `CXXFLAGS`) specified with the `configure` script are not passed correctly when building the mex files (the preprocessor and dynare++ honour the flags). So the mex files are always compiled with debug symbols and it is not possible to use more aggressive optimizations (ie `-O3`).
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1117Get rid of globals in make_ex_2019-06-19T15:37:52ZJohannes Pfeifer Get rid of globals in make_ex_Their presence creates a bunch of issues. In dfc89df6a8f5ff0f94c515934caf576088f5c5f6 we added a call to `make_ex_` to make the `tests/forecast/Hansen_exo_det_forecast.mod` run. But then 105100c7fefcf3610214a5bb8c6970098e8cb9aa eliminated the globals from `dyn_forecast`, splitting the workspace of globals used within `dyn_forecast` from the one set by `make_ex_`, thereby breaking the unit test.
Their presence creates a bunch of issues. In dfc89df6a8f5ff0f94c515934caf576088f5c5f6 we added a call to `make_ex_` to make the `tests/forecast/Hansen_exo_det_forecast.mod` run. But then 105100c7fefcf3610214a5bb8c6970098e8cb9aa eliminated the globals from `dyn_forecast`, splitting the workspace of globals used within `dyn_forecast` from the one set by `make_ex_`, thereby breaking the unit test.
https://git.dynare.org/Dynare/dynare/-/issues/1113Make Dynare compatible with Octave 4.22019-11-21T08:36:44ZJohannes 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
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1111is tests/reporting/example1.mod syntax up to date? Is the test necessary?2019-06-19T15:37:52ZHoutan Bastaniis tests/reporting/example1.mod syntax up to date? Is the test necessary?4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1110make substitutions in aux_equations the same way as in equations in DynamicMo...2019-06-19T15:37:52ZHoutan Bastanimake substitutions in aux_equations the same way as in equations in DynamicModel::substituteLeadLagInternalcurrently, `aux_equations` and the auxiliary equations in `equations` are out of sync
currently, `aux_equations` and the auxiliary equations in `equations` are out of sync
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1106Make treatment of delimiters in missing/strjoin compatible with Matlab2019-06-19T15:37:52ZJohannes Pfeifer Make treatment of delimiters in missing/strjoin compatible with MatlabThe Dynare version returns for `strjoin({'aa','bb'},'\n')`
`ans =aa\nbb`
while Matlab returns
```
ans =
aa
bb
```
The same holds for other delimiters like the tabulator `\t` that are treated like literal characters.
The Dynare version returns for `strjoin({'aa','bb'},'\n')`
`ans =aa\nbb`
while Matlab returns
```
ans =
aa
bb
```
The same holds for other delimiters like the tabulator `\t` that are treated like literal characters.
Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1105Fix several identification issues2019-06-19T15:37:52ZJohannes Pfeifer Fix several identification issuesConsider the following mod-file
```
var C Y T Dd;
varexo eps_1 eps_2 eps_3;
parameters root1 root2;
//rho1=1.5;
//rho2=-0.6;
root1=0.95; //root1=1.5/2+sqrt((1.5/2)^2+(-0.6))
root2=0.55; //root1=1.5/2-sqrt((1.5/2)^2+(-0.6))
model;
// parameter conversion
# rho1= (root1+root2);
# rho2= - root1*root2;
// model equation
Y = T + C;
C = rho1*C(-1)+rho2*C(-2)+ eps_1;
(T-T(-1))-(T(-1)-T(-2))= Dd(-1) + eps_2-eps_2(-1);
Dd = eps_3;
end;
// 2. Steady-state
steady_state_model;
T = 1;
Y = 1;
Dd=0;
C = 0;
end;
shocks;
var eps_1; stderr 0.1;
var eps_2; stderr 0.1;
var eps_3; stderr 0.1;
end;
stoch_simul(periods=2501, order=1);
save d_obs Y;
//3.2 ML Estimation
estimated_params;
stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
root2, 0.55, -0.9999, 0.9999;
end;
varobs Y;
identification(diffuse_filter);
estimation(datafile=d_obs, presample=4, first_obs=1, mode_compute=4, mode_check, diffuse_filter); // simulated data (MLE)
```
1. The problem is that after `identification_analysis` resets the number of autocorrelations, we have the line
`evalin('caller',['options_ident.ar=',int2str(nlags),';']);`
that is, only in the original caller, which is `dynare_identification.m`, is it reset. When the mod-file now reaches `simulated_moment_uncertainty.m` the variable accessed is `options` and not `options_ident` where `ar` is still at the old value.
I am not sure what is the best design choice to solve this issue. That is why I would leave it to you.
2. Now use
```
estimated_params;
//stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
//stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
// root2, 0.55, -0.9999, 0.9999;
end;
```
instead and there will be a different crash due to nonconformable dimensions in `S=[S;zeros(size(JJ,2)-length(indJJ),1)];` in `identification_analysis`
1. I wonder why the standard deviation of eps_2 is not identifiable in the original mod-file, but the likelihood function shows curvature, although ML is used.
Consider the following mod-file
```
var C Y T Dd;
varexo eps_1 eps_2 eps_3;
parameters root1 root2;
//rho1=1.5;
//rho2=-0.6;
root1=0.95; //root1=1.5/2+sqrt((1.5/2)^2+(-0.6))
root2=0.55; //root1=1.5/2-sqrt((1.5/2)^2+(-0.6))
model;
// parameter conversion
# rho1= (root1+root2);
# rho2= - root1*root2;
// model equation
Y = T + C;
C = rho1*C(-1)+rho2*C(-2)+ eps_1;
(T-T(-1))-(T(-1)-T(-2))= Dd(-1) + eps_2-eps_2(-1);
Dd = eps_3;
end;
// 2. Steady-state
steady_state_model;
T = 1;
Y = 1;
Dd=0;
C = 0;
end;
shocks;
var eps_1; stderr 0.1;
var eps_2; stderr 0.1;
var eps_3; stderr 0.1;
end;
stoch_simul(periods=2501, order=1);
save d_obs Y;
//3.2 ML Estimation
estimated_params;
stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
root2, 0.55, -0.9999, 0.9999;
end;
varobs Y;
identification(diffuse_filter);
estimation(datafile=d_obs, presample=4, first_obs=1, mode_compute=4, mode_check, diffuse_filter); // simulated data (MLE)
```
1. The problem is that after `identification_analysis` resets the number of autocorrelations, we have the line
`evalin('caller',['options_ident.ar=',int2str(nlags),';']);`
that is, only in the original caller, which is `dynare_identification.m`, is it reset. When the mod-file now reaches `simulated_moment_uncertainty.m` the variable accessed is `options` and not `options_ident` where `ar` is still at the old value.
I am not sure what is the best design choice to solve this issue. That is why I would leave it to you.
2. Now use
```
estimated_params;
//stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
//stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
// root2, 0.55, -0.9999, 0.9999;
end;
```
instead and there will be a different crash due to nonconformable dimensions in `S=[S;zeros(size(JJ,2)-length(indJJ),1)];` in `identification_analysis`
1. I wonder why the standard deviation of eps_2 is not identifiable in the original mod-file, but the likelihood function shows curvature, although ML is used.
https://git.dynare.org/Dynare/dynare/-/issues/1092Allow changing planner_discount in mod-file (preprocessor restriction)2019-06-19T15:37:52ZJohannes Pfeifer Allow changing planner_discount in mod-file (preprocessor restriction)See the discussion on the mailing list on 31/08/2015. This problem crashes the `Gali_discretion.mod` unit test. My proposal is:
Treat the planner_discount option like any other option (or parameter for that matter) and allow resetting it via the same statement later on. If a warning is needed, I would provide a warning that the planner_discount has been updated. But I don't really see the need for this warning. Changing parameters is common.
See the discussion on the mailing list on 31/08/2015. This problem crashes the `Gali_discretion.mod` unit test. My proposal is:
Treat the planner_discount option like any other option (or parameter for that matter) and allow resetting it via the same statement later on. If a warning is needed, I would provide a warning that the planner_discount has been updated. But I don't really see the need for this warning. Changing parameters is common.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1094Check setting of bayestopt_ in set_prior.m2019-06-19T15:37:52ZJohannes Pfeifer Check setting of bayestopt_ in set_prior.mIn master, `ls2003.mod` crashes, because `set_prior.m` is called, which overwrites `bayestopt_` globally. The main culprit is the bottom line:
```
% Put bayestopt_ in matlab's workspace
assignin('base','bayestopt_',bayestopt_);
```
I don't understand why we have `set_prior.m` returning `bayestopt_` as a function output and simultaneously setting it as a global variable. I would propose getting rid of the above statement.
In master, `ls2003.mod` crashes, because `set_prior.m` is called, which overwrites `bayestopt_` globally. The main culprit is the bottom line:
```
% Put bayestopt_ in matlab's workspace
assignin('base','bayestopt_',bayestopt_);
```
I don't understand why we have `set_prior.m` returning `bayestopt_` as a function output and simultaneously setting it as a global variable. I would propose getting rid of the above statement.
https://git.dynare.org/Dynare/dynare/-/issues/1090Save marginal data density from BVAR2019-06-19T15:37:53ZJohannes Pfeifer Save marginal data density from BVARCurrently, it is computed and displayed, but not stored. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7365
Currently, it is computed and displayed, but not stored. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7365
https://git.dynare.org/Dynare/dynare/-/issues/1081Add Chandrasekhar Recursion Kalman Filter2019-11-21T08:36:41ZJohannes 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
https://git.dynare.org/Dynare/dynare/-/issues/1077Integrate doubling algorithm into lyapunov_symm2019-11-21T08:36:42ZJohannes 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.
https://git.dynare.org/Dynare/dynare/-/issues/1076Add preprocessor interface for prior_posterior_function2019-06-19T15:37:53ZJohannes Pfeifer Add preprocessor interface for prior_posterior_functionSee original PR https://github.com/DynareTeam/dynare/pull/871
See original PR https://github.com/DynareTeam/dynare/pull/871
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1073move test suite timing to bokeh2019-06-19T15:37:54ZHoutan Bastanimove test suite timing to bokeh- store commit number + date of test run
- two y-axes : 1 for matlab test, 1 for octave
- store commit number + date of test run
- two y-axes : 1 for matlab test, 1 for octave
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1074test suite timing: when a test is run more than once on a given day, keep the...2019-06-19T15:37:54ZHoutan Bastanitest suite timing: when a test is run more than once on a given day, keep the last run4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1072fix test suite on OS X2019-06-19T15:37:54ZHoutan Bastanifix test suite on OS XHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1069prevent test suite from failing when a call to octave/matlab fails2019-06-19T15:37:54ZHoutan Bastaniprevent test suite from failing when a call to octave/matlab failsAdd a `-` in front of the calls to octave/matlab. Then add a script afterward that will test for the existence of the `.trs` file and, if it doesn't exist, create it with some information that will allow it to be separated later in the email
Add a `-` in front of the calls to octave/matlab. Then add a script afterward that will test for the existence of the `.trs` file and, if it doesn't exist, create it with some information that will allow it to be separated later in the email
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1070un-revert 48257450475c306c03fdcbea9901bb3ab9fb8293 and 62b1c85fd4638cb01435d3...2019-06-19T15:37:54ZHoutan Bastaniun-revert 48257450475c306c03fdcbea9901bb3ab9fb8293 and 62b1c85fd4638cb01435d35ed2458a538d897d2fThey were reverted to simplify the debugging of the test suite due to the upgrade to Debian Jessie
They were reverted to simplify the debugging of the test suite due to the upgrade to Debian Jessie
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1066Skip dynare initialization when run with noclearall when dynare has previousl...2019-11-21T08:36:44ZTom 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?
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1063Make output of dsge_var_likelihood accessible2019-11-21T08:36:44ZJohannes 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
https://git.dynare.org/Dynare/dynare/-/issues/1065factorizing posterior samplers + inclusion of slice sampler2019-06-19T15:37:54ZMarco Rattofactorizing posterior samplers + inclusion of slice samplerI am going to make a pull request from by personal branch
https://github.com/rattoma/dynare/tree/slice
the aim is to add a new posterior sampler, SLICE, but also to make it easier to add further new ones.
There is a bunch of common codes in random walk, independent, TARB, etc. and I did not want to follow that route.
So I wrote, adapting from random walk algorithm, a new general set of routines
`posterior_sampler_*`
that factorizes the iteration of individual samplers, but the rest of the engine is common: initialization, parallelization, bars, `load_mh_file` etc...
The current implementation fully integrates:
- random walk MH
- independent MH
- slice
It also contains a quick fix for TARB but the latter could be easily fully integrated in the new framework.
An open issue concerns adaptive_metropolis_hastings.m [last commit in 2013], which cannot be easily integrated, so I trapped it in dynare_estimation_1.m keeping the old framework.
Concerning pre-processor provisions, this commit would require:
1) enable slice as new sampler method:
`options_.posterior_sampling_method = 'slice';`
2) enable a form of flexible method specific options, along the lines of optimizers options. would this be possible? To explain better:
I added a new option field `options_.posterior_sampler_options` that can contain method specific options. one could specify a syntax like
`sampler_options=(NAME, VALUE, etc..)`
with name/value pairs. These will be stored as fields of
`options_.posterior_sampler_options`
So the command
`estimation(posterior_sampling_method = slice, sampler_options=('rotated',1), ...)`
would trigger
`options_.posterior_sampler_options.rotated = 1`
what do you think?
I am going to make a pull request from by personal branch
https://github.com/rattoma/dynare/tree/slice
the aim is to add a new posterior sampler, SLICE, but also to make it easier to add further new ones.
There is a bunch of common codes in random walk, independent, TARB, etc. and I did not want to follow that route.
So I wrote, adapting from random walk algorithm, a new general set of routines
`posterior_sampler_*`
that factorizes the iteration of individual samplers, but the rest of the engine is common: initialization, parallelization, bars, `load_mh_file` etc...
The current implementation fully integrates:
- random walk MH
- independent MH
- slice
It also contains a quick fix for TARB but the latter could be easily fully integrated in the new framework.
An open issue concerns adaptive_metropolis_hastings.m [last commit in 2013], which cannot be easily integrated, so I trapped it in dynare_estimation_1.m keeping the old framework.
Concerning pre-processor provisions, this commit would require:
1) enable slice as new sampler method:
`options_.posterior_sampling_method = 'slice';`
2) enable a form of flexible method specific options, along the lines of optimizers options. would this be possible? To explain better:
I added a new option field `options_.posterior_sampler_options` that can contain method specific options. one could specify a syntax like
`sampler_options=(NAME, VALUE, etc..)`
with name/value pairs. These will be stored as fields of
`options_.posterior_sampler_options`
So the command
`estimation(posterior_sampling_method = slice, sampler_options=('rotated',1), ...)`
would trigger
`options_.posterior_sampler_options.rotated = 1`
what do you think?
https://git.dynare.org/Dynare/dynare/-/issues/1059Make names of model-local variables TeX-compatible2019-06-19T15:37:54ZJohannes Pfeifer Make names of model-local variables TeX-compatibleIn particular, replace underscores. See https://github.com/DynareTeam/dynare/issues/263#issuecomment-139540237
Potentially, we might allow defining a TeX-name for them.
In particular, replace underscores. See https://github.com/DynareTeam/dynare/issues/263#issuecomment-139540237
Potentially, we might allow defining a TeX-name for them.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1058Make Dynare compatible with Matlab2015b2019-06-19T15:37:54ZJohannes Pfeifer Make Dynare compatible with Matlab2015bSee https://github.com/DynareTeam/dynare/commit/1a3d8d0b26a398c60221cdceb234036140d8fd4e, 6a17fe5de3e9834da01b6ad10abd891cff35be22, and b4a8ad8aa4b992c49638c90207871a9feaa18c3c for previous version.
See https://github.com/DynareTeam/dynare/commit/1a3d8d0b26a398c60221cdceb234036140d8fd4e, 6a17fe5de3e9834da01b6ad10abd891cff35be22, and b4a8ad8aa4b992c49638c90207871a9feaa18c3c for previous version.
https://git.dynare.org/Dynare/dynare/-/issues/1054argument steadystate_check_flag is ignored in evaluate_steady_state2019-06-19T15:37:54ZMichelJuillardargument steadystate_check_flag is ignored in evaluate_steady_stateMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1057Rethink default clear all to improve compatibility with Matlab 2015b2019-06-19T15:37:54ZJohannes Pfeifer Rethink default clear all to improve compatibility with Matlab 2015bWith Matlab 2015b the default `clear all` statement interferes with the new just-in-time compiler, resulting in many warnings and poor performance.
We may want to get rid of this clear all.
With Matlab 2015b the default `clear all` statement interferes with the new just-in-time compiler, resulting in many warnings and poor performance.
We may want to get rid of this clear all.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1051Eliminate the global variable objective_function_penalty_base2019-06-19T15:37:54ZTom HoldenEliminate the global variable objective_function_penalty_baseThis causes problems when the estimation function is evaluated in parallel, using fmincon's 'UseParallel','always' or similar. Further problems with parallel objectives are given in this issue: https://github.com/DynareTeam/dseries/issues/10
This causes problems when the estimation function is evaluated in parallel, using fmincon's 'UseParallel','always' or similar. Further problems with parallel objectives are given in this issue: https://github.com/DynareTeam/dseries/issues/10
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1053mode_compute=5 breaks computing total execution time2019-06-19T15:37:54ZMichelJuillardmode_compute=5 breaks computing total execution timemode_compute=5 resets maybe time counters with tic and toc. To be checked
mode_compute=5 resets maybe time counters with tic and toc. To be checked
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1047Make Ramsey and discretionary_policy mutually exclusive via preprocessor2019-06-19T15:37:54ZJohannes Pfeifer Make Ramsey and discretionary_policy mutually exclusive via preprocessorFollows discussion on mailing list on 31/08/2015.
Follows discussion on mailing list on 31/08/2015.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1048Eliminate remaining randomness from estimation routines2019-06-19T15:37:54ZJohannes Pfeifer Eliminate remaining randomness from estimation routinesRelated to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7243&p=21224#p21224
There still seem to be elements where we do not make sure that estimation becomes "deterministic". For example, we only reset the seed in `metropolis_hastings_initialization` after we have initialized the chains via
```
candidate = rand_multivariate_normal( transpose(xparam1), d * options_.mh_init_scale, npar);
```
thereby introducing an element of randomness. This seems to be particularly relevant if optimizers are used that rely on random numbers.
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7243&p=21224#p21224
There still seem to be elements where we do not make sure that estimation becomes "deterministic". For example, we only reset the seed in `metropolis_hastings_initialization` after we have initialized the chains via
```
candidate = rand_multivariate_normal( transpose(xparam1), d * options_.mh_init_scale, npar);
```
thereby introducing an element of randomness. This seems to be particularly relevant if optimizers are used that rely on random numbers.
https://git.dynare.org/Dynare/dynare/-/issues/1041Save planner objective after running discretionary_policy2019-06-19T15:37:54ZJohannes Pfeifer Save planner objective after running discretionary_policyFor some reason `discretionary_policy.m` has the commented line
```
%oo_ = evaluate_planner_objective(oo_.dr,M_,oo_,options_);
```
Is there a reason we do not simply add
```
oo_.planner_objective_value = evaluate_planner_objective(M_,options_,oo_);
```
to the function to actually save the objective function value as for Ramey?
For some reason `discretionary_policy.m` has the commented line
```
%oo_ = evaluate_planner_objective(oo_.dr,M_,oo_,options_);
```
Is there a reason we do not simply add
```
oo_.planner_objective_value = evaluate_planner_objective(M_,options_,oo_);
```
to the function to actually save the objective function value as for Ramey?
https://git.dynare.org/Dynare/dynare/-/issues/1035Add option to save kernel density for posterior objects2019-06-19T15:37:54ZJohannes Pfeifer Add option to save kernel density for posterior objectsThis allows for example getting the posterior density of forecasts.
It simply requires adjusting `pm3.m` to save the objects that can already be computed via `posterior_moments`.
I would propose to call the option `posterior_kernel_density` and save it to `options_.estimation.posterior_kernel_density.indicator=1`
This allows for example getting the posterior density of forecasts.
It simply requires adjusting `pm3.m` to save the objects that can already be computed via `posterior_moments`.
I would propose to call the option `posterior_kernel_density` and save it to `options_.estimation.posterior_kernel_density.indicator=1`
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1039@#include should pull in mod files off the MATLAB path, not just the current ...2019-06-19T15:37:54ZTom Holden@#include should pull in mod files off the MATLAB path, not just the current folderTo enable @#include to be easily used with libraries of utilities e.g. https://github.com/tholden/DynareTransformationEngine , it needs to be able to include MOD files that are not in the current folder, and are instead somewhere in the MATLAB path. Copying and pasting is both messy and unreliable.
To enable @#include to be easily used with libraries of utilities e.g. https://github.com/tholden/DynareTransformationEngine , it needs to be able to include MOD files that are not in the current folder, and are instead somewhere in the MATLAB path. Copying and pasting is both messy and unreliable.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1034Add capacities for rolling window forecasts2019-06-19T15:37:54ZJohannes Pfeifer Add capacities for rolling window forecastsCurrently, we only support recursive forecasting where the time window, on which the model is estimated, expands.
Necessary steps:
1. Allow `estimation` option `first_obs` to take vector like `nobs` (with the same consistency checks)
2. Adjust `dynare_estimation` to not either set `options_.nobs = nobs(i);` or `options_.first_obs=first_obs(i)` and add check that makes them mutually exclusive.
The only problem is returning the results. Currently, `dynare_estimation` returns `oo_recursive`. We can either store the rolling window estimation in the same structure or let the preprocessor assign the results to either `oo_recursive` or `oo_rolling` depending on whether `nobs` or `first_obs` is more than a scalar. In this case, the preprocessor must also do the check that either rolling or recursive estimation can be requested, but not both.
Currently, we only support recursive forecasting where the time window, on which the model is estimated, expands.
Necessary steps:
1. Allow `estimation` option `first_obs` to take vector like `nobs` (with the same consistency checks)
2. Adjust `dynare_estimation` to not either set `options_.nobs = nobs(i);` or `options_.first_obs=first_obs(i)` and add check that makes them mutually exclusive.
The only problem is returning the results. Currently, `dynare_estimation` returns `oo_recursive`. We can either store the rolling window estimation in the same structure or let the preprocessor assign the results to either `oo_recursive` or `oo_rolling` depending on whether `nobs` or `first_obs` is more than a scalar. In this case, the preprocessor must also do the check that either rolling or recursive estimation can be requested, but not both.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1033typo in dsge_likelihood.m2019-06-19T15:37:56ZTom Holdentypo in dsge_likelihood.mLines 366 and 480 of dsge_likelihood.m are as follows:
```
switch DynareOptions.lik_init
...
case options_.lik_init == 5 % Old diffuse Kalman filter only for the non stationary variables
```
I presume the `options_.lik_init ==` should not be there? `options_` is no longer even defined in DsgeLikelihood.m, so if none of the previous cases have been matched, a MATLAB error will be generated when MATLAB attempts to access a field of the non-existent structure.
Lines 366 and 480 of dsge_likelihood.m are as follows:
```
switch DynareOptions.lik_init
...
case options_.lik_init == 5 % Old diffuse Kalman filter only for the non stationary variables
```
I presume the `options_.lik_init ==` should not be there? `options_` is no longer even defined in DsgeLikelihood.m, so if none of the previous cases have been matched, a MATLAB error will be generated when MATLAB attempts to access a field of the non-existent structure.
https://git.dynare.org/Dynare/dynare/-/issues/1028Transform M_.aux_vars.eq_nbr from char to double2019-06-19T15:37:56ZJohannes Pfeifer Transform M_.aux_vars.eq_nbr from char to doubleFor some reason, the equation number is stored by the preprocessor as a character, leading to problems in `display_problematic_vars_Jacobian.m`
For some reason, the equation number is stored by the preprocessor as a character, leading to problems in `display_problematic_vars_Jacobian.m`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1026Investigate memory issue of k_order dll (Dynare++)2019-06-19T15:37:56ZJohannes Pfeifer Investigate memory issue of k_order dll (Dynare++)See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7155. Even with 32GB RAM, it crashes with
`terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc`
which seems weird. This may also be related to #612
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7155. Even with 32GB RAM, it crashes with
`terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc`
which seems weird. This may also be related to #612
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1024Save posterior moments even when moments are constant2019-06-19T15:37:56ZJohannes Pfeifer Save posterior moments even when moments are constantIn `covariance_mc_analysis.m` and the like we test whether the moments are constant and, if yes, we store NaN. I don't see the logic of this. All moments are still well-defined (although identical). I would propose to get rid of this check and always store the computed moments.
In `covariance_mc_analysis.m` and the like we test whether the moments are constant and, if yes, we store NaN. I don't see the logic of this. All moments are still well-defined (although identical). I would propose to get rid of this check and always store the computed moments.
https://git.dynare.org/Dynare/dynare/-/issues/1021Check correctness of DSGE-VAR Wiki2019-06-19T15:37:56ZJohannes Pfeifer Check correctness of DSGE-VAR WikiAccording to Del Negro/Schorfheide (2004), the variance priors and posteriors have degrees of freedom correction with number of estimated parameters in the VAR equation, i.e. variables times lags plus a constant:
```
m*p+1
```
However, http://www.dynare.org/DynareWiki/DsgeVar does not feature a constant in the description, but still uses the same initial improper prior with `m+1` as if a constant would be used (below eqation (21) in DNS (2004)).
Similarly, equations P2 and Q2 of the Wiki use a correction of `-mp-m=-m*(p+1)` suggesting a constant for every variable in each equation.
While the condition for `lambda*T<m(p+1)` coincides with the one below equation (21) in DNS (2004), there is no formal derivation of this condition in DNS . The Wiki motivates this statement by alluding to the fact that we could not use OLS to estimate the equation if `T<m(p+1)`. But this again looks strange as the number of parameters estimated is just `m*p+1`.
According to Del Negro/Schorfheide (2004), the variance priors and posteriors have degrees of freedom correction with number of estimated parameters in the VAR equation, i.e. variables times lags plus a constant:
```
m*p+1
```
However, http://www.dynare.org/DynareWiki/DsgeVar does not feature a constant in the description, but still uses the same initial improper prior with `m+1` as if a constant would be used (below eqation (21) in DNS (2004)).
Similarly, equations P2 and Q2 of the Wiki use a correction of `-mp-m=-m*(p+1)` suggesting a constant for every variable in each equation.
While the condition for `lambda*T<m(p+1)` coincides with the one below equation (21) in DNS (2004), there is no formal derivation of this condition in DNS . The Wiki motivates this statement by alluding to the fact that we could not use OLS to estimate the equation if `T<m(p+1)`. But this again looks strange as the number of parameters estimated is just `m*p+1`.
https://git.dynare.org/Dynare/dynare/-/issues/1018fix test suite bugs2019-06-19T15:37:56ZHoutan Bastanifix test suite bugsIn email of 6/8/2015 on the dev list, @JohannesPfeifer reported dependencies of the test suite that don't make sense. fix these
In email of 6/8/2015 on the dev list, @JohannesPfeifer reported dependencies of the test suite that don't make sense. fix these
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.eu