dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-09-27T15:17:17Zhttps://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/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/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/1814rename option in an equation tag, aggregate keeps the renaming part of the tag2021-09-17T07:19:26ZUgo Duboisrename option in an equation tag, aggregate keeps the renaming part of the tagUsing the rename option in a equation tag, then cherrypicking this equation in order to aggregate a larger model has the aggregated model still displaying the rename command in the cherrypicked equation instead of a tag only containing t...Using the rename option in a equation tag, then cherrypicking this equation in order to aggregate a larger model has the aggregated model still displaying the rename command in the cherrypicked equation instead of a tag only containing the new name.
For example:
- cherrypicked equation tag: `[name='y_est', rename='y_est->y']`
- appears in the aggregated model as: `[name='y', rename='y_est->y']`
- what we may like to have: `[name='y']`
See this small example: [AggregationAndRenameBug.mod](/uploads/9a226ade4024fbbd2ceb02179151da23/AggregationAndRenameBug.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/1867Rework perfect foresight handling of initial and terminal values2022-10-13T10:12:25ZJohannes PfeiferRework perfect foresight handling of initial and terminal values1. Disentangle the purpose of various blocks (see https://archives.dynare.org/DynareWiki/DeterministicSimulationBlocks)
2. Eliminate reuse of `oo_.steady_state` for different purposes.
3. Phase out the global variables `ex0_` and `ys0_...1. Disentangle the purpose of various blocks (see https://archives.dynare.org/DynareWiki/DeterministicSimulationBlocks)
2. Eliminate reuse of `oo_.steady_state` for different purposes.
3. Phase out the global variables `ex0_` and `ys0_` used in `make_ex_` and `make_y_`
Related to https://git.dynare.org/Dynare/preprocessor/-/issues/104 and https://git.dynare.org/Dynare/dynare/-/issues/1866https://git.dynare.org/Dynare/dynare/-/issues/829Rewrite local_state_space_iteration_2 routine2021-08-15T19:40:51ZStéphane Adjemianstepan@adjemian.euRewrite local_state_space_iteration_2 routineSeparate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository, particularly https://git.dynare.org/Dynare/particles/-/issues/2Separate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository, particularly https://git.dynare.org/Dynare/particles/-/issues/2Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1864SMM: add support for filters like HP-filter.2022-08-23T08:47:32ZJohannes PfeiferSMM: add support for filters like HP-filter.See https://forum.dynare.org/t/smm-dynare-toolbox-with-binomial-draws/20849/3See https://forum.dynare.org/t/smm-dynare-toolbox-with-binomial-draws/20849/3https://git.dynare.org/Dynare/dynare/-/issues/642Support Dirichlet prior distribution2021-09-03T12:01:06ZHoutan BastaniSupport Dirichlet prior distributionAdding dirichlet to the prior shape option for #568. Needs to be supported in estimation as well.
Adding dirichlet to the prior shape option for #568. Needs to be supported in estimation as well.
https://git.dynare.org/Dynare/dynare/-/issues/819Support DSGE-VAR forecasts2018-09-11T15:00:44ZJohannes PfeiferSupport DSGE-VAR forecastsCurrently, forecasts are based on the DSGE model and not the DSGE-VAR
Currently, forecasts are based on the DSGE model and not the DSGE-VAR
https://git.dynare.org/Dynare/dynare/-/issues/526Support the estimation of static models2018-11-08T11:49:07ZJohannes PfeiferSupport the estimation of static modelsSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5120
It seems not all variables are correctly initialized
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5120
It seems not all variables are correctly initialized
https://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/832Use dseries objects in Dynare2023-06-13T13:21:45ZStéphane Adjemianstepan@adjemian.euUse dseries objects in DynareIn the current state, `dseries` objects can be used in matlab scripts and in Dynare's mod file to create and manipulate datasets. The next step is to integrate more deeply the `dseries` class and Dynare. Whenever possible the output of D...In the current state, `dseries` objects can be used in matlab scripts and in Dynare's mod file to create and manipulate datasets. The next step is to integrate more deeply the `dseries` class and Dynare. Whenever possible the output of Dynare will be `dseries` objects (IRFs, forecasts, ...) and also we will allow the use of `dseries` objects as inputs to Dynare's command (`data`, content of `initval`, data for conditional forecasts, ...).
- [ ] Document the `data` command (new data interface).
- [ ] Save results as `dseries` objects.
- [x] Polish and document the from-to-do syntax.
- [ ] Add the possibility to pass `dseries`to `initial``and``histval``commands.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1845Use keywords as option values when it makes more sense than numerical values2023-09-27T15:11:20ZSébastien VillemotUse keywords as option values when it makes more sense than numerical valuesSeveral options currently accept numerical values, which are not very meaningful nor informative. We could instead use keywords as values (but continue accepting the old numerical values for backward compatibility).
Candidate options fo...Several options currently accept numerical values, which are not very meaningful nor informative. We could instead use keywords as values (but continue accepting the old numerical values for backward compatibility).
Candidate options for this change are:
- `solve_algo`
- `stack_solve_algo`
- `mode_compute`
- `lik_init`
- `kalman_algo`
- `analytic_derivation_mode`
- `mfs`
- `plot_priors`
For example, for `solve_algo`, the integer value `0` could be replaced by the keyword `fsolve`. And so on. The first step is obviously to decide which keywords to use for each numerical value.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1858Use MEX to create stacked Jacobian in two-boundaries blocks with block decomp...2022-09-13T15:50:11ZSébastien VillemotUse MEX to create stacked Jacobian in two-boundaries blocks with block decompositionThe `perfect_foresight_problem` MEX was introduced so as to speed-up the construction of the stacked Jacobian for deterministic problems (when there are both leads and lags).
However, when doing block decomposition, there is no equivale...The `perfect_foresight_problem` MEX was introduced so as to speed-up the construction of the stacked Jacobian for deterministic problems (when there are both leads and lags).
However, when doing block decomposition, there is no equivalent MEX for constructing the stacked Jacobian for two-boundaries blocks. This is an obvious opportunity for optimization.
It remains to be seen how much can be factorized with the existing `perfect_foresight_problem` MEX. The bytecode case may also need special treatment.https://git.dynare.org/Dynare/dynare/-/issues/1693Various improvements in Sphinx doc2023-09-27T15:33:04ZHoutan BastaniVarious improvements in Sphinx doc- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLA...- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1658Write a howto on forecasting2019-09-20T13:06:55ZSébastien VillemotWrite a howto on forecasting