Dynare issueshttps://git.dynare.org/groups/Dynare/-/issues2021-08-19T08:15:50Zhttps://git.dynare.org/Dynare/dynare/-/issues/1784Output updated_covariance from smoother2021-08-19T08:15:50ZMarco RattoOutput updated_covariance from smoothermore on 551917581fba7858f8f590c508b791716a1ace37, I have a question:
- we are issuing in `oo_.Smoother.Variance` the one step ahead variance of variables `V(t+1|t)`. this is in principle a duplicate of the `FilteredVariablesKStepAheadVar...more on 551917581fba7858f8f590c508b791716a1ace37, I have a question:
- we are issuing in `oo_.Smoother.Variance` the one step ahead variance of variables `V(t+1|t)`. this is in principle a duplicate of the `FilteredVariablesKStepAheadVariances`, for k=1.
- we are issuing in `oo_.Smoother.State_uncertainty` the smoother covariances `V(t|T)`
- we are not issuing the updated covariances `V(t|t)`: should we also provide this?
`V(t|t)` would be available already from `matlab/missing_DiffuseKalmanSmootherH3_Z.m` (`P` variable), while for `matlab/missing_DiffuseKalmanSmootherH1_Z.m` it is not (should be computed on purpose).6.xhttps://git.dynare.org/Dynare/website/-/issues/1Improve mobile website2021-04-13T08:44:24ZWilli Mutschlerwilli@mutschler.euImprove mobile websiteI just noticed that the mobile version lacks parts of the top menu and displays only the last few menu entries. Here are some screenshots taken with my iPhone SE (2020) in landscape and horizontal mode. We should somehow add a „burger-st...I just noticed that the mobile version lacks parts of the top menu and displays only the last few menu entries. Here are some screenshots taken with my iPhone SE (2020) in landscape and horizontal mode. We should somehow add a „burger-style“ menu to have access to all subpages.
![73359EE2-CAE5-44E0-9F90-5F8D5100C271](/uploads/49347dbdc207b1c2ee9edcb9d237a0d8/73359EE2-CAE5-44E0-9F90-5F8D5100C271.png)
![46F02AB9-3C35-4A49-B8C6-CC00E46FA8EB](/uploads/37a72b85283d0784399d4e256d13f012/46F02AB9-3C35-4A49-B8C6-CC00E46FA8EB.png)https://git.dynare.org/Dynare/dynare/-/issues/1778Identification toolbox: support measurement errors2021-08-15T19:03:09ZWilli 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.6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1777Pruned theoretical moments: provide a more detailed decomposition of effects2021-07-23T12:23:43ZWilli Mutschlerwilli@mutschler.euPruned theoretical moments: provide a more detailed decomposition of effectsI think we should provide a more detailed decomposition of theoretical unconditional moments at higher-order with pruning as there might be huge differences between e.g. the second and third order system's moments. So something similar t...I think we should provide a more detailed decomposition of theoretical unconditional moments at higher-order with pruning as there might be huge differences between e.g. the second and third order system's moments. So something similar to the output of the `nlma` toolbox:
```sh
THEORETICAL MEAN
VARIABLE MEAN(1st Order Accurate) MEAN(2nd and 3rd Order Accurate)
c 4.8675 29.9263
y 4.8675 29.9263
MEAN(2nd and 3rd Order Accurate) DECOMPOSITION IN LEVEL
VARIABLE Mean(2nd and 3rd Order Accurate) Det. Steady State Risk Adj. from Var. of Future Shock Risk Adj. from Var. of Past Shock
c 29.9263 4.8675 27.8139 -2.7551
y 29.9263 4.8675 27.8139 -2.7551
THEORETICAL STANDARD DEVIATION AND VARIANCE
VARIABLE STD.(1st Order Accurate) STD.(2nd Order Accurate) STD.(3rd Order Accurate) VAR.(1st Order Accurate) VAR.(2nd Order Accurate) VAR.(3rd Order Accurate)
c 14.8060 16.0911 53.0529 219.2180 258.9244 2814.6081
y 3.5188 6.8786 63.4057 12.3816 47.3149 4020.2871
THEORETICAL CORRELATIONS(1st Order Accurate)
Variables c y
c 1.0000 0.5852
y 0.5852 1.0000
THEORETICAL CORRELATIONS(2nd Order Accurate)
Variables c y
c 1.0000 0.5201
y 0.5201 1.0000
THEORETICAL CORRELATIONS(3rd Order Accurate)
Variables c y
c 1.0000 0.8925
y 0.8925 1.0000
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(1st Order Accurate)
Order 1 2 3 4 5
c 0.9602 0.9222 0.8861 0.8518 0.8191
y 0.9960 0.9919 0.9877 0.9834 0.9791
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(2nd Order Accurate)
Order 1 2 3 4 5
c 0.9651 0.9319 0.9001 0.8698 0.8408
y 0.9917 0.9833 0.9747 0.9660 0.9573
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(3rd Order Accurate)
Order 1 2 3 4 5
c 0.9944 0.9891 0.9839 0.9789 0.9741
y 0.9979 0.9958 0.9934 0.9909 0.9882
VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. Total Amp. Total Risk-Amp. Interplay
c 127.42 32.41 -59.83
y 127.42 12.82 -40.24
COMPLETE VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. 1st Order Amp. 2nd Order Incre. Amp. 3rd Order Incre. Amp. 1st-3rd Order Incre. Amp. 3rd Order Incre. Risk-Amp. Interplay 1st-3rd Order Incre. Risk-Amp. Interplay
c 127.42 7.79 1.41 22.44 0.76 -30.31 -29.51
y 127.42 0.31 0.87 10.10 1.55 -28.00 -12.24
```6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1776Consistency in variable names2021-02-18T16:11:58ZWilli 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 4.7, 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.xhttps://git.dynare.org/Dynare/dynare/-/issues/1774Manually verify analytic derivatives before major relases2021-09-20T09:47:15ZJohannes 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.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1766Allow for Herbst-Schorfheide and DS-MH sampler2021-07-21T21:12:52ZJohannes 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
- [ ] 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
- [ ] The default options for the samplers need to be added to `default_option_values`
- [ ] The two routines currently do not provide any return arguments/output6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1758Discuss moving all mod-file output to folder `M_.dname`2021-09-23T09:39:16ZJohannes PfeiferDiscuss moving all mod-file output to folder `M_.dname`The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the...The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the `dname`-saving logic does not fully work. In the long-run, we will move almost all Dynare-generated output to a subfolder of `M_.dname` to get a clean root directory. We have increasingly moved to the direction in the past, e.g. with the $\LaTeX$-files. Two notable exceptions will most probably be
1. `_TeX_binder.tex` due to `\include` only working for subdirectories
2. The `log`-file
3. Potentially the files generated by mode-finders as the user can easily turn them off.
Still to be done:
- [ ] Offer a preprocessor command line option `dname` to set this at the preprocessor-level. This would allow solving the `json`-issue discussed at https://git.dynare.org/Dynare/dynare/-/merge_requests/1793
- [ ] Move the JSON files6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2021-05-03T13:58:40ZSébastien VillemotCreate a MEX equivalent to minreal from the control toolbxSee the comments in `get_minimal_state_representation.m`.See the comments in `get_minimal_state_representation.m`.6.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2022-04-29T15:01:00ZMichelJuillardAdding support for dates in perfect_foresight_setupThe user should be able to control the dates of the dseries produced by `perfect_foresight_solver`
- Currently, `histval`, `histval_file` and `initval_file` pass a `dseries` to `perfect_foresight_setup`
- By default, ``perfect_foresight_...The user should be able to control the dates of the dseries produced by `perfect_foresight_solver`
- Currently, `histval`, `histval_file` and `initval_file` pass a `dseries` to `perfect_foresight_setup`
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this `dseries`
- dates must be permitted in `histval` instead of only signed integers
- `first_obs`: sets the dates used for the first initial conditions. Must be consistent with `histval` or `histval_file` if they are used
- `first_simulation_period`: sets the dates used for the first period of the simulation. It is an alternative to specifying `first_obs` and must be consistent if `first_obs` is also used as an option. Values for initial conditions before this date must be available. Must be consistent with `histval` or `histval_file` if they are used.
- `last_simulation_period`: sets the date of the last period of simulation. It is an alternative to specifying `periods` and must be consistent if `periods` is also used as an option. Data for terminal conditions past the last period must be available6.xhttps://git.dynare.org/Dynare/matlab-gui/-/issues/16options_ when loading dynare model currently in workspace2020-12-07T11:43:13ZMarco Rattooptions_ when loading dynare model currently in workspaceI am trying a bit the behavior of the GUI when I load a project that has been run in the standard command line form, for which one would like to do some post-processing/analysis with the GUI.
M_ oo_ structures a loaded properly, however ...I am trying a bit the behavior of the GUI when I load a project that has been run in the standard command line form, for which one would like to do some post-processing/analysis with the GUI.
M_ oo_ structures a loaded properly, however the options_ which have been set during the executions are not reflected in the options that are set in the GUI. For example, after an estimation, all fields like options_.datafile, first_obs, etc., they have been set, but opening the estimation tab provides the DYNARE defaults etc., which then implies crashes unless one sets manually the options again.
I think it would be extremely useful that all the options set in the GUI reflect the actual values from the session in the workspace and not the default ones.
would this be possible?
thank you!Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1738Publication-quality plots2020-07-15T10:44:06ZWilli Mutschlerwilli@mutschler.euPublication-quality plotsMatlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is...Matlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?https://git.dynare.org/Dynare/preprocessor/-/issues/48Provide a debug mode that gives information about the objects computed in sta...2021-11-09T19:29:52ZSébastien VillemotProvide a debug mode that gives information about the objects computed in static and dynamic filesFor each object in the `static` or `dynamic` file, this mode could add:
- the equation number
- for derivatives, the (possibly dynamic) variable(s) against which the derivative is taken
- the human-readable form of the expression (with r...For each object in the `static` or `dynamic` file, this mode could add:
- the equation number
- for derivatives, the (possibly dynamic) variable(s) against which the derivative is taken
- the human-readable form of the expression (with readable variable names, without temporary terms)
This should also be done for block decomposition mode (in particular, the renormalized equations could be an additional information).6.xhttps://git.dynare.org/Dynare/reporting/-/issues/16create a reporting tutorial website2020-05-07T17:46:42ZHoutan Bastanicreate a reporting tutorial websiteGoing from simple examples to more complex examples to make the code more approachable
Going from simple examples to more complex examples to make the code more approachable
https://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2021-10-25T16:15:30ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16536.xhttps://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes PfeiferFix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveB...As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2021-07-22T10:27:26ZJohannes PfeiferClean root folder of /testsAll integration tests should be in subfolders. The current structure is a messAll integration tests should be in subfolders. The current structure is a mess6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1709Rework handling of trends including automatic detrending2021-08-19T08:43:04ZFerhatMihoubiRework handling of trends including automatic detrendingFor the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new ...For the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2021-07-23T15:37:25ZSébastien VillemotMacro commands that take no arguments have spurious parentheses appended to their synopsisSee for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.See for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1704Update partial information code2021-05-03T13:59:02ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare6.x