dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-10-02T11:57:33Zhttps://git.dynare.org/Dynare/dynare/-/issues/1909macOS distribution: pkg installer vs homebrew2023-10-02T11:57:33ZWilli Mutschlerwilli@mutschler.eumacOS distribution: pkg installer vs homebrew1) Dynare for Octave is distributed already via Homebrew in this [dynare.rb](https://github.com/Homebrew/homebrew-core/blob/d01b7db772f9fa2df063db360ca3dd884f0a1047/Formula/d/dynare.rb). We should probably also try to get Dynare with MAT...1) Dynare for Octave is distributed already via Homebrew in this [dynare.rb](https://github.com/Homebrew/homebrew-core/blob/d01b7db772f9fa2df063db360ca3dd884f0a1047/Formula/d/dynare.rb). We should probably also try to get Dynare with MATLAB available with brew as well, similar to how we package on Debian.
2) Additionally, or alternatively, we should also add the Octave files in the pkg installer that we distribute.
3) Lastly, we should decide whether we keep the pkg installer, go solely the homebrew way, or do both.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1859New interface for dynamic and static files representing the model2023-10-02T15:40:12ZSébastien VillemotNew interface for dynamic and static files representing the modelThe preprocessor currently creates `dynamic` and `static` files for representing the model (forgetting about the `bytecode` case which is sligthly different), which have the following two characteristics:
- the Jacobian matrix that they ...The preprocessor currently creates `dynamic` and `static` files for representing the model (forgetting about the `bytecode` case which is sligthly different), which have the following two characteristics:
- the Jacobian matrix that they return is a dense one
- in the `dynamic` file, the column indices for the dynamic (endogenous) variables are organized so as to avoid columns of zeros; said otherwise, if there are `n` variables, there are less than `3×n` columns (for endogenous) in the dynamic Jacobian. This design decision makes sense since the matrix is dense, but it complicates the computations with the Jacobian matrix.
The proposal is to change the design and have the `dynamic` and the `static` files:
- return a sparse Jacobian
- for the `dynamic` file, use exactly `3×n` columns for the endogenous in the Jacobian (and also for higher order derivatives)
It is expected that having a sparse Jacobian will improve performance, at least for large models.
Since the `static` and `dynamic` files are used at many places in the code, the transition cannot be done overnight, and the idea is to have the old and the new interface coexist for some time. The old interface would be removed at some point (unless it turns out that there is a real use case for dense Jacobians).
The interaction with block decomposition also needs to be taken into account when doing this transition. Currently, when block decomposition is requested, the preprocessor outputs `static` and `dynamic` files that have the same name as in the case without block decomposition, but a different interface. This is bad design. The preprocessor should use different names for those files when using block decomposition. We could even go as far as always providing the two versions of those files (with and without block decomposition), so that the `block` option of the `model` block would no longer affect preprocessor output (but only the algorithms used for computations). An even further step could be to always use block decomposition for perfect foresight, and drop the other code paths (but we probably don’t want to do that for the stochastic case). In particular, this could help with large backward models, for which we only need (dynamic) derivatives with respect to contemporaneous variables, an optimization which is already automatically done when using block decomposition.
Steps:
- [x] Change the preprocessor so that it produces the new `static` and `dynamic` files in parallel to the old ones
- [x] Change the preprocessor so that it always outputs the block decomposed files (with the new interface) in parallel to the non-block decomposed ones? (see also preprocessor#41)
- [x] Start using the new interface in the MATLAB/Octave code
- [ ] Drop the perfect foresight algorithms that do not use block decomposition? (i.e. `block` becomes the default, and only choice, for perfect foresight). This would probably require #1858 to be done first.
- [ ] Drop the old interface (if it is confirmed that dense Jacobians have no real use case)Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1908Port pruning to local_state_space iteration routines used for nonlinear estim...2023-10-02T15:41:09ZJohannes PfeiferPort pruning to local_state_space iteration routines used for nonlinear estimationhttps://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/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2023-10-02T15:42:48ZTom HoldenPreprocessor: Allow reusage of model local variable names in steady_state_model block (wishlist)At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variabl...At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.https://git.dynare.org/Dynare/dynare/-/issues/1414command options should be made local, and a new syntax should provide persist...2023-10-02T15:43:02ZHoutan Bastanicommand options should be made local, and a new syntax should provide persistent optionsAllow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `com...Allow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)https://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`.https://git.dynare.org/Dynare/dynare/-/issues/1674Modification to shock_decomposition and plot_decomposition interfaces to incl...2023-10-02T15:44:23ZDóra Kocsiskocsis.doralinda@gmail.comModification to shock_decomposition and plot_decomposition interfaces to include flexibility with datesInclude the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value a...Include the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.https://git.dynare.org/Dynare/dynare/-/issues/846Provide inverse gamma prior with indeterminate moments2023-10-02T15:44:53ZJohannes PfeiferProvide inverse gamma prior with indeterminate momentsWe currently only allow specifying inverse gamma priors with finite/unique mean and variance. But Leeper/Walker/Yang (2010) in an influential paper use an inverse gamma prior with s=1 and nu=4 (parametrization as at http://en.wikipedia.o...We currently only allow specifying inverse gamma priors with finite/unique mean and variance. But Leeper/Walker/Yang (2010) in an influential paper use an inverse gamma prior with s=1 and nu=4 (parametrization as at http://en.wikipedia.org/wiki/Inverse-gamma_distribution), which implies non-existing first and second moments. I would suggest to provide a new prior `inv_gamma_parametrized` that takes the values provided in the mean and standard deviation fields of the `estimated_params`-block directly as the parameters of the distribution, thereby avoiding the impossible transformation from mean and variances.
I would implement this when doing #520https://git.dynare.org/Dynare/dynare/-/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2023-10-02T15:45:03ZStéphane Adjemianstepan@adjemian.euBehavior of STEADY_STATE() in perfect foresight models with anticipated permanent shocks.In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent sh...In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).https://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/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/1806Manual: use proper bibliography management2023-10-02T15:46:14ZJohannes PfeiferManual: use proper bibliography managementWe may want to transition to e.g. https://pypi.org/project/sphinxcontrib-bibtex/We may want to transition to e.g. https://pypi.org/project/sphinxcontrib-bibtex/https://git.dynare.org/Dynare/dynare/-/issues/1829occbin_write_regime: periods option2023-10-02T15:46:52ZMarco Rattooccbin_write_regime: periods optionthe scope and use of the option is not to select for which periods to save the occasionally binding regimes, but to provide a more informative label to the periods, i.e. dates or real numbers representing years and quarters.
this is in f...the scope and use of the option is not to select for which periods to save the occasionally binding regimes, but to provide a more informative label to the periods, i.e. dates or real numbers representing years and quarters.
this is in fact the behaviour of the function which prints any array T that is user provided.
So, I would suggest to allow for `periods` option to have not only integers, but also real, if not also dates arrays.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/1657add shock decomposition for forecasts done after estimation2023-11-10T15:07:39ZSébastien Villemotadd shock decomposition for forecasts done after estimation@MichelJuillard has some preliminary codes.@MichelJuillard has some preliminary codes.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1912Implement conditional forecasting of Banbura et al. (2015)2023-11-24T13:29:27ZJohannes PfeiferImplement conditional forecasting of Banbura et al. (2015)Allows having more shocks than controlled variables.
https://www.sciencedirect.com/science/article/abs/pii/S0169207014001423Allows having more shocks than controlled variables.
https://www.sciencedirect.com/science/article/abs/pii/S0169207014001423https://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.xhttps://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/1665Implement bridge sampler for computing marginal data density2023-12-14T20:01:17ZJohannes PfeiferImplement bridge sampler for computing marginal data density