dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-10-30T07:48:37Zhttps://git.dynare.org/Dynare/dynare/issues/1663datafile option in perfect_foresight_setup: incomplete documentation and not ...2019-10-30T07:48:37ZMichelJuillarddatafile option in perfect_foresight_setup: incomplete documentation and not flexible enoughthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [ ] make loading data for guess value more flexible
- [ ] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-modelthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [ ] make loading data for guess value more flexible
- [ ] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-model4.6https://git.dynare.org/Dynare/dynare/issues/1661`fast` option to dynare does not recompile every time the model changes2019-10-08T07:17:30ZHoutan Bastani`fast` option to dynare does not recompile every time the model changesThe temporary terms of the equations are not printed in the buffer on which the checksum is calculated. Hence, if the model is changed in a term that then becomes a temporary term, the checksum does not change.The temporary terms of the equations are not printed in the buffer on which the checksum is calculated. Hence, if the model is changed in a term that then becomes a temporary term, the checksum does not change.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1660Update documentation of dseries2019-09-26T12:37:39ZSébastien VillemotUpdate documentation of dseriesSince dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.Since dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.4.6Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1659Filter out non-positive definite Hessians before Laplace approximation2019-09-24T19:55:14ZJohannes Pfeifer Filter out non-positive definite Hessians before Laplace approximationWe do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.We do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.4.6https://git.dynare.org/Dynare/dynare/issues/1657add shock decomposition for forecasts done after estimation2019-11-13T14:54:28ZSébastien Villemotadd shock decomposition for forecasts done after estimation@MichelJuillard has some preliminary codes.@MichelJuillard has some preliminary codes.4.6https://git.dynare.org/Dynare/dynare/issues/1656Provide documentation and compatibility layers for the upgrading to 4.62019-09-30T09:09:02ZSébastien VillemotProvide documentation and compatibility layers for the upgrading to 4.6Between 4.5 and 4.6, many structures in `M_`, `options_` and elsewhere which used to be character vectors are now cell arrays.
We need to compile the list of all those structures, and document that change in the release notes.
Also, we need to provide a compatibility layer and/or some tips on how to adapt existing code.
The function `convert_oo.m` should also be updated, and moved alongside `convert_dyn_45_to_44.m` to the new subfolder for compatibility layers.Between 4.5 and 4.6, many structures in `M_`, `options_` and elsewhere which used to be character vectors are now cell arrays.
We need to compile the list of all those structures, and document that change in the release notes.
Also, we need to provide a compatibility layer and/or some tips on how to adapt existing code.
The function `convert_oo.m` should also be updated, and moved alongside `convert_dyn_45_to_44.m` to the new subfolder for compatibility layers.4.6https://git.dynare.org/Dynare/dynare/issues/1655Move created LaTeX-files to subfolder2019-07-12T10:11:09ZJohannes Pfeifer Move created LaTeX-files to subfolderSee https://git.dynare.org/Dynare/preprocessor/commit/0988a1f755be01b00aab7a458c89d9b63800875d#note_8528See https://git.dynare.org/Dynare/preprocessor/commit/0988a1f755be01b00aab7a458c89d9b63800875d#note_85284.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1652Crash in bytecode2019-07-05T12:17:44ZSébastien VillemotCrash in bytecodeI attach an example ([surprise_solution.zip](/uploads/17158ceefc6fbf59f6810d17cbcdc084/surprise_solution.zip)) that crashes bytecode (just by running `surprise_solution_2019_05_20.mod`).
The problem can be reproduced both with unstable and 4.5.
*Note:* comes from https://forum.dynare.org/t/matlab-shutdown-deterministic-solution-stack-solve-algo-1/13882I attach an example ([surprise_solution.zip](/uploads/17158ceefc6fbf59f6810d17cbcdc084/surprise_solution.zip)) that crashes bytecode (just by running `surprise_solution_2019_05_20.mod`).
The problem can be reproduced both with unstable and 4.5.
*Note:* comes from https://forum.dynare.org/t/matlab-shutdown-deterministic-solution-stack-solve-algo-1/138824.6FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/issues/1651dynare_sensitivity without exogenous variables2019-09-10T09:27:19Zrobvanharreveltdynare_sensitivity without exogenous variablesWhen `dynare_sensitivity` is used for a model without exogenous variables, the following error occurs:
```
Reference to non-existent field 'ghu'.
Error in kalman_transition_matrix (line 42)
B = dr.ghu(iv,:);
```
See the attached file [test1.mod](/uploads/2c7fa958781bb4ea203ecb1d484c9c8d/test1.mod). An easy workaround is to create a dummy exogenous variable (see attached file [test2.mod](/uploads/31ea2681c8f6b2701ed9da63e39c8968/test2.mod)), but it would help if the error message explains that the code does not work for models without exogenous variables.
This issue is similar to issue https://git.dynare.org/Dynare/dynare/issues/1633.When `dynare_sensitivity` is used for a model without exogenous variables, the following error occurs:
```
Reference to non-existent field 'ghu'.
Error in kalman_transition_matrix (line 42)
B = dr.ghu(iv,:);
```
See the attached file [test1.mod](/uploads/2c7fa958781bb4ea203ecb1d484c9c8d/test1.mod). An easy workaround is to create a dummy exogenous variable (see attached file [test2.mod](/uploads/31ea2681c8f6b2701ed9da63e39c8968/test2.mod)), but it would help if the error message explains that the code does not work for models without exogenous variables.
This issue is similar to issue https://git.dynare.org/Dynare/dynare/issues/1633.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1650allow to associate initial conditions to shocks in shocks grouping for shock ...2019-07-06T12:37:31ZMarco Rattoallow to associate initial conditions to shocks in shocks grouping for shock decomposition plotsIt would be useful to have an interface for a command like `init2shocks`, which accepts couples of names. first an endo name, second a shock name
```
init2shocks;
endoname1 exoname1;
endoname2 exoname1;
endoname3 exoname2;
...
;
```
there can be multiple endo names for one exo, but NOT viceversa.
The preprocessor should translate this into a cell matrix as follows:
```
M_.init2shocks = {
'endoname1','exoname1';
'endoname2','exoname1';
'endoname3','exoname2';
};
```
default will be: `M_.init2shocks = {};`
Then we need a new option `init2shocks` for `plot_shock_decomposition(init2shocks)`. If it is called, the preprocessor will trigger
```
options_.plot_shock_decomp.init2shocks = M_.init2shocks;
```
otherwise it should be empty (by default).
```
options_.plot_shock_decomp.init2shocks =[];
```
with this definitions, plot_shock_decompo will attribute the initial condition effect of endo variables to the shock/shock group.It would be useful to have an interface for a command like `init2shocks`, which accepts couples of names. first an endo name, second a shock name
```
init2shocks;
endoname1 exoname1;
endoname2 exoname1;
endoname3 exoname2;
...
;
```
there can be multiple endo names for one exo, but NOT viceversa.
The preprocessor should translate this into a cell matrix as follows:
```
M_.init2shocks = {
'endoname1','exoname1';
'endoname2','exoname1';
'endoname3','exoname2';
};
```
default will be: `M_.init2shocks = {};`
Then we need a new option `init2shocks` for `plot_shock_decomposition(init2shocks)`. If it is called, the preprocessor will trigger
```
options_.plot_shock_decomp.init2shocks = M_.init2shocks;
```
otherwise it should be empty (by default).
```
options_.plot_shock_decomp.init2shocks =[];
```
with this definitions, plot_shock_decompo will attribute the initial condition effect of endo variables to the shock/shock group.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1649new plot_shock_decomposition options2019-07-05T15:55:53ZMarco Rattonew plot_shock_decomposition optionsIt would be useful to allow the preprocessor to take the following new options, both for `plot_shock_decomposition` and `initial_condition_decomposition`:
* `diff`: plots the first difference of the requested variable
* `flip`: flip the requested variables with sign change (e.g. useful to flip the concept of an exchange rate or trade balance or deficit/surplus variable without having to define it in model definition)
I have already provisions ready to push.It would be useful to allow the preprocessor to take the following new options, both for `plot_shock_decomposition` and `initial_condition_decomposition`:
* `diff`: plots the first difference of the requested variable
* `flip`: flip the requested variables with sign change (e.g. useful to flip the concept of an exchange rate or trade balance or deficit/surplus variable without having to define it in model definition)
I have already provisions ready to push.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1648Store info on deflator growth factor in M_ for each endo variables2019-08-20T10:56:08ZMarco RattoStore info on deflator growth factor in M_ for each endo variablesAssume we define a model with trend variables:
```
trend_var(growth_factor = exp(GYTREND0)) YTREND0;
trend_var(growth_factor = exp(GP0)) PY0;
// real variable
var (deflator=YTREND0) Y;
// price index
var (deflator=PY0) PY;
// nominal variable
var (deflator=YTREND0*PY0) YN;
```
It would be extremely useful if we had trace in `M_` of the preprocessed trends, e.g. similarly to name/long_name, there could be a cell list M_.endo_growth_factor, which would contain for the above example:
```
M_.endo_growth_factor(1) = {'exp(GYTREND0)'};
M_.endo_growth_factor(2) = {'exp(GP0)'}
M_.endo_growth_factor(3) = {'exp(GYTREND0)*exp(GP0)'};
```
for variables not trending it would be:
```
M_.endo_growth_factor(4) = {'1'};
```Assume we define a model with trend variables:
```
trend_var(growth_factor = exp(GYTREND0)) YTREND0;
trend_var(growth_factor = exp(GP0)) PY0;
// real variable
var (deflator=YTREND0) Y;
// price index
var (deflator=PY0) PY;
// nominal variable
var (deflator=YTREND0*PY0) YN;
```
It would be extremely useful if we had trace in `M_` of the preprocessed trends, e.g. similarly to name/long_name, there could be a cell list M_.endo_growth_factor, which would contain for the above example:
```
M_.endo_growth_factor(1) = {'exp(GYTREND0)'};
M_.endo_growth_factor(2) = {'exp(GP0)'}
M_.endo_growth_factor(3) = {'exp(GYTREND0)*exp(GP0)'};
```
for variables not trending it would be:
```
M_.endo_growth_factor(4) = {'1'};
```4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1647Add silent mode to perfect foresight simulations2019-09-12T12:50:55ZJohannes Pfeifer Add silent mode to perfect foresight simulationsSee https://forum.dynare.org/t/supressing-output-in-steady-and-simul-commands/13916See https://forum.dynare.org/t/supressing-output-in-steady-and-simul-commands/139164.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1646Save var_list_ used in stoch_simul to oo_2019-09-12T13:07:50ZJohannes Pfeifer Save var_list_ used in stoch_simul to oo_If variables are selected after `stoch_simul`, fields like `oo_.var` will be matrices of the dimension of `var_list_`. But the info on `var_list_` is not stored. So if one loads results from a `_results.mat`-file, there is no way to recover to which variables the entries in `oo_.var` belong.
The question is how to store this info as one can have several different `stoch_simul`-commands in a mod-file.If variables are selected after `stoch_simul`, fields like `oo_.var` will be matrices of the dimension of `var_list_`. But the info on `var_list_` is not stored. So if one loads results from a `_results.mat`-file, there is no way to recover to which variables the entries in `oo_.var` belong.
The question is how to store this info as one can have several different `stoch_simul`-commands in a mod-file.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1641Fix dyn_first_order_solver for models without lagged variables2019-03-08T16:51:44ZJohannes Pfeifer Fix dyn_first_order_solver for models without lagged variablesThe model
```
// Declare variables
var y r k b tax agov wage gama s cf cs;
// Declare parameter values
parameters cbeta cdelta cphi ctheta cn ca cd cb ct da ft;
cbeta=0.98;
cdelta=5;
cphi=0.2058;
cn=1;
ctheta=0.2;
ca=0.3;
cd=0.97;
cb=0.09;
ct=0.05;
ft=0.1;
da=2;
// predetermined_variables k;
model;
y= da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
gama(+1)=cn*(cd+cphi*agov^ca)*k(+1)^ctheta/k^ctheta;
tax=ct*wage+ft*r*(b+k);
b(+1)*cn*(cd+cphi*agov^ca)=agov+r*b-tax;
s=wage*(1-ct)*cbeta^cdelta*(r*(1-ft))^(cdelta-1)/(1+cbeta^cdelta*(r*(1-ft))^(cdelta-1));
k(+1)+b(+1)=s/(cn*(cd+cphi*agov^ca));
b=cb*y;
cf=wage*(1-ct)/(1+cbeta^(-cdelta)*(r*(1-ft))^(1-cdelta));
cs=wage*(1-ct)*(cbeta*r*(1-ft))^(1-cdelta)/(1+cbeta^(0-cdelta)*(r*(1-ft))^(1-cdelta));
end;
initval;
k =0.1;
y = da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
b =cb*y;
tax =ct*wage;
agov =0.1;
s=(wage-tax)*cbeta^cdelta*r^(cdelta-1)/(1+cbeta^cdelta*r^(cdelta-1));
end;
steady;
// check;
stoch_simul(order=1);
```
crashes `dyn_first_order_solver` due to non-conformable matrix dimensions in ` E(row_indx_de_1,index_e1) = -aa(row_indx,index_e);`
Setting the predetermined variables correctly solves the issue.The model
```
// Declare variables
var y r k b tax agov wage gama s cf cs;
// Declare parameter values
parameters cbeta cdelta cphi ctheta cn ca cd cb ct da ft;
cbeta=0.98;
cdelta=5;
cphi=0.2058;
cn=1;
ctheta=0.2;
ca=0.3;
cd=0.97;
cb=0.09;
ct=0.05;
ft=0.1;
da=2;
// predetermined_variables k;
model;
y= da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
gama(+1)=cn*(cd+cphi*agov^ca)*k(+1)^ctheta/k^ctheta;
tax=ct*wage+ft*r*(b+k);
b(+1)*cn*(cd+cphi*agov^ca)=agov+r*b-tax;
s=wage*(1-ct)*cbeta^cdelta*(r*(1-ft))^(cdelta-1)/(1+cbeta^cdelta*(r*(1-ft))^(cdelta-1));
k(+1)+b(+1)=s/(cn*(cd+cphi*agov^ca));
b=cb*y;
cf=wage*(1-ct)/(1+cbeta^(-cdelta)*(r*(1-ft))^(1-cdelta));
cs=wage*(1-ct)*(cbeta*r*(1-ft))^(1-cdelta)/(1+cbeta^(0-cdelta)*(r*(1-ft))^(1-cdelta));
end;
initval;
k =0.1;
y = da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
b =cb*y;
tax =ct*wage;
agov =0.1;
s=(wage-tax)*cbeta^cdelta*r^(cdelta-1)/(1+cbeta^cdelta*r^(cdelta-1));
end;
steady;
// check;
stoch_simul(order=1);
```
crashes `dyn_first_order_solver` due to non-conformable matrix dimensions in ` E(row_indx_de_1,index_e1) = -aa(row_indx,index_e);`
Setting the predetermined variables correctly solves the issue.4.6https://git.dynare.org/Dynare/dynare/issues/1639Add the possibility to use Matlab's namespace in model block2019-10-09T14:43:41ZStéphane Adjemianstepan@dynare.orgAdd the possibility to use Matlab's namespace in model block... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1636Fix infinite loop in mr_hessian2019-02-05T17:03:42ZJohannes Pfeifer Fix infinite loop in mr_hessian@rattoma `mr_hessian` contains the loop
```
while (fx-f0)==0
hess_info.h1(i)= hess_info.h1(i)*2;
xh1(i)=x(i)+hess_info.h1(i);
[fx,exit_flag,ffx]=penalty_objective_function(xh1,func,penalty,varargin{:});
ic=1;
end
```
That loop does not have a proper termination criterion. I have a mod-file where `hess_info.h1(i)` becomes 0 so that it is always true that `fx=f0`. So either we condition on `ic` also being smaller than a particlar number, or we need to check that `hess_info.h1(i)*2` is not 0.@rattoma `mr_hessian` contains the loop
```
while (fx-f0)==0
hess_info.h1(i)= hess_info.h1(i)*2;
xh1(i)=x(i)+hess_info.h1(i);
[fx,exit_flag,ffx]=penalty_objective_function(xh1,func,penalty,varargin{:});
ic=1;
end
```
That loop does not have a proper termination criterion. I have a mod-file where `hess_info.h1(i)` becomes 0 so that it is always true that `fx=f0`. So either we condition on `ic` also being smaller than a particlar number, or we need to check that `hess_info.h1(i)*2` is not 0.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1634Bug in positive/negative IRFs in Dynare++2019-02-05T20:00:07ZJohannes Pfeifer Bug in positive/negative IRFs in Dynare++See
https://forum.dynare.org/t/asymmetric-irfs-at-first-order-in-dynare/12246/4
The issue seems to have not yet been solved.See
https://forum.dynare.org/t/asymmetric-irfs-at-first-order-in-dynare/12246/4
The issue seems to have not yet been solved.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1633Filter out cases where stochastic simulation is run with no shocks2019-09-10T08:47:48ZJohannes Pfeifer Filter out cases where stochastic simulation is run with no shocksWhen using `stoch_simul` without varexo, a cryptic error message will appear. See https://forum.dynare.org/t/how-to-compute-the-decision-rule-matrix-oo-dr-ghx-of-a-deterministic-model/13095
We should provide an informative message, potentially at the level of the preprocessor.When using `stoch_simul` without varexo, a cryptic error message will appear. See https://forum.dynare.org/t/how-to-compute-the-decision-rule-matrix-oo-dr-ghx-of-a-deterministic-model/13095
We should provide an informative message, potentially at the level of the preprocessor.4.6https://git.dynare.org/Dynare/dynare/issues/1631Fix calls to dynamic routines in identification2019-01-09T14:19:54ZJohannes Pfeifer Fix calls to dynamic routines in identificationThe attached file contains a moving average process. It crashes identification in calls like
```
[residual, g1 ] = feval([M_.fname,'_dynamic'],yy0, ...
repmat(oo_.exo_steady_state',[M_.maximum_exo_lag+M_.maximum_exo_lead+1]), M_.params, ...
oo_.dr.ys, 1);
```
Here, the period number (last argument) is always set to 1 instead of presumably `M_.maximum_exo_lag+1 `.
[dsge_mada_debt1.mod](/uploads/cad3e4c1ca2f06c5f85913d13b27a715/dsge_mada_debt1.mod)The attached file contains a moving average process. It crashes identification in calls like
```
[residual, g1 ] = feval([M_.fname,'_dynamic'],yy0, ...
repmat(oo_.exo_steady_state',[M_.maximum_exo_lag+M_.maximum_exo_lead+1]), M_.params, ...
oo_.dr.ys, 1);
```
Here, the period number (last argument) is always set to 1 instead of presumably `M_.maximum_exo_lag+1 `.
[dsge_mada_debt1.mod](/uploads/cad3e4c1ca2f06c5f85913d13b27a715/dsge_mada_debt1.mod)4.6Houtan BastaniHoutan Bastani