dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2013-09-16T20:15:23Zhttps://git.dynare.org/Dynare/dynare/-/issues/1Don't fail when initializing an unknown variable in initval2013-09-16T20:15:23ZSébastien VillemotDon't fail when initializing an unknown variable in initvalThis is a request from Pascal Jacquinot, in order to facilitate the development phase of a model.
This is a request from Pascal Jacquinot, in order to facilitate the development phase of a model.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/2Be more flexible about variable declarations2020-03-12T17:12:34ZSébastien VillemotBe more flexible about variable declarationsRequest by Pascal Jacquinot, in order to facilitate model development.
If I understand correctly, he would like that Dynare simply ignores endogenous/exogenous variables that are never used in the model (instead of complaining about number of variables ≠ number of equations)
Request by Pascal Jacquinot, in order to facilitate model development.
If I understand correctly, he would like that Dynare simply ignores endogenous/exogenous variables that are never used in the model (instead of complaining about number of variables ≠ number of equations)
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/3When the steady state computation fail, give the user a possibility to see wh...2015-07-27T19:50:16ZSébastien VillemotWhen the steady state computation fail, give the user a possibility to see where the computation stoppedRequest by Pascal Jacquinot.
Request by Pascal Jacquinot.
4.5https://git.dynare.org/Dynare/dynare/-/issues/23Add Estimation DLL2016-06-10T12:50:14ZSébastien VillemotAdd Estimation DLLFor DSGE-net.
For DSGE-net.
4.5https://git.dynare.org/Dynare/dynare/-/issues/136complete implementation of "shock_decomposition"2016-04-15T07:45:56ZSébastien Villemotcomplete implementation of "shock_decomposition"add options for grouping shocks together and for choosing the set of parameters to be used
add options for grouping shocks together and for choosing the set of parameters to be used
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/148Integrate dr_block.m into the new structure for stochastic solvers2016-06-10T12:49:08ZSébastien VillemotIntegrate dr_block.m into the new structure for stochastic solvers4.5FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/-/issues/166fix computation of the planner objective under Ramsey policy2013-12-13T09:55:28ZSébastien Villemotfix computation of the planner objective under Ramsey policyThe call to "evaluate_planner_objective" was commented out in f36247ceedb73ebab6be0bbc736fc6f5ce3f3bb1.
The call to "evaluate_planner_objective" was commented out in f36247ceedb73ebab6be0bbc736fc6f5ce3f3bb1.
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/236Add a user friendly frontend to simult_2015-08-06T13:27:23ZSébastien VillemotAdd a user friendly frontend to simult_The idea is to give an user-friendly way to perform simulations of a model using custom series of shocks; this is a recurring request.
The idea is to give an user-friendly way to perform simulations of a model using custom series of shocks; this is a recurring request.
4.5https://git.dynare.org/Dynare/dynare/-/issues/238Add interface for convergence tolerance criterions (and maybe rename internal...2016-06-10T12:47:35ZSébastien VillemotAdd interface for convergence tolerance criterions (and maybe rename internal options)Currently we have 4 options for convergence criterions:
- options_.dynatol.f
- options_.dynatol.x
- options_.solve_tolf
- options_.solve_tolx
The first two are for the deterministic solution, the last two for the steady state.
We should add a preprocessor interface to these options.
Also, it would make sense to rename them for more homogeneity. I suggest the following renaming scheme:
- options_.dynatol.f => options_.simul_tolf
- options_.dynatol.x => options_.simul_tolx
- options_.solve_tolf => options_.steady_tolf
- options_.solve_tolx => options_.steady_tolx
Currently we have 4 options for convergence criterions:
- options_.dynatol.f
- options_.dynatol.x
- options_.solve_tolf
- options_.solve_tolx
The first two are for the deterministic solution, the last two for the steady state.
We should add a preprocessor interface to these options.
Also, it would make sense to rename them for more homogeneity. I suggest the following renaming scheme:
- options_.dynatol.f => options_.simul_tolf
- options_.dynatol.x => options_.simul_tolx
- options_.solve_tolf => options_.steady_tolf
- options_.solve_tolx => options_.steady_tolx
4.5https://git.dynare.org/Dynare/dynare/-/issues/254UnivariateSpectralDensity.m must be implemented to preprocessor and documented.2016-03-23T13:22:33ZSébastien VillemotUnivariateSpectralDensity.m must be implemented to preprocessor and documented.The SpectralDensity option of stoch_simul is neither documented nor implemented in the preprocessor.
It could be implemented as an option of stoch_simul().
Alternatively, we could use a preprocessor command along the lines
spectral_density_decomposition(plot=integer,cutoff=number,step_length= number);
which translates into
options_.SpectralDensity.trigger = 1;
options_.SpectralDensity.plot = integer;
options_.SpectralDensity.cutoff = number;
options_.SpectralDensity.sdl = number;
The SpectralDensity option of stoch_simul is neither documented nor implemented in the preprocessor.
It could be implemented as an option of stoch_simul().
Alternatively, we could use a preprocessor command along the lines
spectral_density_decomposition(plot=integer,cutoff=number,step_length= number);
which translates into
options_.SpectralDensity.trigger = 1;
options_.SpectralDensity.plot = integer;
options_.SpectralDensity.cutoff = number;
options_.SpectralDensity.sdl = number;
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/260implement trust-region method for non-linear solver2014-02-04T16:56:31ZSébastien Villemotimplement trust-region method for non-linear solverThe code in solve1.m to deal with the case where the Jacobian is near singular is unsatisfactory. We need to implement a trust region method as discussed in Nocedal and Wright (2006. This could also be done for the non-linear solver of bytecode
The code in solve1.m to deal with the case where the Jacobian is near singular is unsatisfactory. We need to implement a trust region method as discussed in Nocedal and Wright (2006. This could also be done for the non-linear solver of bytecode
4.5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/261Option to require that all endo/exo are initialized in initval2016-06-02T10:58:44ZSébastien VillemotOption to require that all endo/exo are initialized in initvalImplement a new option to initval command, "all_values_required". The preprocessor would stop and reports which endogenous or exogenous variable has not been explicitly initialized if any (instead of using a default zero value).
Request from the IMF for GIMF
Implement a new option to initval command, "all_values_required". The preprocessor would stop and reports which endogenous or exogenous variable has not been explicitly initialized if any (instead of using a default zero value).
Request from the IMF for GIMF
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/284check values returned by likelihood functions and their use in calling functions2015-05-09T12:27:03ZSébastien Villemotcheck values returned by likelihood functions and their use in calling functionscheck value of fval when returned by DsgeVarLikelihood.m and non_linear_dsge_likelihood.m.
Check the use of fval and exit_flag in the functions calling dsge_likelihood.m, DsgeVarLikelihood.m and non_linear_dsge_likelihood.m
check value of fval when returned by DsgeVarLikelihood.m and non_linear_dsge_likelihood.m.
Check the use of fval and exit_flag in the functions calling dsge_likelihood.m, DsgeVarLikelihood.m and non_linear_dsge_likelihood.m
4.5https://git.dynare.org/Dynare/dynare/-/issues/286Add treatment of missing values to manual2014-01-30T16:58:08ZSébastien VillemotAdd treatment of missing values to manualCurrently, there is no information in the manual on how missing data values are treated. See also [http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4178]
Currently, there is no information in the manual on how missing data values are treated. See also [http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4178]
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/288Expand information stored about model variables in preprocessor2016-06-10T12:45:14ZSébastien VillemotExpand information stored about model variables in preprocessorFrom Michel:
In the preprocessor, we need the full analysis of the dynamic structure of the model. Lists of lagged variables, forward variables, variables that are both lagged and forward, static variables.
Currently, this analysis is done in `set_state_space.m` except when `block` option is used, then @FerhatMihoubi does it in the preprocessor.
We need to think about the structure in which to store this information, so it requires a little planning.
The goal is to remove `set_state_space.m`.
From Michel:
In the preprocessor, we need the full analysis of the dynamic structure of the model. Lists of lagged variables, forward variables, variables that are both lagged and forward, static variables.
Currently, this analysis is done in `set_state_space.m` except when `block` option is used, then @FerhatMihoubi does it in the preprocessor.
We need to think about the structure in which to store this information, so it requires a little planning.
The goal is to remove `set_state_space.m`.
4.5https://git.dynare.org/Dynare/dynare/-/issues/293bug: maxit option in steady2019-02-08T08:31:00ZSébastien Villemotbug: maxit option in steadyCurrently, the preprocessor assigns the maxit option for the steady command to options_.maxit_ and it is used in dynare_solve_block_bytecode.m for finding the steady state; dynare_solve.m, on the other hand, uses options_.solve_maxit (i.e. an option not passed to steady) for solve_algo = 1 or 2, whereas for solve_algo = 0 or 3 the values are hard-coded.
This needs to be made uniform. Stephane suggests assigning maxit to options_.solve_maxit in the preprocessor, changing dynare_solve_block_bytecode.m to use options_.solve_maxit, and replacing the hard-coded values in dynare_solve.m with this option as well.
Currently, the preprocessor assigns the maxit option for the steady command to options_.maxit_ and it is used in dynare_solve_block_bytecode.m for finding the steady state; dynare_solve.m, on the other hand, uses options_.solve_maxit (i.e. an option not passed to steady) for solve_algo = 1 or 2, whereas for solve_algo = 0 or 3 the values are hard-coded.
This needs to be made uniform. Stephane suggests assigning maxit to options_.solve_maxit in the preprocessor, changing dynare_solve_block_bytecode.m to use options_.solve_maxit, and replacing the hard-coded values in dynare_solve.m with this option as well.
4.5https://git.dynare.org/Dynare/dynare/-/issues/302dynSeries: enable excel files to be read in2013-11-12T09:14:03ZSébastien VillemotdynSeries: enable excel files to be read increate load_xls_file_data.m like load_csv_file_data.m
create load_xls_file_data.m like load_csv_file_data.m
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/304Add the possibility of interrupting MEX files during computation with Ctrl-C2014-10-24T14:35:57ZSébastien VillemotAdd the possibility of interrupting MEX files during computation with Ctrl-CEspecially useful for bytecode and estimation DLLs.
The natural way would be to intercept the SIGINT signal within the MEX, but this is not possible with MATLAB. Maybe this is possible under Octave, we must check.
For MATLAB, there is an undocumented function `utIsInterrupt()` in `libut`, which must be polled at regular intervals. This seems to be working under Windows. Need to check under GNU/Linux and MacOSX.
Especially useful for bytecode and estimation DLLs.
The natural way would be to intercept the SIGINT signal within the MEX, but this is not possible with MATLAB. Maybe this is possible under Octave, we must check.
For MATLAB, there is an undocumented function `utIsInterrupt()` in `libut`, which must be polled at regular intervals. This seems to be working under Windows. Need to check under GNU/Linux and MacOSX.
4.5https://git.dynare.org/Dynare/dynare/-/issues/331Add reset option to shocks-block2015-09-07T10:08:50ZJohannes Pfeifer Add reset option to shocks-blockCurrently the only way to set a different covariance matrix of structural shocks and measurement errors is to manually set all elements that differ from the previous shocks-statement. It would be nice to have something like
```
shocks(reset);
var e; stderr 0.9;
end;
```
that sets all elements of the M_.Sigma_e and M_.H to 0 before filling it again with the entries of the shocks-block.
Currently the only way to set a different covariance matrix of structural shocks and measurement errors is to manually set all elements that differ from the previous shocks-statement. It would be nice to have something like
```
shocks(reset);
var e; stderr 0.9;
end;
```
that sets all elements of the M_.Sigma_e and M_.H to 0 before filling it again with the entries of the shocks-block.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/332Add functionality to compute function on posterior2015-10-12T05:18:33ZJohannes Pfeifer Add functionality to compute function on posteriorCurrently, it is very hard to compute a user defined function on the posterior draws. A user asked me if we could add a functionality where the user specifies a function name which is executed on each posterior draw when we compute posterior moments. For such a function call, we would need to clearly specify the interface. We might want to provide M_, oo_, bayestopt_, estim_params_ and the current parameter draw as generic inputs (and nothing else). The tricky part consists of specifying the output arguments and making sure we can save them. One way would be to only accept one output argument and save it to the ii element of a cell array. By putting multiple outputs into a structure, the user could still effectively save multiple outputs while keeping a clearly specified interface for us.
Upon going over all draws, we would just save the cell array to the disk. It would be up to the user to make sense of the saved stuff.
Currently, it is very hard to compute a user defined function on the posterior draws. A user asked me if we could add a functionality where the user specifies a function name which is executed on each posterior draw when we compute posterior moments. For such a function call, we would need to clearly specify the interface. We might want to provide M_, oo_, bayestopt_, estim_params_ and the current parameter draw as generic inputs (and nothing else). The tricky part consists of specifying the output arguments and making sure we can save them. One way would be to only accept one output argument and save it to the ii element of a cell array. By putting multiple outputs into a structure, the user could still effectively save multiple outputs while keeping a clearly specified interface for us.
Upon going over all draws, we would just save the cell array to the disk. It would be up to the user to make sense of the saved stuff.
4.5