dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-10-02T15:45:57Zhttps://git.dynare.org/Dynare/dynare/-/issues/1801Allow estimation of parameters appearing in the discount factor2023-10-02T15:45:57ZJohannes PfeiferAllow estimation of parameters appearing in the discount factorRemaining task from https://git.dynare.org/Dynare/dynare/-/issues/1173
Solution envisioned at Summer School 2022:
1. Have the preprocessor substitute whatever expression is provided instead of creating a new parameter with a fixed value...Remaining task from https://git.dynare.org/Dynare/dynare/-/issues/1173
Solution envisioned at Summer School 2022:
1. Have the preprocessor substitute whatever expression is provided instead of creating a new parameter with a fixed value.
2. Replace the Matlab`function discount_factor=get_optimal_policy_discount_factor(params,param_names)` with an `fname.get_optimal_policy_discount_factor` that returns the value of the discount factor for a given model.https://git.dynare.org/Dynare/dynare/-/issues/1800cherrypick() : Add a 'All' option for the tags selection argument2021-07-22T09:48:04ZUgo Duboischerrypick() : Add a 'All' option for the tags selection argumentAs discussed with Stephanne (A) last Friday (2021-07-16) we think it would be a good (and practical) thing to have a 'Select all the equations in the (sub)model it is invoqued on' option for cherrypick()'s third argument.
Use case: in a...As discussed with Stephanne (A) last Friday (2021-07-16) we think it would be a good (and practical) thing to have a 'Select all the equations in the (sub)model it is invoqued on' option for cherrypick()'s third argument.
Use case: in a situation where we are aggregating a big model from several sub-models scripts, for sub-models where all the equations join the aggregated model, we wouldn't have to manually write the tags list of all the equations in the submodel for cherrypick to take them all. We would instead just have to write 'All'.https://git.dynare.org/Dynare/dynare/-/issues/1796Implement observables decomposition2023-09-27T15:05:56ZJohannes PfeiferImplement observables decompositionFeatures request at the 2021 Summer School. Reference: https://www.dynare.org/wp-repo/dynarewp016.pdf
See also https://forum.dynare.org/t/decomposition-into-observables/17278Features request at the 2021 Summer School. Reference: https://www.dynare.org/wp-repo/dynarewp016.pdf
See also https://forum.dynare.org/t/decomposition-into-observables/172787.xhttps://git.dynare.org/Dynare/dynare/-/issues/1795Feature Request: Handling Indeterminacy à la Bianchi and Nicolo2023-09-27T15:07:55ZWilli Mutschlerwilli@mutschler.euFeature Request: Handling Indeterminacy à la Bianchi and NicoloWe might investigate whether we can include
["A Generalized Approach to Indeterminacy in Linear Rational Expectations Models" by Bianchi and Nicolò.](https://onlinelibrary.wiley.com/doi/full/10.3982/QE949)
They propose to do some pre-pr...We might investigate whether we can include
["A Generalized Approach to Indeterminacy in Linear Rational Expectations Models" by Bianchi and Nicolò.](https://onlinelibrary.wiley.com/doi/full/10.3982/QE949)
They propose to do some pre-processing of the model equations in the case of indeterminacy (essentially it creates an extended state-space system that is then determinate). I'll look into this in the semester break in July and August.7.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1793Harmonize logic of get_complementarity_conditions.m2023-09-28T10:58:12ZJohannes PfeiferHarmonize logic of get_complementarity_conditions.mOnly the `mcp`-tag for Ramsey is allowed to contain parameter values due to employing `eval`. In contrast, for other tags we use `str2num(str(kop+1:end))`. We may want to lift this documented behavior.Only the `mcp`-tag for Ramsey is allowed to contain parameter values due to employing `eval`. In contrast, for other tags we use `str2num(str(kop+1:end))`. We may want to lift this documented behavior.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1788Equations for expectation variables in the .mod file of a model2021-11-10T09:58:39ZAnastasia ZhEquations for expectation variables in the .mod file of a modelAt this stage equations for the PV variables are created by `var_expectation(varexp)` or `pac_expectation(pacman)` which can be found then in the generated .inc files.
It is preferable to have them appear directly in the .mod file of t...At this stage equations for the PV variables are created by `var_expectation(varexp)` or `pac_expectation(pacman)` which can be found then in the generated .inc files.
It is preferable to have them appear directly in the .mod file of the model.
Here is one way of doing it. Say we cherrypick a pac equation from an estimation file. Then the generated simulation file used afterward to aggregate a big model shall automatically include an equation for expectation variable used in this pac equation.https://git.dynare.org/Dynare/dynare/-/issues/1784Output updated_covariance from smoother2023-11-10T15:04:55ZMarco 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).7.xJohannes PfeiferJohannes Pfeiferhttps://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/1777Pruned theoretical moments: provide a more detailed decomposition of effects2023-09-27T15:17:17ZWilli 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
```7.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.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/1758Discuss moving all mod-file output to folder `M_.dname`2023-10-02T15:45:44ZJohannes 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 fileshttps://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2023-09-27T15:13:11ZSé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`.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2023-10-02T15:42:24ZMichelJuillardAdding 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 availablehttps://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/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/1709Rework handling of trends including automatic detrending2023-09-27T15:13:28ZFerhatMihoubiRework 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.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1704Update partial information code2023-09-27T15:06:28ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1700Proposal for a generalized solver2023-09-27T15:13:41ZMichelJuillardProposal for a generalized solverModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function tha...Model inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithm7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1698Allow checking linearity for perfect foresight models2023-10-02T15:44:05ZJohannes PfeiferAllow checking linearity for perfect foresight modelsThe linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That ca...The linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.