dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-12-14T20:03:13Zhttps://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/1880Missing input sanitization in parallel configuration file2023-09-06T10:54:55ZSébastien VillemotMissing input sanitization in parallel configuration fileInput read from the parallel configuration file, specifically from the `UserName`, `ComputerName`, and `RemoteDirectory` fields, is passed directly to a `system` call without any sanitization.
Command injection example with the `UserNam...Input read from the parallel configuration file, specifically from the `UserName`, `ComputerName`, and `RemoteDirectory` fields, is passed directly to a `system` call without any sanitization.
Command injection example with the `UserName` field:
```
[cluster]
Name = LocalProfile1
Members = n1
[node]
Name = n1
ComputerName = 192.168.1.62
CPUnbr = 8
NumberOfThreadsPerJob = 1
OperatingSystem = unix
RemoteDirectory = test
UserName = & ping 127.0.0.1 &
Password = test
```
Intigriti submission reference: `DYNARE-4CN0UV5J`https://git.dynare.org/Dynare/dynare/-/issues/1876Document behavior of steady_state()-operator with trending variables2022-12-20T16:37:03ZJohannes PfeiferDocument behavior of steady_state()-operator with trending variablesSee https://forum.dynare.org/t/correct-specification-of-fiscal-rules-in-a-non-stationary-environment/21245/4See https://forum.dynare.org/t/correct-specification-of-fiscal-rules-in-a-non-stationary-environment/21245/4Johannes PfeiferJohannes Pfeiferhttps://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/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/1871Add Dynare Julia implementation for computing Ramsey steady state2023-09-27T15:18:36ZJohannes PfeiferAdd Dynare Julia implementation for computing Ramsey steady state@MichelJuillard implemented an optimization approach in Julia instead of the current QR-decomposition. We should implement this as an option as it allows controlling the size of the error.@MichelJuillard implemented an optimization approach in Julia instead of the current QR-decomposition. We should implement this as an option as it allows controlling the size of the error.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1869Allow "globally" setting OccBin options for all sub-routines2023-09-06T12:38:41ZJohannes PfeiferAllow "globally" setting OccBin options for all sub-routinesFor options that can be set for the various cases (likelihood, smoother, simul), implement a way to set all sub-cases in `occbin_setup` by using one option. (See https://git.dynare.org/Dynare/dynare/-/merge_requests/2094#note_17648)
Prop...For options that can be set for the various cases (likelihood, smoother, simul), implement a way to set all sub-cases in `occbin_setup` by using one option. (See https://git.dynare.org/Dynare/dynare/-/merge_requests/2094#note_17648)
Proposal: e.g. `check_ahead` as a stand-in for `*_check_ahead`https://git.dynare.org/Dynare/dynare/-/issues/1868Calculation of possible simulation dates and determination of which variables...2022-11-08T15:41:08ZPierre AldamaCalculation of possible simulation dates and determination of which variables limit the datesIn large-scale semi-structural models, the number of endogenous and exogenous variables sometimes can be really large (generally hundreds). As a consequence, users can have hard-time to find which are the possible simulation dates (earli...In large-scale semi-structural models, the number of endogenous and exogenous variables sometimes can be really large (generally hundreds). As a consequence, users can have hard-time to find which are the possible simulation dates (earliest and latest start-date but also latest end-date), which depend on hundreds of endogenous and exogenous variables.
A solution would be to develop a function with two inputs: a model and a dseries containing all endogenous and exogenous variables, and finally returns 3 informations:
- earliest possible simulation start-date
- latest possible simulation start-date
- latest possible simulation end-date
with a list of limiting variables for each date.
In order to derive these dates, based on the dseries and on the model, the algorithm would use: i) the first and last common dates of observed endogenous variables; ii) the last common date of observed exogenous variables and iii) the maximum number of lags and leads in the model.https://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/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/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/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/1857Document data-command or replace it2022-08-10T15:09:00ZJohannes PfeiferDocument data-command or replace itCurrently, to get a `dseries`object loaded into estimation, we use
```
ts = dseries('fsdat_simul.m');
data(series=ts, first_obs=1950Q3, last_obs=2000Q3);
```
(see https://git.dynare.org/Dynare/dynare/-/blob/master/tests/dates/fs2000.mod...Currently, to get a `dseries`object loaded into estimation, we use
```
ts = dseries('fsdat_simul.m');
data(series=ts, first_obs=1950Q3, last_obs=2000Q3);
```
(see https://git.dynare.org/Dynare/dynare/-/blob/master/tests/dates/fs2000.mod). But that `data`-command is not documented as it belongs to the new estimation interface (https://git.dynare.org/Dynare/dynare/-/issues/226). The documentation at https://archives.dynare.org/DynareWiki/NewEstimation seems outdated.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1847Expand *_calibration to higher order2023-09-27T15:04:53ZJohannes PfeiferExpand *_calibration to higher orderCurrently, we only support first order. See also https://forum.dynare.org/t/gsa-of-irfs-with-a-higher-order-approximation/19758/2Currently, we only support first order. See also https://forum.dynare.org/t/gsa-of-irfs-with-a-higher-order-approximation/19758/27.xhttps://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/1843Fix stochastic singularity check with `heteroskedastic_shocks`2022-09-21T08:29:57ZJohannes PfeiferFix stochastic singularity check with `heteroskedastic_shocks`Johannes PfeiferJohannes Pfeiferhttps://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/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/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/1812diff() operator extension for quarterly data2021-09-16T13:47:23ZUgo Duboisdiff() operator extension for quarterly dataThe current diff() operator implementation only allows to get diff('variable') = variable(t) - variable(t-1).
Some equations in our model use Year over Year differences in quarterly time series variables.
We would like a diff() operat...The current diff() operator implementation only allows to get diff('variable') = variable(t) - variable(t-1).
Some equations in our model use Year over Year differences in quarterly time series variables.
We would like a diff() operator extension allowing us to write such a difference, for example this way:
diff('variable', X) = variable(t) - variable(t-X) where X is an integer representing the lag over which we want to get the variable differentiated (our use case would have X = 4). It might be an optional argument and/or default to 1 in order to preserve its current functioning.