dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:38:08Zhttps://git.dynare.org/Dynare/dynare/issues/667rename hessian.m in dyn_hessian.m2019-06-19T15:38:08ZMichelJuillardrename hessian.m in dyn_hessian.mIn order to avoid name collision with other Matlab program/toolboxe
In order to avoid name collision with other Matlab program/toolboxe
4.5https://git.dynare.org/Dynare/dynare/issues/669fullpage LaTeX package causes compilation to break on Windows (is output by w...2019-06-19T15:38:08ZHoutan Bastanifullpage LaTeX package causes compilation to break on Windows (is output by write_latex_dynamic_model)Try to repeat error and find a work around if indeed it is not distributed with MikTex
Try to repeat error and find a work around if indeed it is not distributed with MikTex
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/670Fix handling of prefiltering and trends in non_linear_dsge_likelihood2019-06-19T15:38:08ZJohannes Pfeifer Fix handling of prefiltering and trends in non_linear_dsge_likelihood`non_linear_dsge_likelihood` uses
`Y = transpose(DynareDataset.rawdata);`
By accessing `rawdata` instead of data, prefiltering is ignored. Moreover, deterministic trends are not subtracted. I am not sure this is on purpose.
`non_linear_dsge_likelihood` uses
`Y = transpose(DynareDataset.rawdata);`
By accessing `rawdata` instead of data, prefiltering is ignored. Moreover, deterministic trends are not subtracted. I am not sure this is on purpose.
4.5https://git.dynare.org/Dynare/dynare/issues/671misc changes to dates/dseries2019-06-19T15:38:08ZHoutan Bastanimisc changes to dates/dseries- dates: rename `time` field to something more descriptive. Perhaps `data`
- dates: remove `ndat` field. Should have method that provides this information instead
- dseries: remove `nobs` field. Should have method that provides this information instead
- dseries: remove `vobs` field. Should have method that provides this information instead
- dates: rename `time` field to something more descriptive. Perhaps `data`
- dates: remove `ndat` field. Should have method that provides this information instead
- dseries: remove `nobs` field. Should have method that provides this information instead
- dseries: remove `vobs` field. Should have method that provides this information instead
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/672Use pgfplotstable for report tables instead of latex tables2019-06-19T15:38:08ZHoutan BastaniUse pgfplotstable for report tables instead of latex tablesBefore making the change, ensure it's distributed in MikTex
http://pgfplots.sourceforge.net/pgfplotstable.pdf
Before making the change, ensure it's distributed in MikTex
http://pgfplots.sourceforge.net/pgfplotstable.pdf
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/673when creating a report with only one table, tmpRepDir is not created and it c...2019-06-19T15:38:08ZHoutan Bastaniwhen creating a report with only one table, tmpRepDir is not created and it crashesSee Eleonora's email from 18h30 27/6/2014
See Eleonora's email from 18h30 27/6/2014
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/675Fix bug in dsge_likelihood related to analytic_derivation2019-06-19T15:38:08ZJohannes Pfeifer Fix bug in dsge_likelihood related to analytic_derivationSee http://www.dynare.org/pipermail/dev/2014-May/003793.html
See http://www.dynare.org/pipermail/dev/2014-May/003793.html
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/677Deal with treatment of unit roots in identification2019-06-19T15:38:08ZJohannes Pfeifer Deal with treatment of unit roots in identification```
var y delta_y x z;
varexo eps_x eps_z;
parameters rho sigma_z sigma_x;
// set parameter values
sigma_z=0.001;
sigma_x=0.01;
rho=0.9;
model;
z=rho*z(-1)+sigma_z*eps_z;
x=x(-1)+sigma_x*eps_x;
y=x+z;
delta_y=y-y(-1);
end;
steady_state_model;
x=0;
z=0;
y=0;
delta_y=0;
end;
//set shock variances
shocks;
var eps_z=1;
var eps_x=1;
end;
steady;
check;
varobs y delta_y;
stoch_simul(order=1,irf=0);
estimated_params;
rho, 0.9;
sigma_z, 0.01;
sigma_x, 0.01;
end;
options_.diffuse_filter=1;
identification(lik_init=3,advanced=1);
```
The treatment of unit roots seems unsatisfactory.
First, one needs to specify
`options_.diffuse_filter=1;`
because `options_` used in `dynare_estimation_init` does not inherit the `lik_init` from the `identification` command (used only in `options_ident`) and also does not accept `diffuse_filter`.
Second, some graphs are empty. My guess is because some unconditional moments are infinite.
```
var y delta_y x z;
varexo eps_x eps_z;
parameters rho sigma_z sigma_x;
// set parameter values
sigma_z=0.001;
sigma_x=0.01;
rho=0.9;
model;
z=rho*z(-1)+sigma_z*eps_z;
x=x(-1)+sigma_x*eps_x;
y=x+z;
delta_y=y-y(-1);
end;
steady_state_model;
x=0;
z=0;
y=0;
delta_y=0;
end;
//set shock variances
shocks;
var eps_z=1;
var eps_x=1;
end;
steady;
check;
varobs y delta_y;
stoch_simul(order=1,irf=0);
estimated_params;
rho, 0.9;
sigma_z, 0.01;
sigma_x, 0.01;
end;
options_.diffuse_filter=1;
identification(lik_init=3,advanced=1);
```
The treatment of unit roots seems unsatisfactory.
First, one needs to specify
`options_.diffuse_filter=1;`
because `options_` used in `dynare_estimation_init` does not inherit the `lik_init` from the `identification` command (used only in `options_ident`) and also does not accept `diffuse_filter`.
Second, some graphs are empty. My guess is because some unconditional moments are infinite.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/676Fix compatibility of sensitivity and ML estimation2019-06-19T15:38:08ZJohannes Pfeifer Fix compatibility of sensitivity and ML estimationSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5681
Email to Marco:
```
There is an obvious bug in set_shocks_param.m. Sigma_e_ should be just Sigma_e. But there seems to be more. In stab_map_.m in
if pprior,
for j=1:nshock,
if opt_gsa.morris~=1,
lpmat0(:,j) = randperm(Nsam)'./(Nsam+1); %latin hypercube
end
if opt_gsa.prior_range
lpmat0(:,j)=lpmat0(:,j).*(bayestopt_.ub(j)-bayestopt_.lb(j))+bayestopt_.lb(j);
end
end
bayestopt_.ub and lb are accessed and they are Inf. lpmat0 then has a bunch of NaNs that should not be there. This seems to be due to ML estimation and should probably be filtered out.
```
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5681
Email to Marco:
```
There is an obvious bug in set_shocks_param.m. Sigma_e_ should be just Sigma_e. But there seems to be more. In stab_map_.m in
if pprior,
for j=1:nshock,
if opt_gsa.morris~=1,
lpmat0(:,j) = randperm(Nsam)'./(Nsam+1); %latin hypercube
end
if opt_gsa.prior_range
lpmat0(:,j)=lpmat0(:,j).*(bayestopt_.ub(j)-bayestopt_.lb(j))+bayestopt_.lb(j);
end
end
bayestopt_.ub and lb are accessed and they are Inf. lpmat0 then has a bunch of NaNs that should not be there. This seems to be due to ML estimation and should probably be filtered out.
```
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/678Use of the derivative of an external function directly in the model crashes t...2019-06-19T15:38:08ZJohannes Pfeifer Use of the derivative of an external function directly in the model crashes the preprocessorSee email to @sebastien-villemot on June 9th, 2014
See email to @sebastien-villemot on June 9th, 2014
4.5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/680Clarify license of LMMCP2019-06-19T15:38:08ZSébastien VillemotClarify license of LMMCPThe license of `matlab/lmmcp/lmmcp.m` and `matlab/lmmcp/catstruct.m` is unclear.
Once clarified, it should be documented in `license.txt`.
The license of `matlab/lmmcp/lmmcp.m` and `matlab/lmmcp/catstruct.m` is unclear.
Once clarified, it should be documented in `license.txt`.
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/681Improve model_comparison2019-06-19T15:38:06ZJohannes Pfeifer Improve model_comparison1. Currently, the default for the prior odds if not specified is a probability of 1 for all models, which is improper. We should change this to 1/Number of models to be compared. The default should also be more clearly documented in the manual
2. Model_comparison should provide a warning when only ML was used. The manual should also clarify that this is only possible with Bayesian estimation
3. We might want to allow for likelihood ratio tests for nested models in case of ML
1. Currently, the default for the prior odds if not specified is a probability of 1 for all models, which is improper. We should change this to 1/Number of models to be compared. The default should also be more clearly documented in the manual
2. Model_comparison should provide a warning when only ML was used. The manual should also clarify that this is only possible with Bayesian estimation
3. We might want to allow for likelihood ratio tests for nested models in case of ML
https://git.dynare.org/Dynare/dynare/issues/679Fix various bugs related to detrending and prefiltering2019-06-19T15:38:06ZJohannes Pfeifer Fix various bugs related to detrending and prefiltering- `dyn_forecast` adds unlogged steady state if `loglinear` is used
- `dynare_estimation_init` sets the `noconstant` based on the unlogged steady state if `loglinear` is used
- when trends are specified as a function of deep parameters, the values are not correctly updated during estimation due to using the base-workspace parameter values and not the updated local ones
- when using trends with the `prefilter` option, the mean shift due to the trend is not accounted for
- when using `first_obs>1`, the higher trend starting point is not taken into account (leads also to problems in recursive forecasting)
- `dyn_forecast` adds unlogged steady state if `loglinear` is used
- `dynare_estimation_init` sets the `noconstant` based on the unlogged steady state if `loglinear` is used
- when trends are specified as a function of deep parameters, the values are not correctly updated during estimation due to using the base-workspace parameter values and not the updated local ones
- when using trends with the `prefilter` option, the mean shift due to the trend is not accounted for
- when using `first_obs>1`, the higher trend starting point is not taken into account (leads also to problems in recursive forecasting)
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/686addition bug in dseries2019-06-19T15:38:06ZHoutan Bastaniaddition bug in dseries```
>> a=dseries(ones(3,1))
>> 100-a
```
yields -99 as opposed to 99.
```
>> a=dseries(ones(3,1))
>> 100-a
```
yields -99 as opposed to 99.
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/687update manual for common latex syntax in reports2019-06-19T15:38:06ZHoutan Bastaniupdate manual for common latex syntax in reportse.g. people may want to use a '%' sign in a graph title. Note the fix for this. Also for '\'
e.g. people may want to use a '%' sign in a graph title. Note the fix for this. Also for '\'
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/684Add test and documentation for LMMCP solver2019-06-19T15:38:06ZSébastien VillemotAdd test and documentation for LMMCP solver4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/688add option to suppress all reporting stdout output2019-06-19T15:38:06ZHoutan Bastaniadd option to suppress all reporting stdout outputi.e., suppress:
Adding Page X
Writing Page X
Compiler Output
Where the file is located
i.e., suppress:
Adding Page X
Writing Page X
Compiler Output
Where the file is located
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/694create fortran preprocessor output2019-06-19T15:38:06ZHoutan Bastanicreate fortran preprocessor outputdynamic and static files each as independent functions
model as a fortran module
dynamic and static files each as independent functions
model as a fortran module
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/695Ramsey: fix M_.aux_vars2019-06-19T15:38:06ZJohannes Pfeifer Ramsey: fix M_.aux_varsIn case of the Ramsey multipliers, the counting of equation numbers starts at 0, but should start at 1
In case of the Ramsey multipliers, the counting of equation numbers starts at 0, but should start at 1
4.5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/690Crash of k_order_perturbation DLL under MATLAB/Windows2019-06-19T15:38:06ZSébastien VillemotCrash of k_order_perturbation DLL under MATLAB/WindowsThe following MOD-file crashes MATLAB under Windows:
```
var y, c, k, a, h, b;
varexo e, u;
parameters beta, rho, alpha, delta, theta, psi, tau;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 0.99;
delta = 0.025;
psi = 0;
theta = 2.95;
phi = 0.1;
model;
c*theta*h^(1+psi)=(1-alpha)*y;
k = beta*(((exp(b)*c)/(exp(b(+1))*c(+1)))
*(exp(b(+1))*alpha*y(+1)+(1-delta)*k));
y = exp(a)*(k(-1)^alpha)*(h^(1-alpha));
k = exp(b)*(y-c)+(1-delta)*k(-1);
a = rho*a(-1)+tau*b(-1) + e;
b = tau*a(-1)+rho*b(-1) + u;
end;
initval;
y = 1.08068253095672;
c = 0.80359242014163;
h = 0.29175631001732;
k = 11.08360443260358;
a = 0;
b = 0;
e = 0;
u = 0;
end;
shocks;
var e; stderr 0.009;
var u; stderr 0.009;
var e, u = phi*0.009*0.009;
end;
stoch_simul(order=3,periods=100);
```
The crash only occurs under MATLAB+Windows. It does not occur on Octave or under GNU/Linux.
It seems to be a memory corruption, because MATLAB does not crash immediately within the MEX file, but a little after. However, under Linux, a Valgrind run reveals nothing suspicious. A gdb session under Windows is not helpful either.
Still to be tried:
- convert the MOD file for Dynare++, and see if it crashes
- investigate the MEX file by selectively commenting out/in portions of the code, to detect which one causes the memory corruption
The following MOD-file crashes MATLAB under Windows:
```
var y, c, k, a, h, b;
varexo e, u;
parameters beta, rho, alpha, delta, theta, psi, tau;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 0.99;
delta = 0.025;
psi = 0;
theta = 2.95;
phi = 0.1;
model;
c*theta*h^(1+psi)=(1-alpha)*y;
k = beta*(((exp(b)*c)/(exp(b(+1))*c(+1)))
*(exp(b(+1))*alpha*y(+1)+(1-delta)*k));
y = exp(a)*(k(-1)^alpha)*(h^(1-alpha));
k = exp(b)*(y-c)+(1-delta)*k(-1);
a = rho*a(-1)+tau*b(-1) + e;
b = tau*a(-1)+rho*b(-1) + u;
end;
initval;
y = 1.08068253095672;
c = 0.80359242014163;
h = 0.29175631001732;
k = 11.08360443260358;
a = 0;
b = 0;
e = 0;
u = 0;
end;
shocks;
var e; stderr 0.009;
var u; stderr 0.009;
var e, u = phi*0.009*0.009;
end;
stoch_simul(order=3,periods=100);
```
The crash only occurs under MATLAB+Windows. It does not occur on Octave or under GNU/Linux.
It seems to be a memory corruption, because MATLAB does not crash immediately within the MEX file, but a little after. However, under Linux, a Valgrind run reveals nothing suspicious. A gdb session under Windows is not helpful either.
Still to be tried:
- convert the MOD file for Dynare++, and see if it crashes
- investigate the MEX file by selectively commenting out/in portions of the code, to detect which one causes the memory corruption
4.5Sébastien VillemotSébastien Villemot