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/1765Decide what to do with exogenous deterministic with lead or lag2021-01-22T13:19:33ZSébastien VillemotDecide what to do with exogenous deterministic with lead or lagEndogenous with a lead/lag > 1 and exogenous with a lead/lag are now replaced by auxiliary variables in both stochastic and deterministic mode (see #1112).
However, no such transformation is performed for exogenous deterministic (`varex...Endogenous with a lead/lag > 1 and exogenous with a lead/lag are now replaced by auxiliary variables in both stochastic and deterministic mode (see #1112).
However, no such transformation is performed for exogenous deterministic (`varexo_det`) with lead/lag.
First, we should verify that the current code is not buggy when an exo det is used with a lead/lag (see also #1603).
In any case, it is probably better to homogeneize the treatment across the various types of variables. There are basically two options:
- forbid exo det with lead/lag
- perform the same substitution for those as for “regular” exogenous variables
The first option is of course easier to implement. The second option has the advantage of making things more symmetric, but it’s unclear whether it’s worth it.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1764Document storage of decision rules at order ≥ 42021-03-12T14:00:54ZSébastien VillemotDocument storage of decision rules at order ≥ 4The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1763Ramsey: document potential problems with auxiliary variables for timeless per...2021-08-17T10:24:37ZJohannes PfeiferRamsey: document potential problems with auxiliary variables for timeless perspectiveSee https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/16See https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/165.xhttps://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/1761Method of Moments mode_compute 11 and 122021-01-13T14:59:36ZWilli Mutschlerwilli@mutschler.euMethod of Moments mode_compute 11 and 12In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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/1759Decide whether to drop Windows 7 support2021-11-16T16:29:57ZSébastien VillemotDecide whether to drop Windows 7 supportCurrently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended...Currently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.5.xSébastien VillemotSébastien Villemothttps://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/1757Fix dynare_estimation_1 for order>12021-01-25T18:34:24ZJohannes PfeiferFix dynare_estimation_1 for order>1Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results b...Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results based on a Kalman smoother instead of a particle smoother.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1756Decide what to do with options_.particles.pruning2021-01-25T18:34:24ZJohannes PfeiferDecide what to do with options_.particles.pruningI am having trouble with the `options_.particles.pruning`-option. It is used within the particle filter routines, but currently not inherited for the use of `simult_` in e.g. `non_linear_dsge_likelihood` or `irf.m`. I actually don't see ...I am having trouble with the `options_.particles.pruning`-option. It is used within the particle filter routines, but currently not inherited for the use of `simult_` in e.g. `non_linear_dsge_likelihood` or `irf.m`. I actually don't see why we need that as a separate option of `particles`. I would prefer to have `options_.pruning` and have `particles` rely on it. Or to stay within the module-logic, have `options_.pruning` inherit `options_.particles.pruning`.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1755bug in variable_mapping for Ramsey optimal policy2020-12-09T17:44:43ZMichelJuillardbug in variable_mapping for Ramsey optimal policyIn the preprocessor, for a model using ramsey_model(), variableMapping is empty and in JSON file the field variable_mapping is incomplete. I attach an example generating the problem when run with
```
dynare_m cgg_ramsey.mod json=compute
...In the preprocessor, for a model using ramsey_model(), variableMapping is empty and in JSON file the field variable_mapping is incomplete. I attach an example generating the problem when run with
```
dynare_m cgg_ramsey.mod json=compute
```
[cgg_ramsey.mod](/uploads/a2f584ba20aa90e661a476ee1273a546/cgg_ramsey.mod)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1754Add model_info for non-block models2021-09-15T16:36:15ZJohannes PfeiferAdd model_info for non-block modelsSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variablesSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variables5.xSébastien VillemotSébastien Villemothttps://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/1752Fix identification error with unit root observables and diffuse_filter set2020-11-26T15:41:44ZJohannes PfeiferFix identification error with unit root observables and diffuse_filter setSee [LW_NIC.mod](/uploads/79897cc6c15966c2177cda0cbad032fc/LW_NIC.mod) where the option is correctly set, but we still ask the user to set it.See [LW_NIC.mod](/uploads/79897cc6c15966c2177cda0cbad032fc/LW_NIC.mod) where the option is correctly set, but we still ask the user to set it.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1751Fix encoding of jnl-files2020-11-20T14:54:49ZJohannes PfeiferFix encoding of jnl-filesIt seems the date/time string given by the operating system needs to be converted to UTF-8 [example1.jnl](/uploads/65e2ab3a669e03f39e16ae8dad6fcd53/example1.jnl)It seems the date/time string given by the operating system needs to be converted to UTF-8 [example1.jnl](/uploads/65e2ab3a669e03f39e16ae8dad6fcd53/example1.jnl)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1750Fix Octave mex-files on Windows2020-12-07T11:32:40ZJohannes PfeiferFix Octave mex-files on WindowsOn Windows 10 64bit with Octave 5.2 I am getting the error message
```
error: k_order_pert: could not find library or dependencies: C:\dynare\4.6.2\matlab../mex/octave/win64\k_order_perturbation.mex
```
when using `k_order_solver`. Most...On Windows 10 64bit with Octave 5.2 I am getting the error message
```
error: k_order_pert: could not find library or dependencies: C:\dynare\4.6.2\matlab../mex/octave/win64\k_order_perturbation.mex
```
when using `k_order_solver`. Most likely `libmatio` or `libwinpthread` are the culprits.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1749Fix testsuite for Octave2021-09-21T15:58:35ZWilli Mutschlerwilli@mutschler.euFix testsuite for OctaveOn master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL...On master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL/CentOS, but not Fedora, with KRONFLAG=-1)
- [x] estimation/method_of_moments/* (use nanmean instead of mean(x,'omitnan'; randstream not implemented in Octave;maybe other errors)
- [ ] bgp/* (many problems, probably numerical imprecision, also due to incompatibilities from and differences in toolboxes such as optim)5.xSébastien VillemotSébastien Villemothttps://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/1747bug in macro-processor2020-12-07T11:32:37ZMarco Rattobug in macro-processorwhen using `@#ifndef`, anything after `@#else` is never reached by macro-processor.
See attached test file [test.mod](/uploads/dac7995c3684f9b6a3a935071d05bac6/test.mod) where command in line 6 is never reached by macro-processor when t...when using `@#ifndef`, anything after `@#else` is never reached by macro-processor.
See attached test file [test.mod](/uploads/dac7995c3684f9b6a3a935071d05bac6/test.mod) where command in line 6 is never reached by macro-processor when the macro variable is defined (`@#else` works properly with `@#ifdef`, instead)5.xSébastien VillemotSébastien Villemot