dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2024-01-29T20:57:50Zhttps://git.dynare.org/Dynare/dynare/-/issues/1688fix `basic_plan`, `flip_plan` in doc2024-01-29T20:57:50ZHoutan Bastanifix `basic_plan`, `flip_plan` in docThe calling structure for both of these functions runs off the end of the pageThe calling structure for both of these functions runs off the end of the page6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1680Adapt evaluate_planner_objective.m to higher order and perfect foresight2022-09-07T12:30:49ZJohannes PfeiferAdapt evaluate_planner_objective.m to higher order and perfect foresightSupersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492
Remaining:
- [x] fixi...Supersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492
Remaining:
- [x] fixing or documenting the regression in behavior introduced in e880d1bc. In contrast to previous behavior `histval` will be ignored. `planner_objective_value` now returns conditional and unconditional welfare instead of welfare for different values of the Lagrange multiplier. (done in !1923)
- [x] the question of an interface for setting the initial condition (https://git.dynare.org/Dynare/preprocessor/-/issues/64)
- [x] Adding higher order results to `evaluate_planner_objective`
- [x] Compute unconditional welfare at order>2
- [x] Documenting the recent changes6.xNormann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1660Update documentation of dseries2024-01-29T20:51:00ZSébastien VillemotUpdate documentation of dseriesSince dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.Since dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1611Make dynare_sensitivity compatible with recursive estimation or provide infor...2024-01-17T20:31:14ZJohannes PfeiferMake dynare_sensitivity compatible with recursive estimation or provide informative errorSee https://forum.dynare.org/t/calculating-rmses/11903See https://forum.dynare.org/t/calculating-rmses/119036.xhttps://git.dynare.org/Dynare/dynare/-/issues/1593Add truncated priors2023-09-07T06:56:27ZJohannes PfeiferAdd truncated priorsFollowing the discussions in #1591 and #750, we currently do not have a way to introduce a proper truncated prior. But this is an often requested feature that e.g. @rattoma would like to have. Waiting for the new estimation interface (e....Following the discussions in #1591 and #750, we currently do not have a way to introduce a proper truncated prior. But this is an often requested feature that e.g. @rattoma would like to have. Waiting for the new estimation interface (e.g. #824 and #846) seems to long to wait.
My specific proposal would be to add a new token `truncated_norm_pdf` that uses the third and fourth hyperparameter (which is usually reserved for generalized (beta) distributions) to specify the truncation. I consider this a natural interpretation of these hyperparameters for the normal distribution.
@stepan-a What do you think?
@rattoma Woud that satisfy your immediate needs? Or do you need a truncated distribution other than the normal?6.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1573Allow mode_compute to be a vector2023-09-20T08:18:23ZJohannes PfeiferAllow mode_compute to be a vectorAllow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.Allow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/630Improving Ramsey computations2021-09-14T16:48:39ZMichelJuillardImproving Ramsey computations- [ ] adding the possibility to use one of the parameters of the model as the planner_discount factor
- [x] give independent access to the fonction evaluating the objective function- [ ] adding the possibility to use one of the parameters of the model as the planner_discount factor
- [x] give independent access to the fonction evaluating the objective function6.xMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/349Use preprocessor for variable transformation (e.g. exp for doing approximatio...2023-09-27T15:19:08ZJohannes PfeiferUse preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use...An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1927oo_ used but undefined in +occbin/kalman_update_algo_3.m2024-03-27T14:03:31ZSébastien Villemotoo_ used but undefined in +occbin/kalman_update_algo_3.mLine 259 of `matlab/+occbin/kalman_update_algo_3.m` reads:
```
[~, out, ss] = occbin.solver(M_,oo_,options_);
```
But `oo_` is undefined in that file.
I encountered this error when running `calib_smoother` after `oc...Line 259 of `matlab/+occbin/kalman_update_algo_3.m` reads:
```
[~, out, ss] = occbin.solver(M_,oo_,options_);
```
But `oo_` is undefined in that file.
I encountered this error when running `calib_smoother` after `occbin_setup`.https://git.dynare.org/Dynare/dynare/-/issues/1926No dates in Matlab plot when plotting2024-03-19T13:02:54ZRaphaël MARTINNo dates in Matlab plot when plottingDear Dynare Team,
I hope this message finds you well. I am reaching out to discuss an observation regarding the plot() function as described in the Dynare documentation. It is mentioned that the function "overloads MATLAB/Octave’s `plot...Dear Dynare Team,
I hope this message finds you well. I am reaching out to discuss an observation regarding the plot() function as described in the Dynare documentation. It is mentioned that the function "overloads MATLAB/Octave’s `plot` function for `dseries` objects. Returns a MATLAB/Octave plot handle, that can be used to modify the properties of the plotted time series. If only one `dseries` object, `A`, is passed as argument, **then the plot function will put the associated dates on the x-abscissa**". However, in practice, when plotting a simple dseries, the x-axis displays the periods numerically (e.g., 1, 2, 3, etc.) rather than showing the specific dates as intended.
I've managed to devise a workaround for this issue and am sharing it here, hoping it might benefit others facing the same problem.
```
A=dseries([1;2;3],'2020Y','toto');
% This plot doesn't show dates
plot(A)
% Dates for the plot's legend
DsDates = firstobservedperiod(A):lastobservedperiod(A);
x_Labels= cell(1,length(DsDates));
% Transforms dseries dates into characters
for i = 1:length(DsDates)
x_Labels{i} = char(DsDates(i));
end
% This one does
figure()
hold on
xticks(1:length(DsDates));
xticklabels(x_Labels);
plot(A)
```https://git.dynare.org/Dynare/dynare/-/issues/1925Issues when modifying values of dseries on a loop2024-03-12T10:40:40ZRaphaël MARTINIssues when modifying values of dseries on a loopDear Dynare Team,
As a new user of Dynare, I'm reaching out to report a potential bug I've encountered while working with dseries objects in Matlab, specifically using the latest unstable version of Dynare. This is my first time reporti...Dear Dynare Team,
As a new user of Dynare, I'm reaching out to report a potential bug I've encountered while working with dseries objects in Matlab, specifically using the latest unstable version of Dynare. This is my first time reporting an issue, so please excuse any inadvertent mistakes in my submission. I've noticed an issue where modifying the value of a second dseries object (which was initially set to be equal to a first dseries object) inadvertently alters the values of the first dseries object as well. This behavior is unexpected and seems to occur when the modifications are made within a loop. Here is a quick code snippet illustrating this bug :
```
addpath 'C:\Produits\dynare\dynare-7-unstable-2024-03-04-1703-7d332dee'
dynare_config;
A=dseries([0;0;0],'2020Y','toto');
B=A;
for i=1:length(B.dates)
B(B.dates(i))=B(B.dates(i))+1;
end
disp(A)
disp(B)
```https://git.dynare.org/Dynare/dynare/-/issues/1924[New feature] Add Taylor projection method of Levintal2024-03-04T15:13:48ZWilli Mutschlerwilli@mutschler.eu[New feature] Add Taylor projection method of LevintalI am working on a project with rare disaster models and am looking into the Taylor Projection solution method. I think it is general enough to also incorporate into Dynare, might be a nice new feature for 7.0.I am working on a project with rare disaster models and am looking into the Taylor Projection solution method. I think it is general enough to also incorporate into Dynare, might be a nice new feature for 7.0.7.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1923Dynare 6.x incorrectly assumes Suites-Parse lives in the same directory as Oc...2024-03-06T18:56:06ZSean MolenaarDynare 6.x incorrectly assumes Suites-Parse lives in the same directory as OctaveThe Meson build seems to search for umfpack relative to the octave directory,
but that might not be the place it is installed.
The Homebrew team ran into this in: https://github.com/Homebrew/homebrew-core/pull/164010
I believe this sea...The Meson build seems to search for umfpack relative to the octave directory,
but that might not be the place it is installed.
The Homebrew team ran into this in: https://github.com/Homebrew/homebrew-core/pull/164010
I believe this search should either come through pkg-config or search the whole include path.https://git.dynare.org/Dynare/dynare/-/issues/1922Create GitLab CI to build, test and deploy docker containers2024-02-22T10:22:30ZWilli Mutschlerwilli@mutschler.euCreate GitLab CI to build, test and deploy docker containersIt would be beneficial to have a workflow with GitLab to build, test and deploy the docker containers.It would be beneficial to have a workflow with GitLab to build, test and deploy the docker containers.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1921Rebase docker containers on Debian2024-02-16T09:37:44ZWilli Mutschlerwilli@mutschler.euRebase docker containers on DebianCurrently the Docker images are based on images that MATHWORKs provides and maintains. This has some benefits:
- easier to maintain
- user-friendly ways to interact with the container
- no hassle with the MATLAB license, and if so, we ca...Currently the Docker images are based on images that MATHWORKs provides and maintains. This has some benefits:
- easier to maintain
- user-friendly ways to interact with the container
- no hassle with the MATLAB license, and if so, we can easily direct users towards the MATLAB support
- sponsored MATLAB licenses (e.g. on GitHub) work
But also some disadvantages:
- we are not in full control of the image
- image size is somewhat large
- Octave version is too old in Ubuntu 22.04
- Octave compatibility is not great (the testsuite for Octave typically does not pass for some system-related reason)
- requires additional hacking to improve compatibility with Dynare
- MATLAB does change things from time-to-time and we (or I) need to keep track of the corresponding GitHub repositories
A natural alternative would be to create a vanilla image along the lines we set up the runners that are based on Debian. We would then need to provide similar ways to interact with the container (e.g. [noVNC](https://novnc.com)) and check whether sponsored licenses still work. We would probably loose some user-friendliness here, but then again those who are using Docker might not really need those interactive features.
So, I would like to open this issue to discuss how we should proceed in the future? I'm leaning towards keeping it based on MATHWORK's containers as this is probably easier to maintain; but I have no problem to investigate time and resources towards the Debian option.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1920Provide dr_cycle_reduction_maxiter option2024-02-07T15:09:33ZJohannes PfeiferProvide dr_cycle_reduction_maxiter optionCurrrently, `max_it` in https://git.dynare.org/Dynare/dynare/-/blob/master/mex/sources/cycle_reduction/mexFunction.f08?ref_type=heads is hard-coded to 300. It should be an option as in https://git.dynare.org/Dynare/dynare/-/tree/master/m...Currrently, `max_it` in https://git.dynare.org/Dynare/dynare/-/blob/master/mex/sources/cycle_reduction/mexFunction.f08?ref_type=heads is hard-coded to 300. It should be an option as in https://git.dynare.org/Dynare/dynare/-/tree/master/mex/sources/logarithmic_reduction?ref_type=heads7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1919bug in annualized shock decomposition2024-01-30T10:18:34ZMarco Rattobug in annualized shock decompositionwhen removing unused output args in commit 735bd66d4dea2f244918687fa0fa57051df59673, we created a bug in annualized_shock_decomposition.
there, the second unised argument is actually necessary to trigger the behavior in plot_shock_decomp...when removing unused output args in commit 735bd66d4dea2f244918687fa0fa57051df59673, we created a bug in annualized_shock_decomposition.
there, the second unised argument is actually necessary to trigger the behavior in plot_shock_decomposition that depends on nargout inline 535 .[https://git.dynare.org/Dynare/dynare/-/blob/master/matlab/shock_decomposition/plot_shock_decomposition.m?ref_type=heads#L535](url)
Admittedly, this is a very obscure feature...https://git.dynare.org/Dynare/dynare/-/issues/1918Preprocessor issue with mensual dates with month > 9 passed to daynre into ma...2024-01-29T11:17:26ZUgo DuboisPreprocessor issue with mensual dates with month > 9 passed to daynre into macrovariablesI think I just stumbled into an interesting bug while passing macrovariables containing mensual dates to dynare.
In a very simple mod: [SimpleMod.mod](/uploads/c460c03b98abd0f7acee934530394df5/SimpleMod.mod)
I have (a dummy model) and ...I think I just stumbled into an interesting bug while passing macrovariables containing mensual dates to dynare.
In a very simple mod: [SimpleMod.mod](/uploads/c460c03b98abd0f7acee934530394df5/SimpleMod.mod)
I have (a dummy model) and the instruction: `Toto = @{MensualDate};`
I call this .mod with dynare as follows: `dynare('SimpleMod.mod', '-DMensualDate="2005M10"');`
And get an 'invalid expression' error on `SimpleMod.driver` because what gets written in the driver for the `Toto = @{MensualDate};` instruction is : `Toto = dates('2005M1')0;`
2005M9 works, 2005M11 results into `Toto = dates('2005M1')1;` and 2005M12 results into `Toto = dates('2005M1')2;`Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1917macOS: drop ld_classic workaround2023-12-21T12:16:41ZWilli Mutschlerwilli@mutschler.eumacOS: drop ld_classic workaround~~Xcode CLT 15.1 fixed this [issue](https://github.com/mesonbuild/meson/issues/12282), the `ld_classic` workaround in the native file is not necessary anymore, so we can remove it once the runner is updated. Either way the workaround con...~~Xcode CLT 15.1 fixed this [issue](https://github.com/mesonbuild/meson/issues/12282), the `ld_classic` workaround in the native file is not necessary anymore, so we can remove it once the runner is updated. Either way the workaround continues to work.~~
Nope, 15.1 did not fix this.https://git.dynare.org/Dynare/dynare/-/issues/1916Create testfile for parallel2023-12-19T22:23:20ZWilli Mutschlerwilli@mutschler.euCreate testfile for parallelCurrently the tests in the parallel folder are only for manual testing. It would be good to also test the parallel capabilities in the testsuite.Currently the tests in the parallel folder are only for manual testing. It would be good to also test the parallel capabilities in the testsuite.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.eu