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/1776Consistency in variable names2023-10-25T13:56:19ZWilli Mutschlerwilli@mutschler.euConsistency in variable namesI would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_...I would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_likelihood.m`, `dsge_var_likelihood.m`, `non_linear_dsge_likelihood` or in the functions of the identification toolbox we use names like `DynareOptions`, or `options` (without underscore). So maybe, right before we release 6.x, we could make the names consistent? This would be a simple text search and replace, but everyone would then need to rebase local branches to this.
I think these are the most important variables (feel free to add to this list):
- `M_`
- `options_`
- `oo_`
- `estim_params_`
- `bayestopt_`
- `dataset_`
- `dataset_info`
- `estimation_info`6.xWilli 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/1790MacOS installer auto uninstalls old Dynare version2023-10-12T18:37:03ZWilli Mutschlerwilli@mutschler.euMacOS installer auto uninstalls old Dynare versionThe 4.6.* installer auto-uninstalls any 4.5.* versions on MacOS, I can replicate the issue a user had on the [forum](https://forum.dynare.org/t/how-to-coexist-two-version-of-dynare/18151/8)
Can we make this optional with a checkbox?The 4.6.* installer auto-uninstalls any 4.5.* versions on MacOS, I can replicate the issue a user had on the [forum](https://forum.dynare.org/t/how-to-coexist-two-version-of-dynare/18151/8)
Can we make this optional with a checkbox?6.xhttps://git.dynare.org/Dynare/dynare/-/issues/18355.0 installs empty directories2023-10-11T19:41:19Zyuri@FreeBSD5.0 installs empty directoriesThese directories are empty:
```
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/doc
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/tests/FameDatabases
```These directories are empty:
```
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/doc
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/tests/FameDatabases
```6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/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/1889Gracefully exit after problem in block_trust_region.mex2023-09-26T20:01:23ZJohannes PfeiferGracefully exit after problem in block_trust_region.mexThe attached file crashes Matlab on Windows, presumably due to a Lapack issue in `block_trust_region`.
[example.mod](/uploads/a41c52dff0aac34aeadf7901fa6aa0a7/example.mod)The attached file crashes Matlab on Windows, presumably due to a Lapack issue in `block_trust_region`.
[example.mod](/uploads/a41c52dff0aac34aeadf7901fa6aa0a7/example.mod)Sébastien VillemotSébastien Villemothttps://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/1403Decide on changing prior in fs2000.mod2023-09-13T18:06:46ZJohannes PfeiferDecide on changing prior in fs2000.modhttps://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `example...https://github.com/DynareTeam/dynare/commit/b14cf33c8ffe936c3c3ad79846335e918be7fb77 changed the prior for `rho` in the integration tests to not have an asymptote. But this change was not ported to the `fs2000.mod` in the Dynare `examples`-folder. Following the discussion in #1401, we warn users against using such a prior. Therefore, I would propose to change the prior in the `examples`mod-file as well. After all, it is an example, not a replication file.https://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/1836Provide conditional variance decomposition also for pruning2023-09-08T12:55:21ZJohannes PfeiferProvide conditional variance decomposition also for pruningSee https://forum.dynare.org/t/conditional-variance-decomposition-for-order-2-with-pruning-dynare-5-0/19601
This would (partially) restore the old behavior.See https://forum.dynare.org/t/conditional-variance-decomposition-for-order-2-with-pruning-dynare-5-0/19601
This would (partially) restore the old behavior.https://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/1849Make default value of mh_jscale dependent on number of estimated parameters2023-09-06T12:38:57ZJohannes PfeiferMake default value of mh_jscale dependent on number of estimated parametersWe currently employ the default `mh_jscale=0.2`. This hardly ever fits as the optimal value is typically decreasing in the number of estimated parameters. I would propose to use the optimal value of Gelman et al. (1995) for the normal s...We currently employ the default `mh_jscale=0.2`. This hardly ever fits as the optimal value is typically decreasing in the number of estimated parameters. I would propose to use the optimal value of Gelman et al. (1995) for the normal symmetric random walk Metropolis-Hastings of `2.38^2/npar` as the default. That would break backward compatibility on files where the default was used, but would employ a more sensible starting value depending on the number of parameters estimated.6.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1878X-13ARIMA-SEATS routines can crash depending on the current directory2023-09-06T10:53:18ZPierre AldamaX-13ARIMA-SEATS routines can crash depending on the current directoryWhile working on building our dataset (in our case, for seasonal adjustment), we observed that X-13ARIMA-SEATS routines can crash when the current directory is different from the path of the Matlab script where we call the X13 routines. ...While working on building our dataset (in our case, for seasonal adjustment), we observed that X-13ARIMA-SEATS routines can crash when the current directory is different from the path of the Matlab script where we call the X13 routines. This behavior seems to be eratic: it occurs while we loop over a loop of variables and it does not always crash on the same variable.
In the attached example, I replicate this crash with random data on which I want to do seasonal adjustment. I loop over an arbitrary number of variables (N=30). To trigger the crash, one needs to change the current directory of Matlab to any subfolder.
```
%% Create a subfodler
mkdir SomeFolder
addpath('./SomeFolder')
%% To trigger the bug set bug = true
bug = true ;
if bug
cd('./SomeFolder')
else
cd(cwd)
end
```
In this case, the loop will eventually stop. Sometimes, it can stop for the first variable, sometimes it can iterate until a higher number of variable, for a reason we cannot explain.
```
Variable 7
ans is a dseries object:
| d11
1999Q1 | 0.39353
1999Q2 | 0.91905
1999Q3 | 0.6416
1999Q4 | 0.721
2000Q1 | 0.92627
2000Q2 | 0.42445
2000Q3 | 0.51803
2000Q4 | 0.3232
2001Q1 | 0.32554
2001Q2 | 0.3497
|
2021Q2 | 1.1398
2021Q3 | 0.5587
2021Q4 | 0.23827
2022Q1 | 0.53768
2022Q2 | 0.46911
2022Q3 | 0.77198
2022Q4 | 0.35521
2023Q1 | 0.4205
2023Q2 | 0.61482
2023Q3 | 0.21813
2023Q4 | 1.1208
Variable 8
Reference to non-existent field 'd11'.
Error in x13/subsref (line 88)
o = builtin('subsref', o.(S(1).subs), S(2));
Error in BugX13 (line 50)
o.results.d11
```
[BugX13.7z](/uploads/db69ed042bccb75ffc89e986c79dd8d2/BugX13.7z)Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1872Implement conditional likelihood at order=12023-09-06T10:52:12ZJohannes PfeiferImplement conditional likelihood at order=1@stepan-a already has an implementation.@stepan-a already has an implementation.https://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/1888Rename resid.m2023-07-23T10:34:20ZJohannes PfeiferRename resid.mIn Matlab Online I got the warning
```
Warning: Dynare is not on top of the Matlab/Octave path! This can cause problems because the Dynare implementations of resid.m, and vnorm.m will be overriden.
Warning: I put /MATLAB Add-Ons/Toolbox...In Matlab Online I got the warning
```
Warning: Dynare is not on top of the Matlab/Octave path! This can cause problems because the Dynare implementations of resid.m, and vnorm.m will be overriden.
Warning: I put /MATLAB Add-Ons/Toolboxes/dynare/matlab on top of your Matlab/Ocatve path.
Note that this is a temporary change (i.e. it will not affect future Matlab/Octave sessions).
```
Given that Dynare 6.0 will break backward compatibility with the regularly used syntax `resid(1)`, I would suggest to use this opportunity to rename the underlying Matlab function to something more expressive, which at the same time does not cause a naming conflict with the built-in function.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1718Auxillary particle filter --- number_of_state_variables is undefined2023-07-12T16:29:58ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`n...In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.eu