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/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/1684New WITH_TREND() operator for epilogue block2023-09-27T15:06:41ZSébastien VillemotNew WITH_TREND() operator for epilogue blockImplement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, whi...Implement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #16487.xhttps://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/978Fix interface/options for stochastic extended path in master2021-11-11T13:22:27ZJohannes PfeiferFix 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 a...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.https://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 sho...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/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/614Have balanced growth test consider steady_state_model-block2022-12-09T13:31:48ZMichelJuillardHave balanced growth test consider steady_state_model-blockHere 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 ...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);
```https://git.dynare.org/Dynare/dynare/-/issues/300Implement k-order derivatives of external functions2023-02-24T21:55:57ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor errorOtherwise order ≥ 3 fails with a cryptic preprocessor errorhttps://git.dynare.org/Dynare/dynare/-/issues/135Improve display of decision rules with EXPECTATION operator2019-11-21T08:36:45ZSébastien VillemotImprove display of decision rules with EXPECTATION operatorCurrently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression)...Currently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.