dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-01-13T17:20:08Zhttps://git.dynare.org/Dynare/dynare/-/issues/1731Error in derivatives of perfect foresight models with leaded or lagged exogen...2021-01-13T17:20:08ZMichelJuillardError in derivatives of perfect foresight models with leaded or lagged exogenous variablesA perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploa...A perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1730Consider saving results using -v7.3 flag2020-11-13T13:08:07ZJohannes PfeiferConsider saving results using -v7.3 flagWe may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.We may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.https://git.dynare.org/Dynare/dynare/-/issues/1729Suggestion: Provide unstable builds of current major version branch (e.g. 4.6...2020-06-05T16:58:28ZTom HoldenSuggestion: Provide unstable builds of current major version branch (e.g. 4.6 at present) as well as builds of the master branchIt would be good if as well as providing unstable builds of the master branch, unstable builds of the current major version branch were also provided (e.g. the 4.6 branch at present).
While people can of course compile this themselves, ...It would be good if as well as providing unstable builds of the master branch, unstable builds of the current major version branch were also provided (e.g. the 4.6 branch at present).
While people can of course compile this themselves, in practice this is quite onerous.https://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2021-01-19T09:49:57ZSébastien VillemotImprovements to make install ruleCurrently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to...Currently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1727Blocks of type "evaluate backward" are not correctly simulated2020-09-23T13:29:57ZSébastien VillemotBlocks of type "evaluate backward" are not correctly simulatedThe testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The t...The testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2021-05-07T17:10:32ZSébastien VillemotOption mfs=3 gives wrong resultThe `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible ...The `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2021-05-04T09:21:20ZSé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 t...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.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1724Discuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)2020-08-05T14:38:34ZWilli Mutschlerwilli@mutschler.euDiscuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. ...Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. I have a couple of questions|proposal for the best interface and call for this and would like your guys take on this.
### Declaring parameters
Here I would simply opt to what we do in a Maximum likelihood estimation and use the same syntax in an `estimated_params` or an `estimated_params_bounds` block:
```
stderr VARIABLE_NAME | corr VARIABLE_NAME_1, VARIABLE_NAME_2 | PARAMETER_NAME, LOWER_BOUND, UPPER_BOUND;
```
### Declaring which moments to use
Here I would propose a block similar to `moment_calibration`, but call it `estimated_moments`:
```
estimated_moments;
y_obs,y_obs; //[unconditional variance]
y_obs,y_obs(-(1:4)); //[some acf]
@#for ilag in -2:2
y_obs,R_obs(@{ilag}); //[ccf]
@#endfor
end;
```
### Invocation
Now the toughest question. How to invoke it? I see two options.
Option A: Add an option to `estimation`, e.g.
```
estimation(moments_estimation='GMM');
```
Option B: Have an own command for this, e.g.:
```
gmm_estimation(OPTIONS);
smm_estimation(OPTIONS);
irf_matching(OPTIONS);
```
which then internally calls a wrapper `dynare_moments_estimation.m` and runs the toolbox.
What do you guys think?5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1723Equations defining model local variables are not included in generated JSON f...2020-06-05T16:31:12ZTom HoldenEquations defining model local variables are not included in generated JSON filesThis bug came up in conversation with @MichelJuillard .
For example, this model block:
```
model;
#Pi=exp(pi);
#Pi_LEAD=exp(pi(1));
#Pi_STEADY=exp(pi_STEADY);
#kappa=(gamma/2)*(Pi-1)^2;
#kappa_STEADY=(gamma/2)*(Pi_STEADY-1)^2;
#c=log(1-...This bug came up in conversation with @MichelJuillard .
For example, this model block:
```
model;
#Pi=exp(pi);
#Pi_LEAD=exp(pi(1));
#Pi_STEADY=exp(pi_STEADY);
#kappa=(gamma/2)*(Pi-1)^2;
#kappa_STEADY=(gamma/2)*(Pi_STEADY-1)^2;
#c=log(1-kappa-eta)+y;
#c_LEAD=log(1-(gamma/2)*(Pi_LEAD-1)^2-eta)+y(1);
#h=y-z;
#w=sigma*c+nu*h-log(1-tauw);
#re=-log(beta)-d(1)+pi_STEADY;
#y_STEADY=(1/(sigma+nu))*(log((1-tauw)*((1-beta)*(Pi_STEADY-1)*Pi_STEADY/theta*gamma+1))-sigma*log(1-kappa_STEADY-eta));
#gdp=log(1-kappa)+y;
#gdp_STEADY=log(1-kappa_STEADY)+y_STEADY;
#dynareOBCMaxArgA1=(0);
#dynareOBCMaxArgB1=(re+phi_pi*(pi-pi_STEADY)+phi_y*(gdp-gdp_STEADY));
#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);
r=(dynareOBCMaxFunc1);
1=beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD));
(Pi-1)*Pi=theta/gamma*(exp(w-z)-1)+beta*exp(d(1)+sigma*(c-c_LEAD)+y(1)-y)*(Pi_LEAD-1)*Pi_LEAD;
d=rhod*d(-1)+sigmad*epsilond;
z=rhoz*z(-1)+sigmaz*epsilonz;
end;
```
becomes this in the JSON file (with `json=parse`):
```
...
"model":[
{"lhs": "r", "rhs": "dynareOBCMaxFunc1", "line": 37}
, {"lhs": "1", "rhs": "beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD))", "line": 38}
, {"lhs": "Pi*(Pi-1)", "rhs": "theta/gamma*(exp(w-z)-1)+Pi_LEAD*(Pi_LEAD-1)*beta*exp(y(1)+d(1)+sigma*(c-c_LEAD)-y)", "line": 39}
, {"lhs": "d", "rhs": "rhod*d(-1)+sigmad*epsilond", "line": 40}
, {"lhs": "z", "rhs": "rhoz*z(-1)+sigmaz*epsilonz", "line": 41}
]
, "xrefs": {"parameters": [], "endogenous": [], "exogenous": [], "exogenous_deterministic": []}
, "abstract_syntax_tree":[
{ "number":0, "line":37, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "dynareOBCMaxFunc1", "type" : "modelLocalVariable", "lag" : 0}}}, { "number":1, "line":38, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "NumConstNode", "value" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}}, "arg2" : {"node_type" : "VariableNode", "name" : "pi", "type" : "endogenous", "lag" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}}}}, { "number":2, "line":39, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "/", "arg1" : {"node_type" : "VariableNode", "name" : "theta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "gamma", "type" : "parameter", "lag" : 0}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "w", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}}}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}, "arg2" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 0}}}}}}}}}, { "number":3, "line":40, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhod", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmad", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilond", "type" : "exogenous", "lag" : 0}}}}}, { "number":4, "line":41, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhoz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmaz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilonz", "type" : "exogenous", "lag" : 0}}}}}], "variable_mapping":[
], "statements": [{"statementName": "param_init", "name": "beta", "value": "0.997"},
...
```5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1722Provide mapping between model local variable names and indices in the T vector2020-06-05T16:31:12ZTom HoldenProvide mapping between model local variable names and indices in the T vectorPer a request from a DynareOBC user, today I started working on making DynareOBC compatible with Dynare 4.6.
This is proving harder than expected due to the changes to preprocessor output.
Previously, DynareOBC relied on the *_static.m...Per a request from a DynareOBC user, today I started working on making DynareOBC compatible with Dynare 4.6.
This is proving harder than expected due to the changes to preprocessor output.
Previously, DynareOBC relied on the *_static.m and *_dynamic.m files containing lines giving the value of model local variables (MLVs). This is used in multiple places, e.g. for obtaining the steady state of the augmented model, or for generating code for MLV simulation.
Of course, it is not your duty to support DynareOBC, but having this information in the static and dynamic files was generally useful. For example, in code prepared for the Dynare summer school I used to teach, I used this feature to facilitate writing code for a "perturbation plus" type simulation algorithm (i.e. perturbation used for next period values conditional on today's state and future shock, but given this approximation, the full nonlinear equations + cubature were used to derive today's value).
To make things easy again, it would be sufficient if the generated *_tt.m added comments at the end of each line defining a temporary variable (i.e. T(*)) definition with the name of the MLV to which the given element T(*) corresponds. E.g.:
`#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);`
would become:
`T(14) = max(T(12),T(13)); % dynareOBCMaxFunc1`
Alternatively, the optionally generated JSON could contain this information.
However, I guess that for either of these approaches to be viable as a strategy for DynareOBC to support Dynare 4.6, this would need to be added to Dynare fairly quickly (e.g. for 4.6.2), which may not be viable.
If this is not possible, (and in any case), it would be good to have some documentation of what users can safely assume about the elements of the T vector. A few relevant questions follow:
1. Are all MLVs defined in the model block and used somewhere in the model guaranteed to be in the T vector?
2. If MLV A is defined before MLV B in the model block, then will A definitely be before B in the T vector?
3. Are the MLVs guaranteed to be the first elements of the T vector, or could MLVs and generated temporaries be interspersed?5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2024-03-26T09:53:46ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16537.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1720lmmcp does not work with purely forward or backward models2022-09-06T13:06:43ZJohannes Pfeiferlmmcp does not work with purely forward or backward modelsIn this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constr...In this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constraints. A current workaround is using dummy equations.5.xSébastien VillemotSébastien Villemothttps://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/1718Auxillary particle filter --- number_of_state_variables is undefined2023-07-12T16:29:58ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`n...In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2023-03-20T11:45:35ZJohannes PfeiferClean root folder of /testsAll integration tests should be in subfolders. The current structure is a messAll integration tests should be in subfolders. The current structure is a mess6.xhttps://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/1713Decide minimal MATLAB version requirement for Dynare 4.72020-09-03T14:45:14ZSébastien VillemotDecide minimal MATLAB version requirement for Dynare 4.7We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keepin...We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keeping the same policy would imply raising the minimal MATLAB version to R2011a or R2011b (depending on the exact release date).
But we could also decide to change our policy and support less versions. For example, we could go for a 5-years windows, which would imply R2016a or R2016b. Or we could choose something between 5 and 10 years.
Relevant to this discussion is the list of [MATLAB incompatibilities across versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions). Here are the main benefits that would bring certain requirements:
- *R2013a*: we could get rid of the hack needed to support `intersect(…, 'stable')`
- *R2014a*: we could easily install the minimal required MATLAB version on modern GNU/Linux systems (currently we need a hack to create an artificial `eth0` device with the correct MAC address)
- *R2016a*: we could drop the support for 32-bit versions, which would halve the size of the Windows installer and simplify the build process
- *R2016b*: we could use automatic broadcasting in many places, instead of the obscure `bsxfun` syntax5.xSébastien VillemotSébastien Villemothttps://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/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/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.