dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-09-07T08:31:51Zhttps://git.dynare.org/Dynare/dynare/-/issues/1901Improve convergence diagnostics2023-09-07T08:31:51ZJohannes PfeiferImprove convergence diagnostics1. Multivariate instead of univariate diagnostics https://academic.oup.com/biomet/article-abstract/106/2/321/5426969?redirectedFrom=fulltext and https://doi.org/10.1214/20-STS812
2. Have quantitative instead of eyeballing test for multi...1. Multivariate instead of univariate diagnostics https://academic.oup.com/biomet/article-abstract/106/2/321/5426969?redirectedFrom=fulltext and https://doi.org/10.1214/20-STS812
2. Have quantitative instead of eyeballing test for multiple chains.https://git.dynare.org/Dynare/dynare/-/issues/1899Document of fix behavior of det_cond_forecast2023-08-30T18:18:30ZJohannes PfeiferDocument of fix behavior of det_cond_forecastFrom https://forum.dynare.org/t/error-messages-when-building-the-forecast/22873/4.
I think there is either a bug or the manual is wrong. `det_cond_forecast` seems to always expect three input arguments, i.e. the initial forecast date is...From https://forum.dynare.org/t/error-messages-when-building-the-forecast/22873/4.
I think there is either a bug or the manual is wrong. `det_cond_forecast` seems to always expect three input arguments, i.e. the initial forecast date is mandatory.
[IN_AUX.csv](/uploads/ed7b4b47377fb38a92a99c7b0c571549/IN_AUX.csv)
[UForecast.mod](/uploads/e9d55faa83615f4f0040c5bbb45e2d41/UForecast.mod)
Moreover, the second argument is supposed to indicate the past values of the endogenous variables. But using [UForecast_3_arguments.mod](/uploads/bf27cd7ac32670a1a9b5a09b9184e493/UForecast_3_arguments.mod) I get the error message
> the dseries smoothed finish at time 2023Q2 before the last period of forecast 2024Q3
which does not make sense if only past values are needed.https://git.dynare.org/Dynare/dynare/-/issues/1896Discuss detrending of lagged trend_var2023-07-28T08:06:08ZJohannes PfeiferDiscuss detrending of lagged trend_varConsider
```
var gd, gu;
trend_var(growth_factor=gu) Bu;
trend_var(growth_factor=gd) Bd;
varexo vd,vu;
parameters gamu,gamd,thetadu;
gamu=.01;
gamd=.003;
thetadu=0.3;
model;
log(gu)=log(1+gamu)+vu;
log(gd)=log(1+gamd)+thetadu*l...Consider
```
var gd, gu;
trend_var(growth_factor=gu) Bu;
trend_var(growth_factor=gd) Bd;
varexo vd,vu;
parameters gamu,gamd,thetadu;
gamu=.01;
gamd=.003;
thetadu=0.3;
model;
log(gu)=log(1+gamu)+vu;
log(gd)=log(1+gamd)+thetadu*log(Bu(-1)/Bd(-1))+thetadu*log((1+gamu)/(1+gamd))+vd;
end;
initval;
gu=1.01;
gd=1.003;
vd = 0; vu=0;
end;
steady;
check;
shocks;
var vd; stderr 0.02;
var vu; stderr 0.02;
end;
write_latex_dynamic_model;
collect_latex_files;
stoch_simul(irf=150,order=1) gu gd;
```
from https://forum.dynare.org/t/impulse-responses-with-cointegrated-stochastic-trends/22756
Internally, we replace the lagged `trend_var Bu`, i.e. `Bu(-1)`, by its definition `Bu/gu`. The problem is that we then use the normalization `Bu=1`, i.e. we fix today's value of the trend and have `gu` implicitly determine the predetermined value yesterday. As a consequence, the variable `gd` on the left suddenly reacts contemporaneously to `gu`, although in the original equation everything on the right was predetermined. My understanding is that for a stochastic `growth_factor` this detrending approach is problematic as we are violating predeterminedness. What is the solution to this issue? Normalizing an endogenous object at time $t$ to 1 seems to be poor practice. At a minimum, we need to document the current behavior.https://git.dynare.org/Dynare/dynare/-/issues/1895macOS: add option to choose compiler and investigate whether to make Clang th...2023-12-14T20:02:01ZWilli Mutschlerwilli@mutschler.eumacOS: add option to choose compiler and investigate whether to make Clang the default oneIn some testing with the EAGLE model and the `use_dll` option it seems that Apple's Clang compiler (under x86_64 Rosetta with the default flags) is faster than Homebrew's GCC compiler with our optimized choice of flags. This requires som...In some testing with the EAGLE model and the `use_dll` option it seems that Apple's Clang compiler (under x86_64 Rosetta with the default flags) is faster than Homebrew's GCC compiler with our optimized choice of flags. This requires some more testing to decide whether to make it the default and/or even improve the choice of flags for Clang. Either way, it would be good to have an option to choose the compiler, because as of Dynare/preprocessor!79 we prioritize GCC and use Clang only as a fallback.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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/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/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/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.