dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-03-17T10:31:02Zhttps://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.https://git.dynare.org/Dynare/dynare/-/issues/1709Rework handling of trends including automatic detrending2021-08-19T08:43:04ZFerhatMihoubiRework handling of trends including automatic detrendingFor the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new ...For the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1708Preprocessor fails to parse dates with negative date2020-06-30T12:10:36ZMichelJuillardPreprocessor fails to parse dates with negative date```
dates('-4Y');
```
translates in
```
dates('-dates('4Y')');
```
and
```
'-4Y'
```
translates in
```
'-dates('4Y')';
```
See attached *.mod file[test_negative_date.mod](/uploads/bd77dc2c55701ffd505b432a2071f86d/test_negative_date.mod...```
dates('-4Y');
```
translates in
```
dates('-dates('4Y')');
```
and
```
'-4Y'
```
translates in
```
'-dates('4Y')';
```
See attached *.mod file[test_negative_date.mod](/uploads/bd77dc2c55701ffd505b432a2071f86d/test_negative_date.mod)
The problem didn't appear in 4.5.74.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2021-07-23T15:37:25ZSébastien VillemotMacro commands that take no arguments have spurious parentheses appended to their synopsisSee for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.See for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.6.xhttps://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/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/1704Update partial information code2021-05-03T13:59:02ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1703det_cond_forecast() depends on oo_.dr.state_var but this is not always available2021-09-17T16:07:34ZMichelJuillarddet_cond_forecast() depends on oo_.dr.state_var but this is not always available``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model5.xMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1702det_cond_forecast() argument checking is broken2021-01-28T20:29:40ZMichelJuillarddet_cond_forecast() argument checking is brokenIf one calls det_cond_forecast with two arguments only as in the manual example, the function fails with error
```
impossible case
```
that is triggered near line 208If one calls det_cond_forecast with two arguments only as in the manual example, the function fails with error
```
impossible case
```
that is triggered near line 2085.xMichelJuillardMichelJuillardhttps://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/1700Proposal for a generalized solver2021-07-20T10:58:59ZMichelJuillardProposal for a generalized solverModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function tha...Model inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithm6.xhttps://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/1698Allow checking linearity for perfect foresight models2021-07-22T13:27:44ZJohannes PfeiferAllow checking linearity for perfect foresight modelsThe linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That ca...The linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1697Regression in LMMCP perfect foresight solver2020-12-02T21:55:49ZSébastien VillemotRegression in LMMCP perfect foresight solverThe simulation in `tests/lmmcp/rbcii.mod` fails to converge. The same file works with 4.5.
Once this is fixed, a check that convergence has indeed been obtained should be added, so that regressions may be detected earlier in the future.The simulation in `tests/lmmcp/rbcii.mod` fails to converge. The same file works with 4.5.
Once this is fixed, a check that convergence has indeed been obtained should be added, so that regressions may be detected earlier in the future.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1696fix parsing of user-provided command line arguments2020-02-11T17:15:49ZHoutan Bastanifix parsing of user-provided command line argumentsMatlab is actually quite good about keeping user-provided arguments together. See:
```
>> dynare example1 '-DA="nthn thnth"' -DB=[1,2, .3] -DB=( oe )
-DA="nthn thnth"
-DB=[1,2, .3]
-DB=( oe )
```
The output above comes from sim...Matlab is actually quite good about keeping user-provided arguments together. See:
```
>> dynare example1 '-DA="nthn thnth"' -DB=[1,2, .3] -DB=( oe )
-DA="nthn thnth"
-DB=[1,2, .3]
-DB=( oe )
```
The output above comes from simply printing the arguments of `varargin`.
We should be able to thus simply add single quotes around every user-provided argument in `dynare.m` and pass these directly to the preprocessor for processing. We'd then require that all strings be double-quoted and could potentially even handle macro expressions (not just base values) in `-D` arguments.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1695Calib_Smoother options specify sheet and range2020-01-13T17:40:52ZCamilo MarchesiniCalib_Smoother options specify sheet and range```calib_smoother``` currently does not support options related to 'sheet' and 'range' of the Excel spreadsheet. However, these options can be included in the ```estimation``` call. It could be useful to include them also in the call to ...```calib_smoother``` currently does not support options related to 'sheet' and 'range' of the Excel spreadsheet. However, these options can be included in the ```estimation``` call. It could be useful to include them also in the call to ```calib_smoother``` .
4.6https://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/1693Various improvements in Sphinx doc2021-07-23T15:21:51ZHoutan BastaniVarious improvements in Sphinx doc- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLA...- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand6.x