dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2024-03-19T13:02:54Zhttps://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/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/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/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.euhttps://git.dynare.org/Dynare/dynare/-/issues/1913Fix handling of squeezing in plot_shock_decomposition2023-12-21T13:18:07ZJohannes PfeiferFix handling of squeezing in plot_shock_decompositionThe original bug in https://forum.dynare.org/t/init2shocks-does-not-work/24591 was addressed via a4e6531420c7f41168eae99b6b924cfc9640e7ef
We still need to address how to deal with squeezing of results that is currently addressed in `plo...The original bug in https://forum.dynare.org/t/init2shocks-does-not-work/24591 was addressed via a4e6531420c7f41168eae99b6b924cfc9640e7ef
We still need to address how to deal with squeezing of results that is currently addressed in `plot_shock_decomposition` via
```
try
[i_var,nvar,index_uniques] = varlist_indices(varlist,M_.endo_names);
catch ME
if isfield(oo_.shock_decomposition_info,'i_var')
warning('shock decomp results for some input variable was not stored: I recompute all decompositions')
M_ = evalin('base','M_');
```
Particularly loading `M_` when it is an input if problematic.Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1912Implement conditional forecasting of Banbura et al. (2015)2023-11-24T13:29:27ZJohannes PfeiferImplement conditional forecasting of Banbura et al. (2015)Allows having more shocks than controlled variables.
https://www.sciencedirect.com/science/article/abs/pii/S0169207014001423Allows having more shocks than controlled variables.
https://www.sciencedirect.com/science/article/abs/pii/S0169207014001423https://git.dynare.org/Dynare/dynare/-/issues/1911Investigate premature xtol termination in trust_solve.m2024-02-01T20:47:43ZJohannes PfeiferInvestigate premature xtol termination in trust_solve.mCommit https://git.dynare.org/Dynare/dynare/-/commit/aa8439d4ccbfcf3761c7e168a8423adc8cfce204 introduced the additional termination criterion
```
% Tests for termination and stringent tolerances.
if max(.1*delta, pnorm)<=10*eps(xn...Commit https://git.dynare.org/Dynare/dynare/-/commit/aa8439d4ccbfcf3761c7e168a8423adc8cfce204 introduced the additional termination criterion
```
% Tests for termination and stringent tolerances.
if max(.1*delta, pnorm)<=10*eps(xnorm)*xnorm
% xtol is too small. no further improvement in
% the approximate solution x is possible.
info = 5;
x(:) = inf;
errorflag = true;
continue
end
```
This causes steady-state finding to fail in master where it worked in `5.x`. An example is the attache file.
[Bench.zip](/uploads/47415753cad27448ffdd1ed71d64ea76/Bench.zip)7.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1909macOS distribution: pkg installer vs homebrew2023-10-02T11:57:33ZWilli Mutschlerwilli@mutschler.eumacOS distribution: pkg installer vs homebrew1) Dynare for Octave is distributed already via Homebrew in this [dynare.rb](https://github.com/Homebrew/homebrew-core/blob/d01b7db772f9fa2df063db360ca3dd884f0a1047/Formula/d/dynare.rb). We should probably also try to get Dynare with MAT...1) Dynare for Octave is distributed already via Homebrew in this [dynare.rb](https://github.com/Homebrew/homebrew-core/blob/d01b7db772f9fa2df063db360ca3dd884f0a1047/Formula/d/dynare.rb). We should probably also try to get Dynare with MATLAB available with brew as well, similar to how we package on Debian.
2) Additionally, or alternatively, we should also add the Octave files in the pkg installer that we distribute.
3) Lastly, we should decide whether we keep the pkg installer, go solely the homebrew way, or do both.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1908Port pruning to local_state_space iteration routines used for nonlinear estim...2023-10-02T15:41:09ZJohannes PfeiferPort pruning to local_state_space iteration routines used for nonlinear estimationhttps://git.dynare.org/Dynare/dynare/-/issues/1906Potentially support parfor loops for parallelization2023-09-22T21:50:00ZJohannes PfeiferPotentially support parfor loops for parallelizationRecent Matlab versions will simply resort to a `for`-loop if the parallel-computing toolbox is not available. So we may give this as an option.Recent Matlab versions will simply resort to a `for`-loop if the parallel-computing toolbox is not available. So we may give this as an option.https://git.dynare.org/Dynare/dynare/-/issues/1903Disentangle functions of diffuse_filter2023-09-07T14:56:43ZJohannes PfeiferDisentangle functions of diffuse_filterThe `diffuse_filter`-option serves three purposes:
1. setting `qz_criterium`
2. setting `lik_init`
3. setting `kalman_algo`
This creates unintended consequences.
1. In principle, we don't need `diffuse_filter` if the observables are st...The `diffuse_filter`-option serves three purposes:
1. setting `qz_criterium`
2. setting `lik_init`
3. setting `kalman_algo`
This creates unintended consequences.
1. In principle, we don't need `diffuse_filter` if the observables are stationary (`diffuse_periods=0`). But `diffuse_filter` is still required to change the setting of `qz_criterium` and set `lik_init`. That seems problematic.
2. Specifying `diffuse_filter` is incompatible with `fast_kalman_filter`, but that will not trigger a warning and will work if `diffuse_periods=0`. But it should be slower due to solving the Lyapunov equation differently.https://git.dynare.org/Dynare/dynare/-/issues/1902Allow looping over (random) starting values for estimation2023-09-07T08:46:24ZJohannes PfeiferAllow looping over (random) starting values for estimationRequest at advanced user meeting: draw from prior and start mode-finding.Request at advanced user meeting: draw from prior and start mode-finding.https://git.dynare.org/Dynare/dynare/-/issues/1901Improve convergence diagnostics2023-09-07T08:31:51ZJohannes PfeiferImprove convergence diagnostics1. Multivariate instead of univariate diagnostics https://academic.oup.com/biomet/article-abstract/106/2/321/5426969?redirectedFrom=fulltext and https://doi.org/10.1214/20-STS812
2. Have quantitative instead of eyeballing test for multi...1. Multivariate instead of univariate diagnostics https://academic.oup.com/biomet/article-abstract/106/2/321/5426969?redirectedFrom=fulltext and https://doi.org/10.1214/20-STS812
2. Have quantitative instead of eyeballing test for multiple chains.https://git.dynare.org/Dynare/dynare/-/issues/1900Add Artificial bee colony optimizer2023-09-27T15:07:25ZWilli Mutschlerwilli@mutschler.euAdd Artificial bee colony optimizerArtificial bee colony (ABC) is a stochastic search technique based on swarm intelligence, which mimics the process of honey bee swarms foraging for food.
@jmaih has an implementation in RISE and - even though it is rather slow- it is su...Artificial bee colony (ABC) is a stochastic search technique based on swarm intelligence, which mimics the process of honey bee swarms foraging for food.
@jmaih has an implementation in RISE and - even though it is rather slow- it is supposed to be very powerful.7.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1899Document of fix behavior of det_cond_forecast2023-08-30T18:18:30ZJohannes PfeiferDocument of fix behavior of det_cond_forecastFrom https://forum.dynare.org/t/error-messages-when-building-the-forecast/22873/4.
I think there is either a bug or the manual is wrong. `det_cond_forecast` seems to always expect three input arguments, i.e. the initial forecast date is...From https://forum.dynare.org/t/error-messages-when-building-the-forecast/22873/4.
I think there is either a bug or the manual is wrong. `det_cond_forecast` seems to always expect three input arguments, i.e. the initial forecast date is mandatory.
[IN_AUX.csv](/uploads/ed7b4b47377fb38a92a99c7b0c571549/IN_AUX.csv)
[UForecast.mod](/uploads/e9d55faa83615f4f0040c5bbb45e2d41/UForecast.mod)
Moreover, the second argument is supposed to indicate the past values of the endogenous variables. But using [UForecast_3_arguments.mod](/uploads/bf27cd7ac32670a1a9b5a09b9184e493/UForecast_3_arguments.mod) I get the error message
> the dseries smoothed finish at time 2023Q2 before the last period of forecast 2024Q3
which does not make sense if only past values are needed.https://git.dynare.org/Dynare/dynare/-/issues/1896Discuss detrending of lagged trend_var2023-07-28T08:06:08ZJohannes PfeiferDiscuss detrending of lagged trend_varConsider
```
var gd, gu;
trend_var(growth_factor=gu) Bu;
trend_var(growth_factor=gd) Bd;
varexo vd,vu;
parameters gamu,gamd,thetadu;
gamu=.01;
gamd=.003;
thetadu=0.3;
model;
log(gu)=log(1+gamu)+vu;
log(gd)=log(1+gamd)+thetadu*l...Consider
```
var gd, gu;
trend_var(growth_factor=gu) Bu;
trend_var(growth_factor=gd) Bd;
varexo vd,vu;
parameters gamu,gamd,thetadu;
gamu=.01;
gamd=.003;
thetadu=0.3;
model;
log(gu)=log(1+gamu)+vu;
log(gd)=log(1+gamd)+thetadu*log(Bu(-1)/Bd(-1))+thetadu*log((1+gamu)/(1+gamd))+vd;
end;
initval;
gu=1.01;
gd=1.003;
vd = 0; vu=0;
end;
steady;
check;
shocks;
var vd; stderr 0.02;
var vu; stderr 0.02;
end;
write_latex_dynamic_model;
collect_latex_files;
stoch_simul(irf=150,order=1) gu gd;
```
from https://forum.dynare.org/t/impulse-responses-with-cointegrated-stochastic-trends/22756
Internally, we replace the lagged `trend_var Bu`, i.e. `Bu(-1)`, by its definition `Bu/gu`. The problem is that we then use the normalization `Bu=1`, i.e. we fix today's value of the trend and have `gu` implicitly determine the predetermined value yesterday. As a consequence, the variable `gd` on the left suddenly reacts contemporaneously to `gu`, although in the original equation everything on the right was predetermined. My understanding is that for a stochastic `growth_factor` this detrending approach is problematic as we are violating predeterminedness. What is the solution to this issue? Normalizing an endogenous object at time $t$ to 1 seems to be poor practice. At a minimum, we need to document the current behavior.https://git.dynare.org/Dynare/dynare/-/issues/1895macOS: add option to choose compiler and investigate whether to make Clang th...2023-12-14T20:02:01ZWilli Mutschlerwilli@mutschler.eumacOS: add option to choose compiler and investigate whether to make Clang the default oneIn some testing with the EAGLE model and the `use_dll` option it seems that Apple's Clang compiler (under x86_64 Rosetta with the default flags) is faster than Homebrew's GCC compiler with our optimized choice of flags. This requires som...In some testing with the EAGLE model and the `use_dll` option it seems that Apple's Clang compiler (under x86_64 Rosetta with the default flags) is faster than Homebrew's GCC compiler with our optimized choice of flags. This requires some more testing to decide whether to make it the default and/or even improve the choice of flags for Clang. Either way, it would be good to have an option to choose the compiler, because as of Dynare/preprocessor!79 we prioritize GCC and use Clang only as a fallback.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1890model_replace cannot identify equations with multiple tags2023-12-14T20:03:13ZMarco Rattomodel_replace cannot identify equations with multiple tags`model_replace(TAGS...);`
allows providing a list of tags, which is interpreted as a list of equations to replace, however we cannot identify one single equation with multiple tags. for example this makes impossible to replace one equati...`model_replace(TAGS...);`
allows providing a list of tags, which is interpreted as a list of equations to replace, however we cannot identify one single equation with multiple tags. for example this makes impossible to replace one equation related to OBC (occbin), since the name of the equation applies to the 2 variants (relax, bind), and hence model_replace cannot be used.
we could find a way to identify 1 equation with multiple tags, e.g. with multiple tags grouped into square brakets as follows?
`model_replace([TAG1 TAG2], TAGS, ...);
`Sébastien VillemotSébastien Villemot