dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-12-13T17:22:32Zhttps://git.dynare.org/Dynare/dynare/issues/1683Provide preprocessor warning that `simul` is deprecated2019-12-13T17:22:32ZJohannes Pfeifer Provide preprocessor warning that `simul` is deprecatedWe provide a preprocessor warning that `ramsey_policy` is deprecated. We should provide a similar warning if `simul` is called that the recommended syntax is `perfect_foresight_setup` and `perfect_foresight_solver`.We provide a preprocessor warning that `ramsey_policy` is deprecated. We should provide a similar warning if `simul` is called that the recommended syntax is `perfect_foresight_setup` and `perfect_foresight_solver`.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1681Model incorrectly detected as linear for ramsey_model2019-12-13T19:54:26ZJohannes Pfeifer Model incorrectly detected as linear for ramsey_modelI am experiencing trouble with `ramsey_model` in `Ramsey_Example.mod`. If I use `stoch_simul` via `dynare Ramsey_Example -DOptimal_policy=0`, then
```
M_.nonzero_hessian_eqs = [0 1 2 5 6 7 9 10 11];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
but with `ramsey_model` via `dynare Ramsey_Example`
```
M_.nonzero_hessian_eqs = [];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
So for some reason the model is detected as being linear, which it is notI am experiencing trouble with `ramsey_model` in `Ramsey_Example.mod`. If I use `stoch_simul` via `dynare Ramsey_Example -DOptimal_policy=0`, then
```
M_.nonzero_hessian_eqs = [0 1 2 5 6 7 9 10 11];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
but with `ramsey_model` via `dynare Ramsey_Example`
```
M_.nonzero_hessian_eqs = [];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
So for some reason the model is detected as being linear, which it is not4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1677Exempt Ramsey instruments from warning in steady_state_model block2019-12-12T17:22:48ZJohannes Pfeifer Exempt Ramsey instruments from warning in steady_state_model blockCurrently, we provide a preprocessor warning if a variable has not been set in a `steady_state_model`-block. E.g.
>WARNING: in the 'steady_state_model' block, variable 'R' is not assigned a value
But if the user provides an instrument (`ramsey_policy(instruments=(R))`), the steady state file needs to be conditional on this instrument. So the warning points users to a wrong "fix".Currently, we provide a preprocessor warning if a variable has not been set in a `steady_state_model`-block. E.g.
>WARNING: in the 'steady_state_model' block, variable 'R' is not assigned a value
But if the user provides an instrument (`ramsey_policy(instruments=(R))`), the steady state file needs to be conditional on this instrument. So the warning points users to a wrong "fix".4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1676Investigate macro-processor behavior related to defined() statement2019-12-10T15:53:50ZJohannes Pfeifer Investigate macro-processor behavior related to defined() statementI am running
```
@#if !defined(DEFINEDvar) || DEFINEDvar==0
@#echo "Good"
@#else
@#error "ELSE ERROR"
@#endif
```
and get
```
Macro-processing error: backtrace...
- Unknown variable DEFINEDvar
- binary operation: "macro.mod" line 1, col 29-42
- binary operation: "macro.mod" line 1, col 5-42
- @#if: "macro.mod" line 1, col 1 to line 5, col 7
```I am running
```
@#if !defined(DEFINEDvar) || DEFINEDvar==0
@#echo "Good"
@#else
@#error "ELSE ERROR"
@#endif
```
and get
```
Macro-processing error: backtrace...
- Unknown variable DEFINEDvar
- binary operation: "macro.mod" line 1, col 29-42
- binary operation: "macro.mod" line 1, col 5-42
- @#if: "macro.mod" line 1, col 1 to line 5, col 7
```4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1672conditional_forecast should save its output in oo_2019-11-29T16:11:56ZSébastien Villemotconditional_forecast should save its output in oo_Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.4.6https://git.dynare.org/Dynare/dynare/issues/1669Restore index of functions and commands in the manual2019-12-03T14:45:18ZSébastien VillemotRestore index of functions and commands in the manualIn the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.In the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1668Tighten tolerance for first iteration in solve1()2019-12-12T17:59:24ZMichelJuillardTighten tolerance for first iteration in solve1()Currently solve1() uses the same tolerance level (``tolf``) to decide to start Newton iterations or to terminate them. I suggest the the tolerance above which to start Newton iterations should be tighter.
It is mainly useful for the simulation of purely backward models. When the model is stationary, we expect the trajectory to converge asymptotically towards the steady state. This occurs as long as at least one iteration Newton takes place in each period. If the tolerance criteria is too lax, the simulation remains constant from too early a point.
**I suggest to use the square of ``tolf`` at the start of the computation**
For reference, csolve() always performs one Newton iteration. Matlab's fsolve() and lmmcp use a single tolerance level.Currently solve1() uses the same tolerance level (``tolf``) to decide to start Newton iterations or to terminate them. I suggest the the tolerance above which to start Newton iterations should be tighter.
It is mainly useful for the simulation of purely backward models. When the model is stationary, we expect the trajectory to converge asymptotically towards the steady state. This occurs as long as at least one iteration Newton takes place in each period. If the tolerance criteria is too lax, the simulation remains constant from too early a point.
**I suggest to use the square of ``tolf`` at the start of the computation**
For reference, csolve() always performs one Newton iteration. Matlab's fsolve() and lmmcp use a single tolerance level.https://git.dynare.org/Dynare/dynare/issues/1666option for tolerance value in Modified Harmonic Mean estimator2019-12-12T11:58:40ZMarco Rattooption for tolerance value in Modified Harmonic Mean estimatorcurrently there is an hard-coded threshold set to 0.01 for the relative difference between the marginal likelihood computed withing the 1st and 9th deciles.
It might be helpful to allow modifying it with an explicit option, something like:
`options_.Modified_Harmonic_Mean_Tolerance`
with default 0.01currently there is an hard-coded threshold set to 0.01 for the relative difference between the marginal likelihood computed withing the 1st and 9th deciles.
It might be helpful to allow modifying it with an explicit option, something like:
`options_.Modified_Harmonic_Mean_Tolerance`
with default 0.014.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1662Add support for linear models in perfect_foresight_problem MEX2019-11-27T13:11:54ZSébastien VillemotAdd support for linear models in perfect_foresight_problem MEXIn that case, the Jacobian needs not be recomputed for each period.In that case, the Jacobian needs not be recomputed for each period.Sébastien VillemotSébastien Villemothttps://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/1659Filter out non-positive definite Hessians before Laplace approximation2019-11-21T14:06:17ZJohannes 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.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1655Move created LaTeX-files to subfolder2019-11-21T14:15:56ZJohannes 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/1654Efficient computation of products of matrix arrays2019-07-03T10:43:38ZWilli Mutschlerwilli@mutschler.euEfficient computation of products of matrix arraysHi,
while extending the identification toolbox I often run into the need to compute a 2d matrix with a 3d array. That is, assume `A is [m x n]`, `B is [n x o x p]` and I need to compute `C(:,:,j)=A*B(:,:,j)`. Currently, I simply run a for loop (as p is dimension of parameters and hence not so large), i.e. the minimal matlab code looks like
```
for j=1:size(B,3)
C(:,:,j) = A*B(:,:,j);
end
```
Is there a more efficient way/trick to do so?Hi,
while extending the identification toolbox I often run into the need to compute a 2d matrix with a 3d array. That is, assume `A is [m x n]`, `B is [n x o x p]` and I need to compute `C(:,:,j)=A*B(:,:,j)`. Currently, I simply run a for loop (as p is dimension of parameters and hence not so large), i.e. the minimal matlab code looks like
```
for j=1:size(B,3)
C(:,:,j) = A*B(:,:,j);
end
```
Is there a more efficient way/trick to do so?https://git.dynare.org/Dynare/dynare/issues/1653kstate2019-12-13T10:34:09ZWilli Mutschlerwilli@mutschler.eukstateHi,
I was wondering if somebody can explain to me the structure of kstate? I am aware that using this is depreciated, as this is a reminiscence of old dynare versions where we did not create auxiliary variables for leads and lags greater than one, but still I find it is used in several functions dealing with e.g. the perturbation solution or identification toolbox.
In any case, I still have problems to get the hang of this. So maybe someone can help me out, given the following simple example:
```
var Y C K A;
varexo eps_A;
parameters alph betta rhoA sigA;
alph = 0.35; betta = 0.99; rhoA = 0.9; sigA = 0.6;
model;
C^(-1)=alph*betta*C(+1)^(-1)*A(+1)*K^(alph-1);
K=A*K(-1)^alph-C;
log(A)=rhoA*log(A(-1))+sigA*eps_A;
Y = A*K(-1)^alph;
end;
```
As I understand, my state variables are K and A, i.e.
- the declaration order is Y C K A
- the DR order is Y K A C
- lead_lag_incidence is equal to
| | Y | C | K | A |
|------|---|---|---|---|
| t-1 | 0 | 0 | 1 | 2 |
| t | 3 | 4 | 5 | 6 |
| t+1 | 0 | 7 | 0 | 8 |
where the number corresponds to the corresponding column number in the dynamic files (i.e. derivative wrt the variable)
Now, the kstate variable is given by:
| | | | |
| ------ | ------ | -----|--|
| 3 | 3 | 4 | 0|
| 4 | 3 | 3 | 0|
| 2 | 2 | 0 | 1|
| 3 | 2 | 0 | 2|
but I do not understand this. As far as I see, there is only one comment in set_state_space.m:
```
% composition of state vector
% col 1: variable; col 2: lead/lag in z(t+1);
% col 3: A cols for t+1 (D); col 4: A cols for t (E)
```
but what is the meaning of z(t+1), A, D and E or to which state space representation do these correspond to?
Thanks!Hi,
I was wondering if somebody can explain to me the structure of kstate? I am aware that using this is depreciated, as this is a reminiscence of old dynare versions where we did not create auxiliary variables for leads and lags greater than one, but still I find it is used in several functions dealing with e.g. the perturbation solution or identification toolbox.
In any case, I still have problems to get the hang of this. So maybe someone can help me out, given the following simple example:
```
var Y C K A;
varexo eps_A;
parameters alph betta rhoA sigA;
alph = 0.35; betta = 0.99; rhoA = 0.9; sigA = 0.6;
model;
C^(-1)=alph*betta*C(+1)^(-1)*A(+1)*K^(alph-1);
K=A*K(-1)^alph-C;
log(A)=rhoA*log(A(-1))+sigA*eps_A;
Y = A*K(-1)^alph;
end;
```
As I understand, my state variables are K and A, i.e.
- the declaration order is Y C K A
- the DR order is Y K A C
- lead_lag_incidence is equal to
| | Y | C | K | A |
|------|---|---|---|---|
| t-1 | 0 | 0 | 1 | 2 |
| t | 3 | 4 | 5 | 6 |
| t+1 | 0 | 7 | 0 | 8 |
where the number corresponds to the corresponding column number in the dynamic files (i.e. derivative wrt the variable)
Now, the kstate variable is given by:
| | | | |
| ------ | ------ | -----|--|
| 3 | 3 | 4 | 0|
| 4 | 3 | 3 | 0|
| 2 | 2 | 0 | 1|
| 3 | 2 | 0 | 2|
but I do not understand this. As far as I see, there is only one comment in set_state_space.m:
```
% composition of state vector
% col 1: variable; col 2: lead/lag in z(t+1);
% col 3: A cols for t+1 (D); col 4: A cols for t (E)
```
but what is the meaning of z(t+1), A, D and E or to which state space representation do these correspond to?
Thanks!https://git.dynare.org/Dynare/dynare/issues/1652Crash in bytecode2019-12-03T14:45:18ZSé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.6Sébastien VillemotSébastien Villemothttps://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/1649new plot_shock_decomposition options2019-12-06T15:30:45ZMarco 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-12-13T17:29:34ZMarco 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.6https://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 Bastani