dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-12-12T17:59:24Zhttps://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/1667Problem with command line options passed on the first line of a `.mod` file w...2020-01-23T17:58:43ZHoutan BastaniProblem with command line options passed on the first line of a `.mod` file when they are used in dynare.mWhen command line options are passed on the first line of a `.mod` file within `// --+ options: +--`, they are parsed by the preprocessor and ignored by `dynare.m`.
This ignores the options `nopathchange`, `nopreprocessoroutput`, `onlymacro`, `onlyjson`, and `nolog`. An attempt to fix this was made with a regex for `nolog` but it is buggy (e.g. a command line argument such as `savemacro=,nolog,` would result in no Dynare log being created).When command line options are passed on the first line of a `.mod` file within `// --+ options: +--`, they are parsed by the preprocessor and ignored by `dynare.m`.
This ignores the options `nopathchange`, `nopreprocessoroutput`, `onlymacro`, `onlyjson`, and `nolog`. An attempt to fix this was made with a regex for `nolog` but it is buggy (e.g. a command line argument such as `savemacro=,nolog,` would result in no Dynare log being created).4.6Sébastien VillemotSébastien Villemothttps://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/1656Provide documentation for the upgrading to 4.62020-01-10T15:47:45ZSébastien VillemotProvide documentation 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. Other things have changed in a backward-incompatible way.
We need to compile the list of all those structures, and document that change in the release notes.
Between 4.5 and 4.6, many structures in `M_`, `options_` and elsewhere which used to be character vectors are now cell arrays. Other things have changed in a backward-incompatible way.
We need to compile the list of all those structures, and document that change in the release notes.
4.6https://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/1653kstate2020-05-04T16:22:56ZWilli 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/1650allow to associate initial conditions to shocks in shocks grouping for shock ...2020-01-21T17:39:56ZMarco 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-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 Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1645Provide an example for ramsey_policy and osr2020-01-10T17:30:50ZSébastien VillemotProvide an example for ramsey_policy and osrTo be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.To be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1644How to include m2html when compiling the MEX for MATLAB2019-05-22T15:36:00ZWilli Mutschlerwilli@mutschler.euHow to include m2html when compiling the MEX for MATLABHi, just a minor (and not really important) question, but still for completeness.
Whenever I compile the preprocessor I always get
`M2HTML documentation: no` .
I did download m2html from https://www.artefact.tk/software/matlab/m2html/, unzipped it and added the path to matlab. I am on Ubuntu. Am I doing anything wrong?Hi, just a minor (and not really important) question, but still for completeness.
Whenever I compile the preprocessor I always get
`M2HTML documentation: no` .
I did download m2html from https://www.artefact.tk/software/matlab/m2html/, unzipped it and added the path to matlab. I am on Ubuntu. Am I doing anything wrong?Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1642Bug in analytical computations of second-order params derivs (d2A and d2Om)2019-03-27T11:52:59ZWilli Mutschlerwilli@mutschler.euBug in analytical computations of second-order params derivs (d2A and d2Om)The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.Marco RattoMarco Ratto