dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-10-26T20:53:27Zhttps://git.dynare.org/Dynare/dynare/-/issues/1910Investigate MATLAB new desktop2023-10-26T20:53:27ZWilli Mutschlerwilli@mutschler.euInvestigate MATLAB new desktopSo far MATLAB's new desktop starts to be on par except for the performance. MATHWORKS will switch to it as the default in the near future, so we should investigate which issues occur.
#### Printing speed
For us the printing speed is pro...So far MATLAB's new desktop starts to be on par except for the performance. MATHWORKS will switch to it as the default in the near future, so we should investigate which issues occur.
#### Printing speed
For us the printing speed is problematic, because there is an event coalescing problem where text is sent to often. Workaround after discussing this with Eduard from MATHWORKS: vectorize “fprintf” calls to get back the old speed (maybe with a tiny delay due to the actual technology difference).7.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.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/1907Decide the minimal required versions of MATLAB and Octave for Dynare 62023-12-04T08:51:40ZSébastien VillemotDecide the minimal required versions of MATLAB and Octave for Dynare 6We need to decide the minimal required versions of MATLAB and Octave for Dynare 6.
Dynare 5 requires at least MATLAB R2014a and Octave 5 (at the source code level for the latter).
Since Dynare 5 was released in January 2022, it means t...We need to decide the minimal required versions of MATLAB and Octave for Dynare 6.
Dynare 5 requires at least MATLAB R2014a and Octave 5 (at the source code level for the latter).
Since Dynare 5 was released in January 2022, it means that upon release we were supporting 8 years of MATLAB (R2014a to R2021b); and we are currently supporting 10 years of MATLAB.
If we were to apply the same policy for Dynare 6, that would mean requiring R2016a. But we could also be more aggressive, which would bring some benefits (see the [MATLAB versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions) page):
- R2016b would allow us to remove all calls to `bsxfun`, and also to drop the JSONlab toolbox under `contrib/` (provided that we also require Octave 7)
- R2018a would allow us to ship only one flavour of the MEX files (since that version introduced an ABI break)
- R2018b would allow us to use double quoted strings (and thus stop worrying about using single quotes everywhere)
And requiring R2019a would mean moving to 5-years window of MATLAB releases supported, which is already quite a lot.
I think we should go for at least R2016b, and maybe even R2018b.
For Octave, we already require Octave 6 in unstable. I would be inclined to require Octave 7, because that would allow us to drop JSONlab (if we also require MATLAB R2016b). My only concern is that Ubuntu 22.04 LTS ships with Octave 6 (so that may affect you @wmutschl); however note that Ubuntu 24.04 LTS will be released shortly after Dynare 6, and it will include Octave 8.
Waiting for your thoughts on this. We should also ask our institutional users about their constraints.6.xSébastien VillemotSébastien Villemothttps://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/1905Rework fs2000.mod example file to use actual data2023-12-14T13:06:29ZJohannes PfeiferRework fs2000.mod example file to use actual dataSee https://git.dynare.org/Dynare/dynare/-/merge_requests/2160#note_19189See https://git.dynare.org/Dynare/dynare/-/merge_requests/2160#note_19189https://git.dynare.org/Dynare/dynare/-/issues/1904Allow vector input for chain in generate_trace_plots2023-09-11T14:47:44ZJohannes PfeiferAllow vector input for chain in generate_trace_plotshttps://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/1898Fix testsuite: "sed: couldn't write 56 items to stdout: Broken pipe"2023-09-27T14:59:31ZJohannes PfeiferFix testsuite: "sed: couldn't write 56 items to stdout: Broken pipe"The Matlab testsuite states:
>sed: couldn't write 56 items to stdout: Broken pipeThe Matlab testsuite states:
>sed: couldn't write 56 items to stdout: Broken pipehttps://git.dynare.org/Dynare/dynare/-/issues/1897Discuss the expected output of shock_decomposition2023-08-30T10:09:35ZJohannes PfeiferDiscuss the expected output of shock_decompositionThe `shock_decomposition`-command contains a call to `evaluate_smoother`, which will overwrite all previous computations from the smoother. My understanding is that this is unexpected behavior. See https://forum.dynare.org/t/oo-smoothedv...The `shock_decomposition`-command contains a call to `evaluate_smoother`, which will overwrite all previous computations from the smoother. My understanding is that this is unexpected behavior. See https://forum.dynare.org/t/oo-smoothedvariables-with-shock-decomposition/22883/3. @rattoma What do you think?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/1894macOS: drop gcc option2023-10-16T18:30:53ZWilli Mutschlerwilli@mutschler.eumacOS: drop gcc optionI am currently working on revising and updating our macOS build scripts and encountered issue #1893. Reflecting on this, I questioned our current method of including a manual homebrew installation in our distribution. As the homebrew pro...I am currently working on revising and updating our macOS build scripts and encountered issue #1893. Reflecting on this, I questioned our current method of including a manual homebrew installation in our distribution. As the homebrew project doesn't officially support this, it extends the installation time unnecessarily, especially for those with slower internet connections. Additionally, having outdated versions of gcc on hand could potentially lead to security risks.
To my understanding, the primary reason for this inclusion is to facilitate the use of gcc for the `use_dll` option, as well as to accommodate users without `admin` privileges on their Mac. However, this approach seems contradictory since installing the pkg already requires admin rights because the files are installed into /Applications and the Command Line Tools installation also requires admin rights.
Therefore, I propose two main changes to our approach:
1. Eliminate the gcc option from the installer and instead, provide directions to users on how to install gcc using the homebrew project. Maybe an info box after the installation finishes. This will not only expedite the installation process but also eliminate potential issues linked with outdated brew versions in our directory.
2. Introduce a method to install the pkg without admin privileges, enabling it to be installed directly into the end-user's home directory without needing elevated privileges. This will, of course, require verification that Apple's Command Line Tools are installed (but it might actually be the case that MATLAB also installs them).
I believe these proposed adjustments will result in a more efficient installation process and better adherence to Homebrew's best practices. Any feedback on these proposed changes is welcome.6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1893macOS: installation failed for x86_64 due to relinking issue in brew2023-10-16T18:30:53ZWilli Mutschlerwilli@mutschler.eumacOS: installation failed for x86_64 due to relinking issue in brewRecently, installing the unstable snapshots on macOS yields an error:
```
Error: Failed changing install name in /Applications/Dynare/6-2023-07-07-1144/.brew/Cellar/gcc/13.1.0/libexec/gcc/x86_64-apple-darwin22/13/cc1
from @@HOMEBREW_PR...Recently, installing the unstable snapshots on macOS yields an error:
```
Error: Failed changing install name in /Applications/Dynare/6-2023-07-07-1144/.brew/Cellar/gcc/13.1.0/libexec/gcc/x86_64-apple-darwin22/13/cc1
from @@HOMEBREW_PREFIX@@/opt/gmp/lib/libgmp.10.dylib
to /Applications/Dynare/6-2023-07-07-1144/.brew/opt/gmp/lib/libgmp.10.dylib
Error: Updated load commands do not fit in the header of /Applications/Dynare/6-2023-07-07-1144/.brew/Cellar/gcc/13.1.0/libexec/gcc/x86_64-apple-darwin22/13/cc1. /Applications/Dynare/6-2023-07-07-1144/.brew/Cellar/gcc/13.1.0/libexec/gcc/x86_64-apple-darwin22/13/cc1 needs to be relinked, possibly with -headerpad or -headerpad_max_install_names
```
The installer ends with error. Here is the [install.log](/uploads/d7f56bfe25969776263e114572785493/install.log).
Now the new built scripts for Apple Silicon in Dynare/dynare!2143 have the same issue for x86_64, but not for arm64. There everything installs without error. I have looked and updated the rb files, but without success. By the way, I don't think we need the rb files anymore (e.g. the arm64 packages install fine without).
Anyways, if someone knows a solution, please let me know. Otherwise I would actually like to discuss whether to drop the GCC option in the macos installer in a separate issue.6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1892Octave testsuite on macOS: xvfb-run: command not found2023-12-21T13:05:00ZWilli Mutschlerwilli@mutschler.euOctave testsuite on macOS: xvfb-run: command not found`make check-octave` does not work on my Apple Silicon Mac running Ventura, it says `xvfb-run: command not found`. I tried installing xquartz, which gave me the `xvfb` command but not the run script. Is there a workaround?`make check-octave` does not work on my Apple Silicon Mac running Ventura, it says `xvfb-run: command not found`. I tried installing xquartz, which gave me the `xvfb` command but not the run script. Is there a workaround?6.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1891stoch_simul: deal with zero variance2023-07-11T22:10:32ZWilli Mutschlerwilli@mutschler.eustoch_simul: deal with zero varianceWe add a very small number to the covariance matrix to compute irfs:
```matlab
SS(M_.exo_names_orig_ord,M_.exo_names_orig_ord)=M_.Sigma_e+1e-14*eye(M_.exo_nbr);
cs = transpose(chol(SS));
```
The reason: If a shock has 0 variance,...We add a very small number to the covariance matrix to compute irfs:
```matlab
SS(M_.exo_names_orig_ord,M_.exo_names_orig_ord)=M_.Sigma_e+1e-14*eye(M_.exo_nbr);
cs = transpose(chol(SS));
```
The reason: If a shock has 0 variance, the matrix isn't definite positive and chol() can't be computed. The small positive amount on the diagonal insure that the matrix is nevertheless positive definite in this case.
It would be better to add this epsilon only on zero diagonal elements, to avoid changing the covariance matrix in the usual case; and possibly also providing a warning or error.Johannes PfeiferJohannes Pfeifer