dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:42Zhttps://git.dynare.org/Dynare/dynare/-/issues/285Allow user-specified path for exogenous in extended_path2019-06-19T15:37:42ZSébastien VillemotAllow user-specified path for exogenous in extended_pathThat could be implemented with the shocks blocks.
That could be implemented with the shocks blocks.
https://git.dynare.org/Dynare/dynare/-/issues/1839Automatic normalization of variables when solving a model with multiple trends2022-01-21T14:31:17ZUgo DuboisAutomatic normalization of variables when solving a model with multiple trendsTrying to simulate the latest backward-looking version of the FR-BDF model with perfect_foresight_solver (as we did before) seems to have raised a conflict between the precision criteria (tolf) and the simulation horizon. We raised the p...Trying to simulate the latest backward-looking version of the FR-BDF model with perfect_foresight_solver (as we did before) seems to have raised a conflict between the precision criteria (tolf) and the simulation horizon. We raised the precision criteria to 1e-9 to get a better comparison with Troll simulations with a previous version of the model, with no impact on the simulation horizon length (we used to simulate up to 2300Q4, roughly 1130 periods).
Updating the model to its latest version (the main difference with the former version being the integration of block related to financing of firms), we can no longer simulate further than 2050Q4 (128 periods) with tolf at 1e-9, lowering the precision criteria to 1e-5 (its default value), we’re able to simulate up to but no further than 2083Q4 (about 260 periods).
Checking the equation’s numerical residuals against the ones obtained in Troll (using dynamic_resid.m and feeding it manually constructed inputs), we are confident the issue does not come from a parsing error (translation from Troll syntax to Dynare).
Our main hypothesis tends to focus on the fact that the values of variables vary widely from variable to variable, with growing discrepancies in simulations related to multiple steady-state growth rates of the model. Mixing very small quantities with very big ones could cause issues in the numerical methods used to solve the model. Operating some automatic normalization when solving the model could solve this aspect. The way to operate such a rebalancing and the degree of generality of the algorithm (only for backward-looking models or also for forward-looking ones) will be specified after a discussion with Stéphane Adjemian.https://git.dynare.org/Dynare/dynare/-/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2021-08-15T16:14:51ZStéphane Adjemianstepan@adjemian.euBehavior of STEADY_STATE() in perfect foresight models with anticipated permanent shocks.In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent sh...In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).6.xhttps://git.dynare.org/Dynare/dynare/-/issues/326Change color scheme of figures to be readable on monochrome printouts2019-06-19T15:37:41ZJohannes PfeiferChange color scheme of figures to be readable on monochrome printoutsMore information will be provided soon.
More information will be provided soon.
https://git.dynare.org/Dynare/dynare/-/issues/530checking singularity in first order approximation2021-08-15T19:44:22ZMichelJuillardchecking singularity in first order approximationCurrently, we don't check for singularity in first order approximation when solving for static variables (is b10 singular?) or solving for shocks coefficient (is A_ singular?)
1) We should probably add a warning to stoch_simul (and ramse...Currently, we don't check for singularity in first order approximation when solving for static variables (is b10 singular?) or solving for shocks coefficient (is A_ singular?)
1) We should probably add a warning to stoch_simul (and ramsey_policy)
2) Should we care for estimation? Should expand the implicit prior to b10 and A_ non-singular?
3) If b10 is singular, the model has a problem: it is not possible to determine some static variable from the solution of the dynamic part of the model
4) The conditions under which A_ can be singular are mode difficult to determine.
https://git.dynare.org/Dynare/dynare/-/issues/1800cherrypick() : Add a 'All' option for the tags selection argument2021-07-22T09:48:04ZUgo Duboischerrypick() : Add a 'All' option for the tags selection argumentAs discussed with Stephanne (A) last Friday (2021-07-16) we think it would be a good (and practical) thing to have a 'Select all the equations in the (sub)model it is invoqued on' option for cherrypick()'s third argument.
Use case: in a...As discussed with Stephanne (A) last Friday (2021-07-16) we think it would be a good (and practical) thing to have a 'Select all the equations in the (sub)model it is invoqued on' option for cherrypick()'s third argument.
Use case: in a situation where we are aggregating a big model from several sub-models scripts, for sub-models where all the equations join the aggregated model, we wouldn't have to manually write the tags list of all the equations in the submodel for cherrypick to take them all. We would instead just have to write 'All'.https://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2021-07-22T10:27:26ZJohannes 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/1414command options should be made local, and a new syntax should provide persist...2022-04-29T14:58:00ZHoutan Bastanicommand options should be made local, and a new syntax should provide persistent optionsAllow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `com...Allow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1776Consistency in variable names2021-02-18T16:11:58ZWilli Mutschlerwilli@mutschler.euConsistency in variable namesI would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_...I would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_likelihood.m`, `dsge_var_likelihood.m`, `non_linear_dsge_likelihood` or in the functions of the identification toolbox we use names like `DynareOptions`, or `options` (without underscore). So maybe, right before we release 4.7, we could make the names consistent? This would be a simple text search and replace, but everyone would then need to rebase local branches to this.
I think these are the most important variables (feel free to add to this list):
- `M_`
- `options_`
- `oo_`
- `estim_params_`
- `bayestopt_`
- `dataset_`
- `dataset_info`
- `estimation_info`6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2021-05-03T13:58:40ZSébastien VillemotCreate a MEX equivalent to minreal from the control toolbxSee the comments in `get_minimal_state_representation.m`.See the comments in `get_minimal_state_representation.m`.6.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1521create class for storing/writing metropolis draws2021-07-20T10:58:09ZHoutan Bastanicreate class for storing/writing metropolis drawsIn the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
...In the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.6.xhttps://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/909Create true unit test from comments in middle of random_walk_metropolis_hasti...2018-09-11T15:00:44ZJohannes PfeiferCreate true unit test from comments in middle of random_walk_metropolis_hastings.mThere is some advice for a manual unit test hidden there.
There is some advice for a manual unit test hidden there.
https://git.dynare.org/Dynare/dynare/-/issues/1663datafile option in perfect_foresight_setup: incomplete documentation and not ...2021-09-23T15:10:09ZMichelJuillarddatafile option in perfect_foresight_setup: incomplete documentation and not flexible enoughthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flex...the datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flexible
- [x] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-modelhttps://git.dynare.org/Dynare/dynare/-/issues/1825Decide on whether to drop Dynare++2021-11-19T16:37:37ZJohannes PfeiferDecide on whether to drop Dynare++Most functionality of Dynare++ has been integrated to Dynare. We are moving closer/further with tickets like https://git.dynare.org/Dynare/dynare/-/issues/1802
But there still are some parts that Dynare++ is capable of that are not suppo...Most functionality of Dynare++ has been integrated to Dynare. We are moving closer/further with tickets like https://git.dynare.org/Dynare/dynare/-/issues/1802
But there still are some parts that Dynare++ is capable of that are not supported in Dynare. From what I can see we have
1. approximation around something like the stochastic steady state (`--steps` option for steps in the volatility direction). Related Dynare ticket:
2. numerical accuracy checks.
I would propose to drop Dynare++ once we have these features in place in Dynare. For
1. we have the related risky steady state (https://git.dynare.org/Dynare/dynare/-/issues/1338), the nonlinear moving average codes (https://git.dynare.org/Dynare/dynare/-/merge_requests/653). I am also pretty sure there are newer developments.
2. we have the ticket https://git.dynare.org/Dynare/dynare/-/issues/1476.xhttps://git.dynare.org/Dynare/dynare/-/issues/1818Decide what to do with solve_algo=132022-05-17T19:57:45ZSébastien VillemotDecide what to do with solve_algo=13`solve_algo=13` uses the `block_trust_region` MEX, which is essentially a MEX reimplementation of what is available under `solve_algo=4`.
After a Mattermost discussion on 2021-09-21/22, the consensus seems to be:
- verify that the two c...`solve_algo=13` uses the `block_trust_region` MEX, which is essentially a MEX reimplementation of what is available under `solve_algo=4`.
After a Mattermost discussion on 2021-09-21/22, the consensus seems to be:
- verify that the two codes are really equivalent (in particular when moving in the complex domain)
- then change `solve_algo=4` so that it calls the MEX file, and drop `solve_algo=13`
- the old MATLAB code for `solve_algo=4` should be kept under `missing/mex`, ideally with an interface, in order to facilitate the debugging of models (which is easier in MATLAB than in Fortran)6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1031declare all options_ fields as empty/0/NaN in global_initialization2021-01-20T10:05:50ZHoutan Bastanideclare all options_ fields as empty/0/NaN in global_initializationFollowing the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
Following the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
https://git.dynare.org/Dynare/dynare/-/issues/1055Deprecate first_obs and last_obs in data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDeprecate first_obs and last_obs in data commandReplaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Replaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1812diff() operator extension for quarterly data2021-09-16T13:47:23ZUgo Duboisdiff() operator extension for quarterly dataThe current diff() operator implementation only allows to get diff('variable') = variable(t) - variable(t-1).
Some equations in our model use Year over Year differences in quarterly time series variables.
We would like a diff() operat...The current diff() operator implementation only allows to get diff('variable') = variable(t) - variable(t-1).
Some equations in our model use Year over Year differences in quarterly time series variables.
We would like a diff() operator extension allowing us to write such a difference, for example this way:
diff('variable', X) = variable(t) - variable(t-X) where X is an integer representing the lag over which we want to get the variable differentiated (our use case would have X = 4). It might be an optional argument and/or default to 1 in order to preserve its current functioning.https://git.dynare.org/Dynare/dynare/-/issues/1758Discuss moving all mod-file output to folder `M_.dname`2021-09-23T09:39:16ZJohannes PfeiferDiscuss moving all mod-file output to folder `M_.dname`The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the...The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the `dname`-saving logic does not fully work. In the long-run, we will move almost all Dynare-generated output to a subfolder of `M_.dname` to get a clean root directory. We have increasingly moved to the direction in the past, e.g. with the $\LaTeX$-files. Two notable exceptions will most probably be
1. `_TeX_binder.tex` due to `\include` only working for subdirectories
2. The `log`-file
3. Potentially the files generated by mode-finders as the user can easily turn them off.
Still to be done:
- [ ] Offer a preprocessor command line option `dname` to set this at the preprocessor-level. This would allow solving the `json`-issue discussed at https://git.dynare.org/Dynare/dynare/-/merge_requests/1793
- [ ] Move the JSON files6.x