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/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/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/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/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/1874Document pac_target_nonstationary-operator and auxiliary variable content rel...2024-01-29T20:44:08ZJohannes PfeiferDocument pac_target_nonstationary-operator and auxiliary variable content related to PAC-modelsThe `pac_target_nonstationary`-operator does not appear in the manual. Similarly, the content of `M_.aux_vars.orig_expr` should be documented. For example, `tests/pac/var-5/example1.mod` has an `aux_var` of the form:
```g*pacman_pac_gro...The `pac_target_nonstationary`-operator does not appear in the manual. Similarly, the content of `M_.aux_vars.orig_expr` should be documented. For example, `tests/pac/var-5/example1.mod` has an `aux_var` of the form:
```g*pacman_pac_growth_neutrality_correction+h_pacman_constant+AUX_DIFF_32(-1)*h_pacman_var_AUX_DIFF_32_lag_1+y(-1)*h_pacman_var_y_lag_1+AUX_DIFF_32(-2)*h_pacman_var_AUX_DIFF_32_lag_2+y(-2)*h_pacman_var_y_lag_2```
The structure of such expressions and the meaning of preprocessor-created objects should be explained.
Related to https://forum.dynare.org/t/iterative-ols-for-pac-equation/21379/47.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1774Manually verify analytic derivatives before major relases2024-01-17T13:47:43ZJohannes PfeiferManually verify analytic derivatives before major relasesUsing `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_op...Using `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_optim.mod`. These tests would fail as Matlab does not allow setting the tolerance lower than the default 1e-6, while we are at 1e-5. But we should nevertheless manually check whether we are within a reasonable tolerance.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1766Allow for Herbst-Schorfheide and DS-MH sampler2023-12-22T12:24:02ZJohannes PfeiferAllow for Herbst-Schorfheide and DS-MH samplerSee https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7
First part is done in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884
- [x] The default options for the samplers need to be added to `default_optio...See https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7
First part is done in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884
- [x] The default options for the samplers need to be added to `default_option_values` (done in 128eaa2d)
- [ ] The two routines currently do not provide any return arguments/output7.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.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/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/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 Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2023-12-14T20:02:49ZTom HoldenNon-bayesian estimation should use quasi-Maximum likelihood standard errorsAt present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an ...At present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1873Method-Of-Moments: add ability to keep first moments despite prefilter option2023-12-14T20:02:09ZWilli Mutschlerwilli@mutschler.euMethod-Of-Moments: add ability to keep first moments despite prefilter optionWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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/1778Identification toolbox: support measurement errors2023-12-14T20:01:47ZWilli Mutschlerwilli@mutschler.euIdentification toolbox: support measurement errorsThe identification toolbox should be able to support measurement errors.The identification toolbox should be able to support measurement errors.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1513Allow selecting proper training sample for endogenous_prior2023-12-14T20:01:28ZJohannes PfeiferAllow selecting proper training sample for endogenous_priorCurrently, we simply use `Y=data';`, but it is straightforward to include different dataCurrently, we simply use `Y=data';`, but it is straightforward to include different datahttps://git.dynare.org/Dynare/dynare/-/issues/1665Implement bridge sampler for computing marginal data density2023-12-14T20:01:17ZJohannes PfeiferImplement bridge sampler for computing marginal data densityhttps://git.dynare.org/Dynare/dynare/-/issues/1818Make mex solve_algo=13 the default solve_algo=42023-12-14T19:59:53ZSébastien VillemotMake mex solve_algo=13 the default solve_algo=4`solve_algo=13` uses the `block_trust_region` MEX, which is essentially a MEX reimplementation of what is available under `solve_algo=4`.
After a Mattermost discussion on 2021-09-21/22, the consensus seems to be:
- verify that the two c...`solve_algo=13` uses the `block_trust_region` MEX, which is essentially a MEX reimplementation of what is available under `solve_algo=4`.
After a Mattermost discussion on 2021-09-21/22, the consensus seems to be:
- verify that the two codes are really equivalent (in particular when moving in the complex domain)
- then change `solve_algo=4` so that it calls the MEX file, and drop `solve_algo=13`
- the old MATLAB code for `solve_algo=4` should be kept under `missing/mex`, ideally with an interface, in order to facilitate the debugging of models (which is easier in MATLAB than in Fortran)https://git.dynare.org/Dynare/dynare/-/issues/1112homogeneize treatment of leads/lags on exogenous between deterministic and st...2023-12-08T09:16:59ZHoutan Bastanihomogeneize treatment of leads/lags on exogenous between deterministic and stochastic modesAuxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_stru...Auxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.7.x