dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-01-22T17:18:39Zhttps://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.6documentationpreprocessorSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1682Sort out correct order of blocks in perfect foresight Ramsey and document it2020-01-10T14:48:20ZJohannes Pfeifer Sort out correct order of blocks in perfect foresight Ramsey and document itUsually `steady` after `initval` computes a steady state. But with `ramsey_model`, one seems to need the `ramsey_model(planner_discount=0.99);` statement before the call to steady and therefore `initval`. Also, it is not clear what `steady` does in this case. Is it the private sector equilibrium steady state or the Ramsey steady state that is computed.
Relevant test case: `optimal_policy/nk_ramsey_det.mod`Usually `steady` after `initval` computes a steady state. But with `ramsey_model`, one seems to need the `ramsey_model(planner_discount=0.99);` statement before the call to steady and therefore `initval`. Also, it is not clear what `steady` does in this case. Is it the private sector equilibrium steady state or the Ramsey steady state that is computed.
Relevant test case: `optimal_policy/nk_ramsey_det.mod`4.6documentationhttps://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.6documentationHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1678Provide interface to access evaluate_planner_objective.m2020-01-10T14:48:18ZJohannes Pfeifer Provide interface to access evaluate_planner_objective.mAs noted in https://git.dynare.org/Dynare/dynare/issues/564#note_9765, `ramsey_policy` only allows for `order=1`. The solution is to replace it by
```
ramsey_model;
stoch_simul(order=2)
```
But the downside of this approach is that we do not compute the welfare function in this case and one cannot add it to the model-block. For that reason, we need to provide the user with an interface to call `evaluate_planner_objective`As noted in https://git.dynare.org/Dynare/dynare/issues/564#note_9765, `ramsey_policy` only allows for `order=1`. The solution is to replace it by
```
ramsey_model;
stoch_simul(order=2)
```
But the downside of this approach is that we do not compute the welfare function in this case and one cannot add it to the model-block. For that reason, we need to provide the user with an interface to call `evaluate_planner_objective`4.6documentationenhancementpreprocessorJohannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1672conditional_forecast should save its output in oo_2019-11-29T16:11:56ZSébastien Villemotconditional_forecast should save its output in oo_Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.4.6documentationenhancementhttps://git.dynare.org/Dynare/dynare/-/issues/1669Restore index of functions and commands in the manual2019-12-03T14:45:18ZSébastien VillemotRestore index of functions and commands in the manualIn the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.In the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.4.6bugdocumentationHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1656Provide documentation for the upgrading to 4.62020-01-10T15:47:45ZSébastien VillemotProvide documentation for the upgrading to 4.6Between 4.5 and 4.6, many structures in `M_`, `options_` and elsewhere which used to be character vectors are now cell arrays. Other things have changed in a backward-incompatible way.
We need to compile the list of all those structures, and document that change in the release notes.
Between 4.5 and 4.6, many structures in `M_`, `options_` and elsewhere which used to be character vectors are now cell arrays. Other things have changed in a backward-incompatible way.
We need to compile the list of all those structures, and document that change in the release notes.
4.6documentationhttps://git.dynare.org/Dynare/dynare/-/issues/1650allow to associate initial conditions to shocks in shocks grouping for shock ...2020-01-21T17:39:56ZMarco Rattoallow to associate initial conditions to shocks in shocks grouping for shock decomposition plotsIt would be useful to have an interface for a command like `init2shocks`, which accepts couples of names. first an endo name, second a shock name
```
init2shocks;
endoname1 exoname1;
endoname2 exoname1;
endoname3 exoname2;
...
;
```
there can be multiple endo names for one exo, but NOT viceversa.
The preprocessor should translate this into a cell matrix as follows:
```
M_.init2shocks = {
'endoname1','exoname1';
'endoname2','exoname1';
'endoname3','exoname2';
};
```
default will be: `M_.init2shocks = {};`
Then we need a new option `init2shocks` for `plot_shock_decomposition(init2shocks)`. If it is called, the preprocessor will trigger
```
options_.plot_shock_decomp.init2shocks = M_.init2shocks;
```
otherwise it should be empty (by default).
```
options_.plot_shock_decomp.init2shocks =[];
```
with this definitions, plot_shock_decompo will attribute the initial condition effect of endo variables to the shock/shock group.It would be useful to have an interface for a command like `init2shocks`, which accepts couples of names. first an endo name, second a shock name
```
init2shocks;
endoname1 exoname1;
endoname2 exoname1;
endoname3 exoname2;
...
;
```
there can be multiple endo names for one exo, but NOT viceversa.
The preprocessor should translate this into a cell matrix as follows:
```
M_.init2shocks = {
'endoname1','exoname1';
'endoname2','exoname1';
'endoname3','exoname2';
};
```
default will be: `M_.init2shocks = {};`
Then we need a new option `init2shocks` for `plot_shock_decomposition(init2shocks)`. If it is called, the preprocessor will trigger
```
options_.plot_shock_decomp.init2shocks = M_.init2shocks;
```
otherwise it should be empty (by default).
```
options_.plot_shock_decomp.init2shocks =[];
```
with this definitions, plot_shock_decompo will attribute the initial condition effect of endo variables to the shock/shock group.4.6documentationenhancementSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1645Provide an example for ramsey_policy and osr2020-01-10T17:30:50ZSébastien VillemotProvide an example for ramsey_policy and osrTo be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.To be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.4.6documentationenhancementJohannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1628Document new preprocessor options2019-10-09T10:33:13ZJohannes Pfeifer Document new preprocessor optionsAs far as I can see, the options `[output=dynamic|first|second|third]` and `[language=julia]` have not yet been documentedAs far as I can see, the options `[output=dynamic|first|second|third]` and `[language=julia]` have not yet been documented4.6documentationpreprocessorhttps://git.dynare.org/Dynare/dynare/-/issues/1586Document initial_condition_decomposition and make it an official feature2019-12-09T14:54:10ZJohannes Pfeifer Document initial_condition_decomposition and make it an official featureStill missing from https://github.com/DynareTeam/dynare/pull/1421Still missing from https://github.com/DynareTeam/dynare/pull/14214.6documentationhttps://git.dynare.org/Dynare/dynare/-/issues/1565initial condition decomposition2019-11-29T16:06:44ZMarco Rattoinitial condition decompositionit would be useful to add interface for the following options:
```
nodisplay
graph_format
fig_name
```
Moreover, the preprocessor should give a lhs arg oo_ when translating the command, i.e.:
`oo_ = initial_condition_decomposition(M_,oo_,options_,var_list_,bayestopt_,estim_params_);`
so not really new options, but just allow those in the pre-processor. many thanks!it would be useful to add interface for the following options:
```
nodisplay
graph_format
fig_name
```
Moreover, the preprocessor should give a lhs arg oo_ when translating the command, i.e.:
`oo_ = initial_condition_decomposition(M_,oo_,options_,var_list_,bayestopt_,estim_params_);`
so not really new options, but just allow those in the pre-processor. many thanks!4.6documentationpreprocessorhttps://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.
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.
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.6documentationJohannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1349set number of threads per job in parallel execution2019-06-19T15:37:45ZMarco Rattoset number of threads per job in parallel executionGiven the large number of CPU's being made available on desktop pc's, the current node option `singleCompThread` looks rather limited.
I would propose the following changes to the parallel configuration:
- set the default for `singleCompThread` to 0;
- add a node option in dynare.ini `numberOfThreadsPerJob`, which allows to set the number of cpu's assigned to each job. So, for example, for a node with 8 CPU's and `numberOfThreadsPerJob=2`, the parallel engine will split the work into 4 parallel instances, each using 2 cpu's.
would this be possible?Given the large number of CPU's being made available on desktop pc's, the current node option `singleCompThread` looks rather limited.
I would propose the following changes to the parallel configuration:
- set the default for `singleCompThread` to 0;
- add a node option in dynare.ini `numberOfThreadsPerJob`, which allows to set the number of cpu's assigned to each job. So, for example, for a node with 8 CPU's and `numberOfThreadsPerJob=2`, the parallel engine will split the work into 4 parallel instances, each using 2 cpu's.
would this be possible?4.5documentationMarco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1309improve documentation of datafile option2019-06-19T15:37:47ZMichelJuillardimprove documentation of datafile optionIn the manual add that if several files differ only by the extension, the filaname must include the extendsion and written between quotes
In the manual add that if several files differ only by the extension, the filaname must include the extendsion and written between quotes
4.5documentationenhancementhttps://git.dynare.org/Dynare/dynare/-/issues/1232Remove onlyclearglobals option2019-06-19T15:37:49ZJohannes Pfeifer Remove onlyclearglobals optionIt was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
It was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
4.5documentationJohannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1177Implement interface for posterior sampling methods2019-06-19T15:37:51ZJohannes Pfeifer Implement interface for posterior sampling methodsRelated to #1174 and #1065
I would propose to use this occasion to further clean up the `options_`-structure and create a field `options_.posterior_sampler_options` that stores as subfields the various options.
The preprocessor should have an option `posterior_sampling_method` that accepts a quoted string that can be `slice`, `random_walk_metropolis_hastings`, `independent_metropolis_hastings` or `tailored_random_block_metropolis_hastings`
It should map into `options_.posterior_sampler_options.posterior_sampling_method` with default
`random_walk_metropolis_hastings`, which replaces the current `options_.posterior_sampling_method`
In addition:
1. We need a subfields `options_.posterior_sampler_options.tarb`, `options_.posterior_sampler_options.rwmh`,`options_.posterior_sampler_options.slice`,
and `options_.posterior_sampler_options.imh` that store the default options for the respective sampler as we already do for different mode_computes.
2. We need the preprocessor to accept name/value pairs like in the already existing `optim`-option in the form of `posterior_sampler_options = (NAME, VALUE,...)`.
It should map into a string `options_.posterior_sampler_options.sampling_opt`, which can then be read out using `read_key_value_string` as we already do in `dynare_minimize_objective`.
3. The already existing but undocumented options `options_.proposal_distribution` and `options_.student_degrees_of_freedom` should now become sampler-specific subfields of the fields introduced in 1.
Related to #1174 and #1065
I would propose to use this occasion to further clean up the `options_`-structure and create a field `options_.posterior_sampler_options` that stores as subfields the various options.
The preprocessor should have an option `posterior_sampling_method` that accepts a quoted string that can be `slice`, `random_walk_metropolis_hastings`, `independent_metropolis_hastings` or `tailored_random_block_metropolis_hastings`
It should map into `options_.posterior_sampler_options.posterior_sampling_method` with default
`random_walk_metropolis_hastings`, which replaces the current `options_.posterior_sampling_method`
In addition:
1. We need a subfields `options_.posterior_sampler_options.tarb`, `options_.posterior_sampler_options.rwmh`,`options_.posterior_sampler_options.slice`,
and `options_.posterior_sampler_options.imh` that store the default options for the respective sampler as we already do for different mode_computes.
2. We need the preprocessor to accept name/value pairs like in the already existing `optim`-option in the form of `posterior_sampler_options = (NAME, VALUE,...)`.
It should map into a string `options_.posterior_sampler_options.sampling_opt`, which can then be read out using `read_key_value_string` as we already do in `dynare_minimize_objective`.
3. The already existing but undocumented options `options_.proposal_distribution` and `options_.student_degrees_of_freedom` should now become sampler-specific subfields of the fields introduced in 1.
4.5documentationestimationhttps://git.dynare.org/Dynare/dynare/-/issues/948Potentially add interface to set parameter bounds for osr.2019-06-19T15:37:58ZJohannes Pfeifer Potentially add interface to set parameter bounds for osr.In principle, there is everything in place to use constrained optimizers with osr. An example on how to use this with a user-defined optimizer wrapper is at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6835
However, we do not provide an interface to set such bounds. We should discuss if we should leave it at that (more work for users) or whether we provide functionality to automatically set the bounds (including their correct ordering in the parameter vector).
In principle, there is everything in place to use constrained optimizers with osr. An example on how to use this with a user-defined optimizer wrapper is at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6835
However, we do not provide an interface to set such bounds. We should discuss if we should leave it at that (more work for users) or whether we provide functionality to automatically set the bounds (including their correct ordering in the parameter vector).
4.5documentationenhancementoptimal policyJohannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/943Update manual on ordering of variables coming from smoother2019-06-19T15:37:58ZJohannes Pfeifer Update manual on ordering of variables coming from smootherSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6020. Needs to be done after #804
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6020. Needs to be done after #804
4.5documentationhttps://git.dynare.org/Dynare/dynare/-/issues/944Fix description of Ramsey timeless perspective in manual2019-06-19T15:37:58ZJohannes Pfeifer Fix description of Ramsey timeless perspective in manualMichel writes:
```
I don't agree with the part on timeless perspective. Setting the initial
multiplier to its steady state value is not timeless
perspective. "Setting the initial Lagrange multipliers as if optimal
policy was started a long time ago" would take into consideration the
value of the initial state variables.
```
Michel writes:
```
I don't agree with the part on timeless perspective. Setting the initial
multiplier to its steady state value is not timeless
perspective. "Setting the initial Lagrange multipliers as if optimal
policy was started a long time ago" would take into consideration the
value of the initial state variables.
```
4.5documentation