dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-05-20T10:14:37Zhttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2020-05-20T10:14:37ZSébastien VillemotBetter interface for mfs optionThe `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.The `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1684New WITH_TREND() operator for epilogue block2019-12-13T17:29:05ZSébastien VillemotNew WITH_TREND() operator for epilogue blockImplement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #1648Implement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #16484.7https://git.dynare.org/Dynare/dynare/-/issues/1674Modification to shock_decomposition and plot_decomposition interfaces to incl...2020-10-15T15:23:40ZDóra Kocsiskocsis.doralinda@gmail.comModification to shock_decomposition and plot_decomposition interfaces to include flexibility with datesInclude the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.Include the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.4.7https://git.dynare.org/Dynare/dynare/-/issues/1597Accept UTF-8 in .mod file2020-05-07T17:45:03ZHoutan BastaniAccept UTF-8 in .mod filehttps://git.dynare.org/Dynare/dynare/-/issues/1596add maximum lag info by variable2020-05-07T17:45:37ZHoutan Bastaniadd maximum lag info by variable```
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr````
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr`https://git.dynare.org/Dynare/dynare/-/issues/978Fix interface/options for stochastic extended path in master2019-04-01T07:09:38ZJohannes Pfeifer Fix interface/options for stochastic extended path in masterNot all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
Not all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/891adding options to irf/moment calibration2018-09-11T15:00:44ZMarco Rattoadding options to irf/moment calibrationWould it be possible to add options in the irf/moment calibration interface.
For example it would be good to allow:
```
irf_calibration(relative_irf);
...
end;
```
to allow triggering
`options_.relative_irf=1;`
In fact, when std of shocks are estimated, it makes probably more sense to target a relative response w.r.t. an absolute one, which might just change due to the change in the value of the shock.
Similarly, we might think of allowing `moment_calibration` to trigger estimation type options, like
```
varobs y_obs R_obs pie_obs dq de;
moment_calibration(datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1);
...
end;
```
that would allow me to write a routine that automatically generates data based moment restrictions up to lag `ar` for theoretical moments of the variables listed in `varobs`.
We might also allow a different list of variables for calibration w.r.t. estimation, e.g. by
```
varobs_calibration y_obs R_obs pie_obs dq de;
```
Or by adding the list of variables inside the `moment_calibration` command (like `namendo` comma separated list in sensitivity analysis)
```
moment_calibration( datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1,
varobs=(y_obs, R_obs, pie_obs, dq de)
);
...
end;
```
what do you think?
Would it be possible to add options in the irf/moment calibration interface.
For example it would be good to allow:
```
irf_calibration(relative_irf);
...
end;
```
to allow triggering
`options_.relative_irf=1;`
In fact, when std of shocks are estimated, it makes probably more sense to target a relative response w.r.t. an absolute one, which might just change due to the change in the value of the shock.
Similarly, we might think of allowing `moment_calibration` to trigger estimation type options, like
```
varobs y_obs R_obs pie_obs dq de;
moment_calibration(datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1);
...
end;
```
that would allow me to write a routine that automatically generates data based moment restrictions up to lag `ar` for theoretical moments of the variables listed in `varobs`.
We might also allow a different list of variables for calibration w.r.t. estimation, e.g. by
```
varobs_calibration y_obs R_obs pie_obs dq de;
```
Or by adding the list of variables inside the `moment_calibration` command (like `namendo` comma separated list in sensitivity analysis)
```
moment_calibration( datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1,
varobs=(y_obs, R_obs, pie_obs, dq de)
);
...
end;
```
what do you think?
https://git.dynare.org/Dynare/dynare/-/issues/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2018-09-11T15:00:44ZTom HoldenPreprocessor: Allow reusage of model local variable names in steady_state_model block (wishlist)At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
https://git.dynare.org/Dynare/dynare/-/issues/614not balanced growth model not detected by test2019-11-21T08:36:46ZMichelJuillardnot balanced growth model not detected by testHere is an example where an error in trend declaration isn't detected by the balanced growth test. It may come from the fact that labor enhancing productivity (G) is not a variable of the model, just a trend. The error should appear for the equations defining r and w and for the resource constraint.
```
parameters rho delta gamma alpha lambda g;
trend_var(growth_factor=1+g) G;
// the trend of K is wrong:
var(deflator=G) C w;
var L r A K;
// Here is the correct specification:
// var(deflator=G) C w K;
// var L r A;
varexo e;
alpha = 0.33;
delta = 0.1;
rho = 0.03;
lambda = 0.97;
gamma = 0;
g = 0.015;
model;
1/C = 1/(1+rho)*(1/C(+1))*(r(+1)+1-delta);
L^gamma = w/C;
r = alpha*A*K(-1)^(alpha-1)*(G*L)^(1-alpha);
w = (1-alpha)*A*K(-1)^alpha*(G*L)^(-alpha);
K+C = K(-1)*(1-delta)+A*K(-1)^alpha*(G*L)^(1-alpha);
log(A) = lambda*log(A(-1))+e;
end;
steady_state_model;
A = 1;
r = (1+g)*(1+rho)+delta-1;
K_L = (1+g)*(r/(alpha*A))^(1/(alpha-1));
w = (1-alpha)*A*(K_L/(1+g))^alpha;
L = (-((delta+g)/(1+g))*K_L/w+A*(K_L/((1+g)*w^(1/alpha)))^alpha)
^(-1/(1+gamma));
K = K_L*L;
C = (1-delta)*K/(1+g)+(K_L/(1+g))^alpha*L-K;
end;
shocks;
var e; stderr 0.01;
end;
write_latex_dynamic_model;
steady;
check;
stoch_simul(order=1);
```
Here is an example where an error in trend declaration isn't detected by the balanced growth test. It may come from the fact that labor enhancing productivity (G) is not a variable of the model, just a trend. The error should appear for the equations defining r and w and for the resource constraint.
```
parameters rho delta gamma alpha lambda g;
trend_var(growth_factor=1+g) G;
// the trend of K is wrong:
var(deflator=G) C w;
var L r A K;
// Here is the correct specification:
// var(deflator=G) C w K;
// var L r A;
varexo e;
alpha = 0.33;
delta = 0.1;
rho = 0.03;
lambda = 0.97;
gamma = 0;
g = 0.015;
model;
1/C = 1/(1+rho)*(1/C(+1))*(r(+1)+1-delta);
L^gamma = w/C;
r = alpha*A*K(-1)^(alpha-1)*(G*L)^(1-alpha);
w = (1-alpha)*A*K(-1)^alpha*(G*L)^(-alpha);
K+C = K(-1)*(1-delta)+A*K(-1)^alpha*(G*L)^(1-alpha);
log(A) = lambda*log(A(-1))+e;
end;
steady_state_model;
A = 1;
r = (1+g)*(1+rho)+delta-1;
K_L = (1+g)*(r/(alpha*A))^(1/(alpha-1));
w = (1-alpha)*A*(K_L/(1+g))^alpha;
L = (-((delta+g)/(1+g))*K_L/w+A*(K_L/((1+g)*w^(1/alpha)))^alpha)
^(-1/(1+gamma));
K = K_L*L;
C = (1-delta)*K/(1+g)+(K_L/(1+g))^alpha*L-K;
end;
shocks;
var e; stderr 0.01;
end;
write_latex_dynamic_model;
steady;
check;
stoch_simul(order=1);
```
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/349Use preprocessor for variable transformation (e.g. exp for doing approximatio...2020-12-23T12:53:54ZJohannes Pfeifer Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.4.7https://git.dynare.org/Dynare/dynare/-/issues/300Implement k-order derivatives of external functions2019-12-16T14:00:55ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor error
Otherwise order ≥ 3 fails with a cryptic preprocessor error
4.7https://git.dynare.org/Dynare/dynare/-/issues/294rework option handling2020-05-07T17:47:23ZSébastien Villemotrework option handlingIt's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
It's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
https://git.dynare.org/Dynare/dynare/-/issues/240rewrite getPowerDeriv assignments in temporary terms2019-06-19T15:37:42ZSébastien Villemotrewrite getPowerDeriv assignments in temporary termsFrom Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
From Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
https://git.dynare.org/Dynare/dynare/-/issues/172improve derivation engine for derivatives of STEADY_STATE wrt parameters2019-06-19T15:37:42ZSébastien Villemotimprove derivation engine for derivatives of STEADY_STATE wrt parametersCurrently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
Currently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
https://git.dynare.org/Dynare/dynare/-/issues/135Improve display of decision rules with EXPECTATION operator2019-11-21T08:36:45ZSébastien VillemotImprove display of decision rules with EXPECTATION operatorCurrently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.
Currently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.