dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-12-22T12:24:02Zhttps://git.dynare.org/Dynare/dynare/-/issues/1766Allow for Herbst-Schorfheide and DS-MH sampler2023-12-22T12:24:02ZJohannes PfeiferAllow for Herbst-Schorfheide and DS-MH samplerSee https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7
First part is done in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884
- [x] The default options for the samplers need to be added to `default_optio...See https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7
First part is done in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884
- [x] The default options for the samplers need to be added to `default_option_values` (done in 128eaa2d)
- [ ] The two routines currently do not provide any return arguments/output7.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1762set_auxiliary_variables function doesn't handle exogenous variables correctly2021-01-11T14:41:53ZMichelJuillardset_auxiliary_variables function doesn't handle exogenous variables correctlyCurrently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. m...Currently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. modify existing Matlab code calling the function
3. The Julia version of the this function should modify ``y`` and ``x`` in place and not return anythinghttps://git.dynare.org/Dynare/dynare/-/issues/1760issue on dynare.jl repo is tracked?2021-01-05T21:22:58ZFlorian Oswaldissue on dynare.jl repo is tracked?hi all,
sorry for cross posting this here but i [left an issue](https://git.dynare.org/Dynare/Dynare.jl/-/issues/5) on the julia version repo and I'm a bit worried it won't get picked up (I had trouble finding it again myself from the D...hi all,
sorry for cross posting this here but i [left an issue](https://git.dynare.org/Dynare/Dynare.jl/-/issues/5) on the julia version repo and I'm a bit worried it won't get picked up (I had trouble finding it again myself from the Dynare.jl dashboard, so...)https://git.dynare.org/Dynare/dynare/-/issues/1758Discuss moving all mod-file output to folder `M_.dname`2023-10-02T15:45:44ZJohannes 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 fileshttps://git.dynare.org/Dynare/dynare/-/issues/1753Build failure with clang C++ compiler (on macOS 10.15 and 11.0)2020-12-01T09:27:35ZFX CoudertBuild failure with clang C++ compiler (on macOS 10.15 and 11.0)Trying to build dynare 4.6.3 on macOS 10.15 and 11.0 fails with:
```
clang++ -std=gnu++17 -Wall -Wno-parentheses -Wold-style-cast -g -O2 -L/usr/local/opt/boost/lib -o dynare_m dynare_m-DynareFlex.o dynare_m-DynareBison.o dynare_m-Comp...Trying to build dynare 4.6.3 on macOS 10.15 and 11.0 fails with:
```
clang++ -std=gnu++17 -Wall -Wno-parentheses -Wold-style-cast -g -O2 -L/usr/local/opt/boost/lib -o dynare_m dynare_m-DynareFlex.o dynare_m-DynareBison.o dynare_m-ComputingTasks.o dynare_m-ModelTree.o dynare_m-StaticModel.o dynare_m-DynamicModel.o dynare_m-NumericalConstants.o dynare_m-NumericalInitialization.o dynare_m-Shocks.o dynare_m-SigmaeInitialization.o dynare_m-SymbolTable.o dynare_m-SymbolList.o dynare_m-ParsingDriver.o dynare_m-DataTree.o dynare_m-ModFile.o dynare_m-ConfigFile.o dynare_m-Statement.o dynare_m-ExprNode.o dynare_m-MinimumFeedbackSet.o dynare_m-DynareMain.o dynare_m-DynareMain1.o dynare_m-DynareMain2.o dynare_m-ExternalFunctionsTable.o dynare_m-ModelEquationBlock.o dynare_m-WarningConsolidation.o dynare_m-SubModel.o macro/libmacro.a -lstdc++fs
ld: library not found for -lstdc++fs
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
The C/C++ compiler is clang 12, the system compiler. The Fortran compiler is gfortran 10. We configure with:
./configure --disable-debug --disable-dependency-tracking --disable-silent-rules --prefix=/usr/local/Cellar/dynare/4.6.3 --disable-matlab --with-slicot=/private/tmp/dynare-20201123-18116-o8kpbx/dynare-4.6.3/slicot --with-boost=/usr/local/opt/boost --disable-doc
This is part of Homebrew building for distribution: https://github.com/Homebrew/homebrew-core/pull/65956https://git.dynare.org/Dynare/dynare/-/issues/1748bug in preprocessor for configuration file for parallel2020-11-18T14:31:45ZMarco Rattobug in preprocessor for configuration file for parallelCurrently, the preprocessor reads the `DynarePath` field in the configuration file, but it stores it into the `ProgramPath` field of `options_.parallel`. It should be ported into a `DynarePath` field, obviously.
note: `ProgramPath` woul...Currently, the preprocessor reads the `DynarePath` field in the configuration file, but it stores it into the `ProgramPath` field of `options_.parallel`. It should be ported into a `DynarePath` field, obviously.
note: `ProgramPath` would be the ultimate notation once I finish the merge with `DragonFly` ..., but for the time being the usual behaviour should be preserved.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2023-09-27T15:13:11ZSé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`.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2023-10-02T15:42:24ZMichelJuillardAdding support for dates in perfect_foresight_setupThe user should be able to control the dates of the dseries produced by `perfect_foresight_solver`
- Currently, `histval`, `histval_file` and `initval_file` pass a `dseries` to `perfect_foresight_setup`
- By default, ``perfect_foresight_...The user should be able to control the dates of the dseries produced by `perfect_foresight_solver`
- Currently, `histval`, `histval_file` and `initval_file` pass a `dseries` to `perfect_foresight_setup`
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this `dseries`
- dates must be permitted in `histval` instead of only signed integers
- `first_obs`: sets the dates used for the first initial conditions. Must be consistent with `histval` or `histval_file` if they are used
- `first_simulation_period`: sets the dates used for the first period of the simulation. It is an alternative to specifying `first_obs` and must be consistent if `first_obs` is also used as an option. Values for initial conditions before this date must be available. Must be consistent with `histval` or `histval_file` if they are used.
- `last_simulation_period`: sets the date of the last period of simulation. It is an alternative to specifying `periods` and must be consistent if `periods` is also used as an option. Data for terminal conditions past the last period must be availablehttps://git.dynare.org/Dynare/dynare/-/issues/1738Publication-quality plots2020-07-15T10:44:06ZWilli Mutschlerwilli@mutschler.euPublication-quality plotsMatlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is...Matlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?https://git.dynare.org/Dynare/dynare/-/issues/1736Display of simulated moments: introduce cutoff for 0 variables2020-09-03T14:45:13ZJohannes PfeiferDisplay of simulated moments: introduce cutoff for 0 variablesSee the problem in https://forum.dynare.org/t/question-on-ramsey-example-mod/16113See the problem in https://forum.dynare.org/t/question-on-ramsey-example-mod/16113https://git.dynare.org/Dynare/dynare/-/issues/1732Improve debugging options for perfect foresight2021-03-25T16:08:29ZJohannes PfeiferImprove debugging options for perfect foresightWe occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. ...We occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`. Two test cases are attached, one for `sim1` and one for `sim1_linear`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)
[code_14_march.mod](/uploads/715a4d7c3f3e4485d60919247ccb11c8/code_14_march.mod)Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1730Consider saving results using -v7.3 flag2020-11-13T13:08:07ZJohannes PfeiferConsider saving results using -v7.3 flagWe may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.We may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.https://git.dynare.org/Dynare/dynare/-/issues/1729Suggestion: Provide unstable builds of current major version branch (e.g. 4.6...2020-06-05T16:58:28ZTom HoldenSuggestion: Provide unstable builds of current major version branch (e.g. 4.6 at present) as well as builds of the master branchIt would be good if as well as providing unstable builds of the master branch, unstable builds of the current major version branch were also provided (e.g. the 4.6 branch at present).
While people can of course compile this themselves, ...It would be good if as well as providing unstable builds of the master branch, unstable builds of the current major version branch were also provided (e.g. the 4.6 branch at present).
While people can of course compile this themselves, in practice this is quite onerous.https://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2024-03-26T09:53:46ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16537.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1719Allow running shock_decomposition on simulated model2020-03-31T16:18:23ZJohannes PfeiferAllow running shock_decomposition on simulated modelCurrently, `shock_decomposition` only allows for
```
if isempty(parameter_set)
if isfield(oo_,'posterior_mean')
parameter_set = 'posterior_mean';
elseif isfield(oo_,'mle_mode')
parameter_set = 'mle_mode';
else...Currently, `shock_decomposition` only allows for
```
if isempty(parameter_set)
if isfield(oo_,'posterior_mean')
parameter_set = 'posterior_mean';
elseif isfield(oo_,'mle_mode')
parameter_set = 'mle_mode';
elseif isfield(oo_,'posterior')
parameter_set = 'posterior_mode';
else
error(['shock_decomposition: option parameter_set is not specified ' ...
'and posterior mode is not available'])
end
end
```
but then we call `evaluate_smoother`, where we allow for
```
switch parameters
case 'posterior_mode'
parameters = get_posterior_parameters('mode',M_,estim_params_,oo_,options_);
case 'posterior_mean'
parameters = get_posterior_parameters('mean',M_,estim_params_,oo_,options_);
case 'posterior_median'
parameters = get_posterior_parameters('median',M_,estim_params_,oo_,options_);
case 'mle_mode'
parameters = get_posterior_parameters('mode',M_,estim_params_,oo_,options_,'mle_');
case 'prior_mode'
parameters = bayestopt_.p5(:);
case 'prior_mean'
parameters = bayestopt_.p1;
case 'calibration'
if isempty(oo_.dr)
error('You must run ''stoch_simul'' first.');
end
parameters = [];
```https://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes PfeiferFix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveB...As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1714`get_error_message` does not return an output when `options_.noprint = 1`2020-03-10T08:26:24ZAliaksandr Zaretski`get_error_message` does not return an output when `options_.noprint = 1`The function `get_error_message` must return an output, but does so only when `options_.noprint = 0`. Hence, there is an unexpected error message when both `info(1) > 0` and `options_.noprint = 1`. To replicate, see attached [example1_ed...The function `get_error_message` must return an output, but does so only when `options_.noprint = 0`. Hence, there is an unexpected error message when both `info(1) > 0` and `options_.noprint = 1`. To replicate, see attached [example1_ed.mod](/uploads/f0716731f7540ce7030e68dd2e5de1eb/example1_ed.mod), where I set `alpha = -0.36` to generate an error and added the `noprint` option. See attached slightly revised [print_info.m](/uploads/30439caa39aacbdac9f9e1b2a644483b/print_info.m) and [get_error_message.m](/uploads/c15787c57bb9e46b6a3136be9a803db9/get_error_message.m) where the issue is solved.https://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.