dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:41Zhttps://git.dynare.org/Dynare/dynare/-/issues/295offer a quiet and a verbose mode2019-06-19T15:37:41ZSébastien Villemotoffer a quiet and a verbose modeSome users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never ...Some users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
https://git.dynare.org/Dynare/dynare/-/issues/294rework option handling2022-06-02T13:55:11ZSébastien Villemotrework option handlingIt's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something t...It's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.https://git.dynare.org/Dynare/dynare/-/issues/291bugs related to auxiliary variables for lagged exogenous variables2013-02-21T14:54:09ZSébastien Villemotbugs related to auxiliary variables for lagged exogenous variablesIn ./tests/auxiliary_variables/test2.mod, the preprocessor fails to create auxiliary variable for lagged exogenous one.
When that is fixed, it will be necessary to check that the derivatives of the definition of the auxiliary variable i...In ./tests/auxiliary_variables/test2.mod, the preprocessor fails to create auxiliary variable for lagged exogenous one.
When that is fixed, it will be necessary to check that the derivatives of the definition of the auxiliary variable is correctly added to test2_static.m
When test2.mod runs correctly, please add it to ./tests/Makefile.am
https://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....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/292model_diagnostics and lead/lag on exogenous variables2013-02-21T14:54:09ZSébastien Villemotmodel_diagnostics and lead/lag on exogenous variablesmodel_diagnostics breaks when there are longer lead/lag on exogenous variables than endogenous ones
model_diagnostics breaks when there are longer lead/lag on exogenous variables than endogenous ones
https://git.dynare.org/Dynare/dynare/-/issues/290Estimation+moments_varendo does not always deliver autocorrelation function2013-03-27T13:12:56ZSébastien VillemotEstimation+moments_varendo does not always deliver autocorrelation functionEven when option ar > 1, oo_.PosteriorTheoreticalMoments.mean.var1.var2 seems to be a scalar.
Even when option ar > 1, oo_.PosteriorTheoreticalMoments.mean.var1.var2 seems to be a scalar.
4.4Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/287Test System: Support test we expect to fail2013-02-21T14:54:09ZSébastien VillemotTest System: Support test we expect to failShould report in a different category from regular tests: XFAIL and XPASS. XFAIL will show the tests that were expected to fail and failed. XPASS will show the tests that were expected to fail and passed.
Should report in a different category from regular tests: XFAIL and XPASS. XFAIL will show the tests that were expected to fail and failed. XPASS will show the tests that were expected to fail and passed.
https://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 ...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/289make -j doesn't work in clean work directory2013-02-21T14:54:09ZSébastien Villemotmake -j doesn't work in clean work directoryfor make -j to work for dynare++, it is necessary to check that the code files and headers are ctangle BEFORE being used in compilation
for make -j to work for dynare++, it is necessary to check that the code files and headers are ctangle BEFORE being used in compilation
https://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/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/282change console mode so that no figures are displayed2013-02-21T14:54:08ZSébastien Villemotchange console mode so that no figures are displayedCurrently, under console mode, Dynare does not display graphical wait bars in Matlab (see http://www.dynare.org/manual/index_9.html#Dynare-invocation ). Change this Dynare not display any figures either, the way you would expect console ...Currently, under console mode, Dynare does not display graphical wait bars in Matlab (see http://www.dynare.org/manual/index_9.html#Dynare-invocation ). Change this Dynare not display any figures either, the way you would expect console mode to work.
https://git.dynare.org/Dynare/dynare/-/issues/283In Matlab, check whether nojvm or nodisplay were passed2013-02-21T14:54:08ZSébastien VillemotIn Matlab, check whether nojvm or nodisplay were passedIf nodisplay was passed, change to console mode as default
If nojvm was passed, potentially do the same or, perhaps, don't create figures at all....
If nodisplay was passed, change to console mode as default
If nojvm was passed, potentially do the same or, perhaps, don't create figures at all....
https://git.dynare.org/Dynare/dynare/-/issues/281Fix Bug in random_walk_metropolis_hastings_core2013-02-21T14:54:08ZSébastien VillemotFix Bug in random_walk_metropolis_hastings_coreCurrently, mode_compute=0 only allows for providing a mode_file from mode_compute=6 and automatically loading optimal_mh_scale_parameter.mat from a former run of mode_compute=6.
We need to implement a more flexible version that allows fo...Currently, mode_compute=0 only allows for providing a mode_file from mode_compute=6 and automatically loading optimal_mh_scale_parameter.mat from a former run of mode_compute=6.
We need to implement a more flexible version that allows for
i) loading mode-files from other optimizers and
ii) in the case of using a mode-file from mode_compute=6 to provide a different mh_jscale than contained in the optimal_mh_scale_parameter.mat
This most probably requires changes in the preprocessor to detect if mh_jscale was specified by the user (or just set by default in global_initialization). Moreover, we need mode_compute=0 to be able to detect which optimizer created the mode-file so it knows when the file was generated by mode_compute =6 and should thus load optimal_mh_scale_parameter.mat (unless mh_jscale was explicitly specified)
Alternatively, one could force users to provide a "mh_scale_parameter_file"-option in the estimation command. In this case, Dynare will load the file if specified and otherwise use either the default or the specified mh_jscale. However, this solution would break backward-compatibility.
https://git.dynare.org/Dynare/dynare/-/issues/280Implement @#ifndef2013-02-21T14:54:08ZSébastien VillemotImplement @#ifndefhttps://git.dynare.org/Dynare/dynare/-/issues/279add --with-slicot and --with-matio options to configure2013-02-21T14:54:08ZSébastien Villemotadd --with-slicot and --with-matio options to configureAdd m4/ax_slicot.m4 and m4/ax_matio.m4 to conform with --with-gsl.
Add m4/ax_slicot.m4 and m4/ax_matio.m4 to conform with --with-gsl.
https://git.dynare.org/Dynare/dynare/-/issues/278Improve documentation of conditional_variance_decomposition and moments2013-03-19T08:33:29ZSébastien VillemotImprove documentation of conditional_variance_decomposition and moments1. The option conditional_variance_decomposition in stoch_simul only triggers the decomposition, if theoretical moments are requested, i.e. periods=0. We should add a warning in the code and in the manual
2. Even if one specifies order=2...1. The option conditional_variance_decomposition in stoch_simul only triggers the decomposition, if theoretical moments are requested, i.e. periods=0. We should add a warning in the code and in the manual
2. Even if one specifies order=2 (with periods=0), Dynare still outputs a variance_decomposition, but the decomposition is based on the first order state-space system. We should add a warning for all second order moments as the same is true for variance, correlations, and autocorrelations
4.4https://git.dynare.org/Dynare/dynare/-/issues/277mex problem with Matlab 7.1 under Windows XP2013-02-21T14:54:08ZSébastien Villemotmex problem with Matlab 7.1 under Windows XPI have received the following error message
??? Invalid MEX-file 'C:\JIJI\Dynare\4.3.0\matlab..\mex\matlab\win32-7.1-7.4\mjdgges.mexw32': La procédure spécifiée est introuvable.
Windows XP
Matlab 7.1
the same problem exists with Dynare...I have received the following error message
??? Invalid MEX-file 'C:\JIJI\Dynare\4.3.0\matlab..\mex\matlab\win32-7.1-7.4\mjdgges.mexw32': La procédure spécifiée est introuvable.
Windows XP
Matlab 7.1
the same problem exists with Dynare unstable. Dynare version 4.2.4 used to work
https://git.dynare.org/Dynare/dynare/-/issues/276Add ar-option to estimation command2013-02-21T14:54:08ZSébastien VillemotAdd ar-option to estimation commandCurrently, the ar-option is only allowed in stoch_simul. Its value then also tranfers to the computation of moments in compute_moments_varendo.m. We should explicitly implement ar in estimation. If specified, it should also trigger the m...Currently, the ar-option is only allowed in stoch_simul. Its value then also tranfers to the computation of moments in compute_moments_varendo.m. We should explicitly implement ar in estimation. If specified, it should also trigger the moments_varendo option. This avoids setting options_.ar before the estimation command. Maybe we should split options_.ar into options_.ar for stoch_simul and options_.var_endo_ar for estimation in order for one command not to affect the computations from the other one as is currently the case.