dynare issueshttps://git.dynare.org/Dynare/dynare/issues2018-11-08T09:52:18Zhttps://git.dynare.org/Dynare/dynare/issues/614not balanced growth model not detected by test2018-11-08T09:52:18ZMichelJuillardnot balanced growth model not detected by testHere is an example where an error in trend declaration isn't detected by the balanced growth test. It may come from the fact that labor enhancing productivity (G) is not a variable of the model, just a trend. The error should appear for the equations defining r and w and for the resource constraint.
```
parameters rho delta gamma alpha lambda g;
trend_var(growth_factor=1+g) G;
// the trend of K is wrong:
var(deflator=G) C w;
var L r A K;
// Here is the correct specification:
// var(deflator=G) C w K;
// var L r A;
varexo e;
alpha = 0.33;
delta = 0.1;
rho = 0.03;
lambda = 0.97;
gamma = 0;
g = 0.015;
model;
1/C = 1/(1+rho)*(1/C(+1))*(r(+1)+1-delta);
L^gamma = w/C;
r = alpha*A*K(-1)^(alpha-1)*(G*L)^(1-alpha);
w = (1-alpha)*A*K(-1)^alpha*(G*L)^(-alpha);
K+C = K(-1)*(1-delta)+A*K(-1)^alpha*(G*L)^(1-alpha);
log(A) = lambda*log(A(-1))+e;
end;
steady_state_model;
A = 1;
r = (1+g)*(1+rho)+delta-1;
K_L = (1+g)*(r/(alpha*A))^(1/(alpha-1));
w = (1-alpha)*A*(K_L/(1+g))^alpha;
L = (-((delta+g)/(1+g))*K_L/w+A*(K_L/((1+g)*w^(1/alpha)))^alpha)
^(-1/(1+gamma));
K = K_L*L;
C = (1-delta)*K/(1+g)+(K_L/(1+g))^alpha*L-K;
end;
shocks;
var e; stderr 0.01;
end;
write_latex_dynamic_model;
steady;
check;
stoch_simul(order=1);
```
Here is an example where an error in trend declaration isn't detected by the balanced growth test. It may come from the fact that labor enhancing productivity (G) is not a variable of the model, just a trend. The error should appear for the equations defining r and w and for the resource constraint.
```
parameters rho delta gamma alpha lambda g;
trend_var(growth_factor=1+g) G;
// the trend of K is wrong:
var(deflator=G) C w;
var L r A K;
// Here is the correct specification:
// var(deflator=G) C w K;
// var L r A;
varexo e;
alpha = 0.33;
delta = 0.1;
rho = 0.03;
lambda = 0.97;
gamma = 0;
g = 0.015;
model;
1/C = 1/(1+rho)*(1/C(+1))*(r(+1)+1-delta);
L^gamma = w/C;
r = alpha*A*K(-1)^(alpha-1)*(G*L)^(1-alpha);
w = (1-alpha)*A*K(-1)^alpha*(G*L)^(-alpha);
K+C = K(-1)*(1-delta)+A*K(-1)^alpha*(G*L)^(1-alpha);
log(A) = lambda*log(A(-1))+e;
end;
steady_state_model;
A = 1;
r = (1+g)*(1+rho)+delta-1;
K_L = (1+g)*(r/(alpha*A))^(1/(alpha-1));
w = (1-alpha)*A*(K_L/(1+g))^alpha;
L = (-((delta+g)/(1+g))*K_L/w+A*(K_L/((1+g)*w^(1/alpha)))^alpha)
^(-1/(1+gamma));
K = K_L*L;
C = (1-delta)*K/(1+g)+(K_L/(1+g))^alpha*L-K;
end;
shocks;
var e; stderr 0.01;
end;
write_latex_dynamic_model;
steady;
check;
stoch_simul(order=1);
```
5.0Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1600look at preprocessor `output` option2018-10-02T14:54:31ZHoutan Bastanilook at preprocessor `output` optionWhat is `dynamic` used for?
Look at printing in `DynareMain2.cc`. Why do we switch on `output_mode` ?What is `dynamic` used for?
Look at printing in `DynareMain2.cc`. Why do we switch on `output_mode` ?Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1625Discuss implementing a steady_state_relation-block2018-09-12T08:10:51ZJohannes Pfeifer Discuss implementing a steady_state_relation-blockSteady state finding in large economic models is hard. Currently, the user needs to manually implement a full steady state or reduce the problem and then call a solver. See e.g. https://forum.dynare.org/t/how-to-solve-steady-state-in-large-scale-dsge-models/12185/2
I wonder if it would be useful and feasible to introduce something like a `steady_state_relation`-block that allows specifying analytical steady state relations that Dynare could use in the `_static`-file to substitute out some variable and thus reduce the size of the problem (essentially introducing a model-local variable for the static model). An example would be
```
steady_state_relation;
u=1;
R=1/beta;
Pi=1;
i_nom=R*Pi;
I=delta*K;
end;
```
Combined with `initval` this would make finding a steady state much easier.Steady state finding in large economic models is hard. Currently, the user needs to manually implement a full steady state or reduce the problem and then call a solver. See e.g. https://forum.dynare.org/t/how-to-solve-steady-state-in-large-scale-dsge-models/12185/2
I wonder if it would be useful and feasible to introduce something like a `steady_state_relation`-block that allows specifying analytical steady state relations that Dynare could use in the `_static`-file to substitute out some variable and thus reduce the size of the problem (essentially introducing a model-local variable for the static model). An example would be
```
steady_state_relation;
u=1;
R=1/beta;
Pi=1;
i_nom=R*Pi;
I=delta*K;
end;
```
Combined with `initval` this would make finding a steady state much easier.https://git.dynare.org/Dynare/dynare/issues/1407Keep track of whether smoother results are in logs and adjust smoother2histva...2018-09-11T15:00:44ZJohannes Pfeifer Keep track of whether smoother results are in logs and adjust smoother2histval accordinglySee #1396 See #1396 https://git.dynare.org/Dynare/dynare/issues/1438Write a unit test for mjdgges (m implementation)2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgWrite a unit test for mjdgges (m implementation)Based on matrices E and D from the example contributed by @JohannesPfeifer in #1154.Based on matrices E and D from the example contributed by @JohannesPfeifer in #1154.Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/642Support Dirichlet prior distribution2018-09-11T15:00:44ZHoutan 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.
5.0https://git.dynare.org/Dynare/dynare/issues/891adding options to irf/moment calibration2018-09-11T15:00:44ZMarco Rattoadding options to irf/moment calibrationWould it be possible to add options in the irf/moment calibration interface.
For example it would be good to allow:
```
irf_calibration(relative_irf);
...
end;
```
to allow triggering
`options_.relative_irf=1;`
In fact, when std of shocks are estimated, it makes probably more sense to target a relative response w.r.t. an absolute one, which might just change due to the change in the value of the shock.
Similarly, we might think of allowing `moment_calibration` to trigger estimation type options, like
```
varobs y_obs R_obs pie_obs dq de;
moment_calibration(datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1);
...
end;
```
that would allow me to write a routine that automatically generates data based moment restrictions up to lag `ar` for theoretical moments of the variables listed in `varobs`.
We might also allow a different list of variables for calibration w.r.t. estimation, e.g. by
```
varobs_calibration y_obs R_obs pie_obs dq de;
```
Or by adding the list of variables inside the `moment_calibration` command (like `namendo` comma separated list in sensitivity analysis)
```
moment_calibration( datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1,
varobs=(y_obs, R_obs, pie_obs, dq de)
);
...
end;
```
what do you think?
Would it be possible to add options in the irf/moment calibration interface.
For example it would be good to allow:
```
irf_calibration(relative_irf);
...
end;
```
to allow triggering
`options_.relative_irf=1;`
In fact, when std of shocks are estimated, it makes probably more sense to target a relative response w.r.t. an absolute one, which might just change due to the change in the value of the shock.
Similarly, we might think of allowing `moment_calibration` to trigger estimation type options, like
```
varobs y_obs R_obs pie_obs dq de;
moment_calibration(datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1);
...
end;
```
that would allow me to write a routine that automatically generates data based moment restrictions up to lag `ar` for theoretical moments of the variables listed in `varobs`.
We might also allow a different list of variables for calibration w.r.t. estimation, e.g. by
```
varobs_calibration y_obs R_obs pie_obs dq de;
```
Or by adding the list of variables inside the `moment_calibration` command (like `namendo` comma separated list in sensitivity analysis)
```
moment_calibration( datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1,
varobs=(y_obs, R_obs, pie_obs, dq de)
);
...
end;
```
what do you think?
https://git.dynare.org/Dynare/dynare/issues/909Create true unit test from comments in middle of random_walk_metropolis_hasti...2018-09-11T15:00:44ZJohannes Pfeifer Create true unit test from comments in middle of random_walk_metropolis_hastings.mThere is some advice for a manual unit test hidden there.
There is some advice for a manual unit test hidden there.
https://git.dynare.org/Dynare/dynare/issues/915Integrate convert_dyn_45_to_44 into convert_oo_.m2018-09-11T15:00:44ZJohannes Pfeifer Integrate convert_dyn_45_to_44 into convert_oo_.mSee the discussion in https://github.com/DynareTeam/dynare/commit/a93e0157e4ea0d3a2ee4d5b10842066a0a39c2e9#commitcomment-10984144
See the discussion in https://github.com/DynareTeam/dynare/commit/a93e0157e4ea0d3a2ee4d5b10842066a0a39c2e9#commitcomment-10984144
5.0Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/699Allow for constrained forecast paths of different length2018-09-11T15:00:44ZJohannes Pfeifer Allow for constrained forecast paths of different lengthUser request, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5888
User request, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5888
https://git.dynare.org/Dynare/dynare/issues/933Add load_mh_file-like option for loading posterior subdraws2018-09-11T15:00:44ZJohannes Pfeifer Add load_mh_file-like option for loading posterior subdrawsSee #566
See #566
https://git.dynare.org/Dynare/dynare/issues/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2018-09-11T15:00:44ZTom 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 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.
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/713Block recursive prior definitions2018-09-11T15:00:44ZJohannes Pfeifer Block recursive prior definitionsRecursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
Recursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
https://git.dynare.org/Dynare/dynare/issues/1243Allow model-local variables with block and bytecode2018-09-11T15:00:44ZJohannes 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?
FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/issues/1503Do we really need to have specific dynamic routines for deterministic and sto...2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgDo we really need to have specific dynamic routines for deterministic and stochastic models?See discussion in #1501.See discussion in #1501.https://git.dynare.org/Dynare/dynare/issues/1004Make initvalf and histvalf compatible with translation to one-lag problem2018-09-11T15:00:44ZJohannes 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
5.0https://git.dynare.org/Dynare/dynare/issues/762svar identification2018-09-11T15:00:44ZHoutan Bastanisvar identificationimplement partial/global identification for svar, based on Tao's paper
implement partial/global identification for svar, based on Tao's paper
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1245Make sure _dynamic-file from block returns with proper arguments2018-09-11T15:00:44ZJohannes Pfeifer Make sure _dynamic-file from block returns with proper argumentsCurrently, there are a few `return` statements where `varargout` has not been set, leading to crashes instead of proper switching to homotopy.
Currently, there are a few `return` statements where `varargout` has not been set, leading to crashes instead of proper switching to homotopy.
FerhatMihoubiFerhatMihoubihttps://git.dynare.org/Dynare/dynare/issues/1513Allow selecting proper training sample for endogenous_prior2018-09-11T15:00:44ZJohannes Pfeifer Allow selecting proper training sample for endogenous_priorCurrently, we simply use `Y=data';`, but it is straightforward to include different dataCurrently, we simply use `Y=data';`, but it is straightforward to include different data4.6https://git.dynare.org/Dynare/dynare/issues/773Fix preprocessor info on auxiliary variables2018-09-11T15:00:44ZJohannes Pfeifer Fix preprocessor info on auxiliary variablesSee #770
See #770
5.0Houtan BastaniHoutan Bastani