dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-05-07T17:45:44Zhttps://git.dynare.org/Dynare/dynare/-/issues/1540create reports for dynare commands2020-05-07T17:45:44ZHoutan Bastanicreate reports for dynare commandsCreate standardized reporting output for dynare commands using the reporting submodule, replacing latex code throughout the dynare codebaseCreate standardized reporting output for dynare commands using the reporting submodule, replacing latex code throughout the dynare codebasehttps://git.dynare.org/Dynare/dynare/-/issues/1711Provide M_ as output of stoch_simul and discretionary_policy2020-05-06T14:33:56ZJohannes PfeiferProvide M_ as output of stoch_simul and discretionary_policyWe forgot in https://git.dynare.org/Dynare/dynare/commit/e043c60903dd0e5746feb8af25cd60f1dbcbe53f
that within the computation of decision rules, the steady state file can change parameters and therefore `M_.params`. In the current versio...We forgot in https://git.dynare.org/Dynare/dynare/commit/e043c60903dd0e5746feb8af25cd60f1dbcbe53f
that within the computation of decision rules, the steady state file can change parameters and therefore `M_.params`. In the current version, that change will not be passed to the base workspace.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 greate...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/1706Fix wrong computation in third-order approximation in pruned_state_space.m2020-04-06T08:19:17ZJohannes PfeiferFix wrong computation in third-order approximation in pruned_state_space.mMattermost discussion 06/02/20Mattermost discussion 06/02/204.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1719Allow running shock_decomposition on simulated model2020-03-31T16:18:23ZJohannes PfeiferAllow running shock_decomposition on simulated modelCurrently, `shock_decomposition` only allows for
```
if isempty(parameter_set)
if isfield(oo_,'posterior_mean')
parameter_set = 'posterior_mean';
elseif isfield(oo_,'mle_mode')
parameter_set = 'mle_mode';
else...Currently, `shock_decomposition` only allows for
```
if isempty(parameter_set)
if isfield(oo_,'posterior_mean')
parameter_set = 'posterior_mean';
elseif isfield(oo_,'mle_mode')
parameter_set = 'mle_mode';
elseif isfield(oo_,'posterior')
parameter_set = 'posterior_mode';
else
error(['shock_decomposition: option parameter_set is not specified ' ...
'and posterior mode is not available'])
end
end
```
but then we call `evaluate_smoother`, where we allow for
```
switch parameters
case 'posterior_mode'
parameters = get_posterior_parameters('mode',M_,estim_params_,oo_,options_);
case 'posterior_mean'
parameters = get_posterior_parameters('mean',M_,estim_params_,oo_,options_);
case 'posterior_median'
parameters = get_posterior_parameters('median',M_,estim_params_,oo_,options_);
case 'mle_mode'
parameters = get_posterior_parameters('mode',M_,estim_params_,oo_,options_,'mle_');
case 'prior_mode'
parameters = bayestopt_.p5(:);
case 'prior_mean'
parameters = bayestopt_.p1;
case 'calibration'
if isempty(oo_.dr)
error('You must run ''stoch_simul'' first.');
end
parameters = [];
```https://git.dynare.org/Dynare/dynare/-/issues/1712Difficulty configuring dynare in Ubuntu 18.042020-03-17T10:31:02ZCraig FratrikDifficulty configuring dynare in Ubuntu 18.04There doesn't seem to be an easy way to get Ubuntu 18.04 to default to GCC 8 if GCC 7 is around, which is normally is because of build-essentials.
It would be nice if the configure script for dynare, double checked that gcc and g++ and ...There doesn't seem to be an easy way to get Ubuntu 18.04 to default to GCC 8 if GCC 7 is around, which is normally is because of build-essentials.
It would be nice if the configure script for dynare, double checked that gcc and g++ and gfortran are >= 8, and if they aren't lookede for gcc-8, etc. instead.
I'm not sure how much work this would be inside the configure scripts. But if you think it's a good idea I can look into it. It would be especially helpful if you had thoughts on the best way to do this, because I'm ignorant when it comes to configure things.
I did write this script after >30m of searching on the internet [update-alternatives.sh](/uploads/7fd44dc23129675f12ea787e3c5e561c/update-alternatives.sh)https://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes PfeiferFix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveB...As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1714`get_error_message` does not return an output when `options_.noprint = 1`2020-03-10T08:26:24ZAliaksandr Zaretski`get_error_message` does not return an output when `options_.noprint = 1`The function `get_error_message` must return an output, but does so only when `options_.noprint = 0`. Hence, there is an unexpected error message when both `info(1) > 0` and `options_.noprint = 1`. To replicate, see attached [example1_ed...The function `get_error_message` must return an output, but does so only when `options_.noprint = 0`. Hence, there is an unexpected error message when both `info(1) > 0` and `options_.noprint = 1`. To replicate, see attached [example1_ed.mod](/uploads/f0716731f7540ce7030e68dd2e5de1eb/example1_ed.mod), where I set `alpha = -0.36` to generate an error and added the `noprint` option. See attached slightly revised [print_info.m](/uploads/30439caa39aacbdac9f9e1b2a644483b/print_info.m) and [get_error_message.m](/uploads/c15787c57bb9e46b6a3136be9a803db9/get_error_message.m) where the issue is solved.https://git.dynare.org/Dynare/dynare/-/issues/1710num_procs doesn't exist in Matalb R2019b anymore2020-02-22T17:49:35ZMichelJuillardnum_procs doesn't exist in Matalb R2019b anymoreThere is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_o...There is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_order_perturbation``
A possible alternative would be an undocumented Matlab feature: ``feature('numcores')``
Undocumented Matlab features are discussed in this old document: http://undocumentedmatlab.com/articles/undocumented-feature-function/ but is still working.https://git.dynare.org/Dynare/dynare/-/issues/1673Nonlinear filters at k-order2020-02-17T09:28:31ZSébastien VillemotNonlinear filters at k-orderA MEX file for iterating in the state space (based on Dynare++) is already present in the `local_state_space_iteration_k` branch.
It needs to be tested and integrated in the estimation routines.A MEX file for iterating in the state space (based on Dynare++) is already present in the `local_state_space_iteration_k` branch.
It needs to be tested and integrated in the estimation routines.4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1705Fix, clean and speed up discretionary_policy routines2020-02-12T16:18:04ZJohannes PfeiferFix, clean and speed up discretionary_policy routinesAs is `discretionary_policy_1.m` has various issues
1. At its end, we have
```
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
eval(['ys=',M_.fname,'_steadystate.m;'])
else
ys=zeros(M_.en...As is `discretionary_policy_1.m` has various issues
1. At its end, we have
```
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
eval(['ys=',M_.fname,'_steadystate.m;'])
else
ys=zeros(M_.endo_nbr,1);
end
```
which seems to miss the case of a `steady_state_model`-block. It's also not clear why we have this in any case. At the end of the function, we write `ys` based on this input. But throughout the function, like in
```
[U,Uy,W] = feval([M_.fname,'.objective.static'],zeros(endo_nbr,1),[], M_.params);
```
we assume the steady state to be 0.
2. The handling of error codes should be nested into the `print_info`-framework as opposed to always issuing errors.
3. The function is very verbatim in terms of providing diagnostics. That is useful in standalone code, but a bottleneck when run in a loop like `estimation` where we only want to discard infeasible draws without providing diagnostics.
4. The order of some checks is strange. We do computations on the model before checking e.g. whether the number of instruments is valid. We should be able to do this without computing the Jacobian. Also a check like this should only be done once in the context of estimation and does not belong into the core engine. This suggests a different factorization.
Related to https://git.dynare.org/Dynare/dynare/issues/11734.6Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/637M_.state_var2020-02-11T10:08:30ZMichelJuillardM_.state_varCurrently, the vector M_.state_var is created by the preprocessor only when estimation is taking place. Because, this vector contains information useful in any context involving linear representation, I suggest to create it in all cases....Currently, the vector M_.state_var is created by the preprocessor only when estimation is taking place. Because, this vector contains information useful in any context involving linear representation, I suggest to create it in all cases.
M_.state_var points to variables in declaration order, but is not sorted. This is confusing
In addition, dr_block copies it to oo_.dr. This is confusing.
4.6Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1431Port write_equation_tags to write_latex_static_model and write_latex_original...2020-02-04T14:35:04ZJohannes PfeiferPort write_equation_tags to write_latex_static_model and write_latex_original_modelSee https://github.com/DynareTeam/dynare/commit/14f4544a29eac182ff1f5840e5f9cc78b9efa7e0#commitcomment-21632978See https://github.com/DynareTeam/dynare/commit/14f4544a29eac182ff1f5840e5f9cc78b9efa7e0#commitcomment-216329784.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1701det_conditional_forecast doesn't set set options_.qz_criterium2020-02-03T17:37:21ZMichelJuillarddet_conditional_forecast doesn't set set options_.qz_criteriumWhen ``det_conditional_forecast`` is used by itself in a *.mod file as in the example of the manual options_.qz_criterium isn't set.
We should have
```
options_.qz_criterium = 1+1e-6;
```
at the beginning of the functionWhen ``det_conditional_forecast`` is used by itself in a *.mod file as in the example of the manual options_.qz_criterium isn't set.
We should have
```
options_.qz_criterium = 1+1e-6;
```
at the beginning of the function4.6https://git.dynare.org/Dynare/dynare/-/issues/1699Welfare under optimal discretionary policy not computed2020-01-30T14:50:04ZSébastien VillemotWelfare under optimal discretionary policy not computedAt least with `dennis_1.mod` and `Gali_discretion.mod` from `tests/discretionary_policy/`, the welfare (as stored in `oo_.planner_objective_value`) is a `NaN`. This is a regression from 4.5.
Unfortunately, the test at the end of `Gali_d...At least with `dennis_1.mod` and `Gali_discretion.mod` from `tests/discretionary_policy/`, the welfare (as stored in `oo_.planner_objective_value`) is a `NaN`. This is a regression from 4.5.
Unfortunately, the test at the end of `Gali_discretion.mod` did not catch the problem, because of the specific evaluation rules for `NaN`. This should also be fixed with some call to `isnan()`.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1694Identification tests fail for old matlab2020-01-24T17:25:41ZWilli Mutschlerwilli@mutschler.euIdentification tests fail for old matlabSome identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.Some identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1689Clarify licensing information for identification stuff2020-01-24T14:41:20ZSébastien VillemotClarify licensing information for identification stuffSee !1689
The information should be added in the corresponding headers, and in `license.txt`See !1689
The information should be added in the corresponding headers, and in `license.txt`4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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`, `onlym...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/1687Interface and documentation for new shock decomposition functionalities2020-01-22T17:18:39ZSébastien VillemotInterface and documentation for new shock decomposition functionalitiesImplement the preprocessor changes needed for !1655.
The test `tests/shock_decomposition/ls2003_plot.mod` will need to be adapted for the new `squeeze_shock_decomposition` command.
Also add the related documentation.Implement the preprocessor changes needed for !1655.
The test `tests/shock_decomposition/ls2003_plot.mod` will need to be adapted for the new `squeeze_shock_decomposition` command.
Also add the related documentation.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1679Document epilogue2020-01-22T09:33:16ZSébastien VillemotDocument epilogueIt should also be added to the new features wiki page.It should also be added to the new features wiki page.4.6Houtan BastaniHoutan Bastani