dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-09-07T17:26:47Zhttps://git.dynare.org/Dynare/dynare/-/issues/1798Nonlinear least squares for estimation2021-09-07T17:26:47ZAnastasia ZhNonlinear least squares for estimationNLS does not impose any restrictions on the form of an equation and shall allow estimating non-linear equations.NLS does not impose any restrictions on the form of an equation and shall allow estimating non-linear equations.2021-09-10https://git.dynare.org/Dynare/dynare/-/issues/1785Add structural VAR model as an auxiliary model for VAR based expectations and...2021-09-13T08:44:21ZStéphane Adjemianstepan@adjemian.euAdd structural VAR model as an auxiliary model for VAR based expectations and PAC equations2021-09-10https://git.dynare.org/Dynare/dynare/-/issues/1886Model information routine2023-03-24T13:50:09ZUgo DuboisModel information routineThis function takes as input (< option >,< variable_name >).
Its ouput is a print in the command window with the expressions of all the equations < variable_name > enters in.
If < option > == 1, parameters names get replaced by their...This function takes as input (< option >,< variable_name >).
Its ouput is a print in the command window with the expressions of all the equations < variable_name > enters in.
If < option > == 1, parameters names get replaced by their values in the output. If < option > == 0, then the parameters names are left as names.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.eu2023-02-16https://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/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/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/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/1915Unknow index in parallel/closeSlave.m2023-12-21T13:05:00ZStéphane Adjemianstepan@adjemian.euUnknow index in parallel/closeSlave.mLine 77 we have:
```matlab
isempty(dynareParallelDir(['P_slave_',int2str(j),'End.txt'],TmpFolder,Parallel))
```
under a `if` statement, but index `j` is not defined. Matlab interprets j as a complex number and `int2str(j)` evaluates to `...Line 77 we have:
```matlab
isempty(dynareParallelDir(['P_slave_',int2str(j),'End.txt'],TmpFolder,Parallel))
```
under a `if` statement, but index `j` is not defined. Matlab interprets j as a complex number and `int2str(j)` evaluates to `'0'`.https://git.dynare.org/Dynare/dynare/-/issues/1914Fix saving of _mh_mode after integration of SMC2023-12-15T13:59:45ZJohannes PfeiferFix saving of _mh_mode after integration of SMC60c0ed01 changed the behavior of `compute_mh_covariance_matrix` to not save the `_mh_mode.mat` file. That is now done in `compute_posterior_covariance_matrix`. This breaks backward compatibility as e.g. `fs2000.mod` now does not save the...60c0ed01 changed the behavior of `compute_mh_covariance_matrix` to not save the `_mh_mode.mat` file. That is now done in `compute_posterior_covariance_matrix`. This breaks backward compatibility as e.g. `fs2000.mod` now does not save the `_mh_mode.mat` anymore via the call to `marginal_density.m`.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/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/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/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/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 Villemot