dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2018-11-08T10:15:22Zhttps://git.dynare.org/Dynare/dynare/-/issues/1400Investigate dseries problems in parallel execution2018-11-08T10:15:22ZJohannes Pfeifer Investigate dseries problems in parallel executionWhen executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
When executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1338risky steady state: no interface, test suite2019-11-21T08:25:49ZHoutan Bastanirisky steady state: no interface, test suiteThere are several issues with risky steady state:
1. It has no interface. Why? Is this something we want to keep (hidden) in Dynare?
1. It the .mod files that use it are not in the test suite. Why?
There are several issues with risky steady state:
1. It has no interface. Why? Is this something we want to keep (hidden) in Dynare?
1. It the .mod files that use it are not in the test suite. Why?
4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1282MS-SBVAR: Potentially allow for linear restrictions across A0 and Aplus2018-09-11T15:00:44ZJohannes Pfeifer MS-SBVAR: Potentially allow for linear restrictions across A0 and AplusAfter a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
After a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
https://git.dynare.org/Dynare/dynare/-/issues/1243Allow model-local variables with block and bytecode2020-05-06T12:41:19ZJohannes Pfeifer Allow model-local variables with block and bytecodeWe currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variables seem the only way to go. We should therefore allow them.
@houtanb Where exactly is the challenge from the proprocessor-side?
We currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variables seem the only way to go. We should therefore allow them.
@houtanb Where exactly is the challenge from the proprocessor-side?
4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1208updated2histval2019-11-21T08:36:40ZMarco Rattoupdated2histvalfor real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
for real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
https://git.dynare.org/Dynare/dynare/-/issues/1204Crash in unstable mex when called from parallel workers2019-11-21T08:36:45ZTom HoldenCrash in unstable mex when called from parallel workersI'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
I'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1173Support estimation under optimal policy2020-02-12T16:18:04ZJohannes Pfeifer Support estimation under optimal policySee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2019-11-21T08:36:42ZTom HoldenNon-bayesian estimation should use quasi-Maximum likelihood standard errorsAt present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
At present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1162Handling of trends2019-11-21T08:36:41ZMichelJuillardHandling of trendsCurrently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
Currently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
https://git.dynare.org/Dynare/dynare/-/issues/1114create contributions.md describing how to contribute to dynare2019-11-26T16:30:56ZHoutan Bastanicreate contributions.md describing how to contribute to dynareStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1112homogeneize treatment of leads/lags on exogenous between deterministic and st...2020-05-07T17:46:06ZHoutan 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_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.
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.
https://git.dynare.org/Dynare/dynare/-/issues/1078Make lyapunov_symm compatible with sparse matrices2019-11-21T08:36:41ZJohannes Pfeifer Make lyapunov_symm compatible with sparse matricesAs discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
As discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
https://git.dynare.org/Dynare/dynare/-/issues/1060Add capabilities for pseudo out of sample forecasting2019-11-21T08:36:44ZJohannes Pfeifer Add capabilities for pseudo out of sample forecastingAllow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
Allow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
https://git.dynare.org/Dynare/dynare/-/issues/1056Document the data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDocument the data commandStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1055Deprecate first_obs and last_obs in data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDeprecate first_obs and last_obs in data commandReplaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Replaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1044Clear up option mh_posterior_mode_estimation2018-09-11T15:00:44ZJohannes Pfeifer Clear up option mh_posterior_mode_estimationSee the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
See the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
https://git.dynare.org/Dynare/dynare/-/issues/1045Clarify interface for evaluate_planner_objective.m2020-03-02T10:03:52ZMichelJuillardClarify interface for evaluate_planner_objective.mIt works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing
It works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1031declare all options_ fields as empty/0/NaN in global_initialization2019-11-21T08:36:43ZHoutan Bastanideclare all options_ fields as empty/0/NaN in global_initializationFollowing the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
Following the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
https://git.dynare.org/Dynare/dynare/-/issues/1004Make initvalf and histvalf compatible with translation to one-lag problem2019-11-26T15:21:02ZJohannes Pfeifer Make initvalf and histvalf compatible with translation to one-lag problemWe currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #617
We currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #617
https://git.dynare.org/Dynare/dynare/-/issues/978Fix interface/options for stochastic extended path in master2019-04-01T07:09:38ZJohannes Pfeifer Fix interface/options for stochastic extended path in masterNot all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
Not all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
MichelJuillardMichelJuillard