dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-12-07T11:32:37Zhttps://git.dynare.org/Dynare/dynare/-/issues/1747bug in macro-processor2020-12-07T11:32:37ZMarco Rattobug in macro-processorwhen using `@#ifndef`, anything after `@#else` is never reached by macro-processor.
See attached test file [test.mod](/uploads/dac7995c3684f9b6a3a935071d05bac6/test.mod) where command in line 6 is never reached by macro-processor when t...when using `@#ifndef`, anything after `@#else` is never reached by macro-processor.
See attached test file [test.mod](/uploads/dac7995c3684f9b6a3a935071d05bac6/test.mod) where command in line 6 is never reached by macro-processor when the macro variable is defined (`@#else` works properly with `@#ifdef`, instead)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1744endogenous_prior with missing observation2020-11-13T12:20:25Znaivejendogenous_prior with missing observationHi dynare team,
(Sorry if I posted in the wrong place, I just realised that gitlab seems for developers only)
In v4.6.2, endogenous_prior cannot work with missing observation, but this is not pointed out in the Reference Manual.
I ...Hi dynare team,
(Sorry if I posted in the wrong place, I just realised that gitlab seems for developers only)
In v4.6.2, endogenous_prior cannot work with missing observation, but this is not pointed out in the Reference Manual.
I suppose a naive way to fix this is to exclude any period or variables with missing observations in the calculation of statistics.
Currently, I modified the code as follows but not sure if this is statistically correct. Is there a better way to make this work?
```matlab
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
Fhat=std(Ydemean,1,'omitnan').^2';
for j=1:n
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
end
Fhat=std(Ydemean,1,'omitnan').^2';%Fhat=diag(Ydemean'*Ydemean)/Tsamp;
Sgood=find(~any(isnan(Y),2));
Tgood=length(Sgood);
hmat=zeros(n,Tgood);
% we need ht, where t=1,...,T
for t=1:Tgood
hmat(:,t)=diag(Ydemean(Sgood(t),:)'*Ydemean(Sgood(t),:))-Fhat;
end
% To calculate Shat we need C0, C1 and C2
for t=1:Tgood
C0=C0+1/Tgood*hmat(:,t)*hmat(:,t)';
end
for t=2:Tgood
C1=C1+1/(Tgood-1)*hmat(:,t)*hmat(:,t-1)';
end
for t=3:Tgood
C2=C2+1/(Tgood-2)*hmat(:,t)*hmat(:,t-2)';
end
```5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1743Start diary earlier to include input arguments and Dynare version2021-01-06T16:32:28ZJohannes PfeiferStart diary earlier to include input arguments and Dynare versionCurrently, the diary only starts after the version and the input arguments have been printed. That way, important information is missing when calling a mod-file with command-line switches.Currently, the diary only starts after the version and the input arguments have been printed. That way, important information is missing when calling a mod-file with command-line switches.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1742Fix reported problems in extended path2020-10-16T15:27:19ZJohannes PfeiferFix reported problems in extended pathSee https://forum.dynare.org/t/extended-path-bytecode/16577See https://forum.dynare.org/t/extended-path-bytecode/165775.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1741Linear algorithm for perfect foresight is buggy when there are lagged exogeno...2020-09-04T14:07:56ZMichelJuillardLinear algorithm for perfect foresight is buggy when there are lagged exogenous variables in the modelThe algorithm implemented in ``sim1_linear.m`` is wrong when there are lagged exogenous variables because it relies on the derivatives of exogenous variables that are themselves wrong because of the issue reported in #1731The algorithm implemented in ``sim1_linear.m`` is wrong when there are lagged exogenous variables because it relies on the derivatives of exogenous variables that are themselves wrong because of the issue reported in #17315.xhttps://git.dynare.org/Dynare/dynare/-/issues/1740Investigate MS-BVAR problems on Windows2020-08-27T08:30:31ZJohannes PfeiferInvestigate MS-BVAR problems on WindowsThe `test_ms_variances.mod` fails in `4.6.1` with
```
Unable to create the starting point data file est_csminwel_test_ms_variances.out in csminwel.c!
Error in MS-SBVAR MEX file.
```The `test_ms_variances.mod` fails in `4.6.1` with
```
Unable to create the starting point data file est_csminwel_test_ms_variances.out in csminwel.c!
Error in MS-SBVAR MEX file.
```5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1739Investigate parallel issues2020-11-13T10:56:40ZJohannes PfeiferInvestigate parallel issuesSee https://forum.dynare.org/t/parallel-estimation-mcmc-diagnostics-issue/16228/4See https://forum.dynare.org/t/parallel-estimation-mcmc-diagnostics-issue/16228/45.xhttps://git.dynare.org/Dynare/dynare/-/issues/1737Provide disclyap_fast.m as a mex-file2020-07-30T15:13:17ZJohannes PfeiferProvide disclyap_fast.m as a mex-filePreliminary testing with the Matlab Coder in C++ indicated significant speed gains (factor 3 for a 54 by 54 matrix). Useful as there may be thousands of calls in the context of GMM.
We currently do not use the `chol`-check anywhere. So m...Preliminary testing with the Matlab Coder in C++ indicated significant speed gains (factor 3 for a 54 by 54 matrix). Useful as there may be thousands of calls in the context of GMM.
We currently do not use the `chol`-check anywhere. So may leave it out and only code the main loop.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1735Change treatment of jnl-file of k_order_perturbation2020-10-16T15:27:19ZJohannes PfeiferChange treatment of jnl-file of k_order_perturbationDisable the writing of the file to the hard-disk by default. Implement an additional input argument so that options_.debug triggers writing this file.Disable the writing of the file to the hard-disk by default. Implement an additional input argument so that options_.debug triggers writing this file.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1734Finish nonlinear prior restrictions2021-08-17T19:04:34ZJohannes PfeiferFinish nonlinear prior restrictionsSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292aSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292a5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1733Fix identification issues around steady state file2020-06-22T08:35:36ZJohannes PfeiferFix identification issues around steady state fileThe issue popped up in https://forum.dynare.org/t/mode-check-plots-with-flat-lines/16020/13 with the attached files. From what I can see, the issue is parameters being updated in the steady state file. Identification in `4.7` seems unabl...The issue popped up in https://forum.dynare.org/t/mode-check-plots-with-flat-lines/16020/13 with the attached files. From what I can see, the issue is parameters being updated in the steady state file. Identification in `4.7` seems unable to handle this. If I am not mistaken (@rattoma should know better), this is a regression as in the past, we resorted to simulation instead of theoretical derivatives which are now unavailable.
[Model.mod](/uploads/7416c13b9a736cfe8133774f9342b9bd/Model.mod)
[SOEMData.xlsx](/uploads/9121d21da0eed219d98bac015f97d9ec/SOEMData.xlsx)
[Model_steadystate.m](/uploads/914342354a7271f21b18cdb9130e03ad/Model_steadystate.m)5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1731Error in derivatives of perfect foresight models with leaded or lagged exogen...2021-01-13T17:20:08ZMichelJuillardError in derivatives of perfect foresight models with leaded or lagged exogenous variablesA perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploa...A perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2021-01-19T09:49:57ZSébastien VillemotImprovements to make install ruleCurrently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to...Currently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1727Blocks of type "evaluate backward" are not correctly simulated2020-09-23T13:29:57ZSébastien VillemotBlocks of type "evaluate backward" are not correctly simulatedThe testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The t...The testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2021-05-07T17:10:32ZSébastien VillemotOption mfs=3 gives wrong resultThe `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible ...The `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2021-05-04T09:21:20ZSébastien VillemotBetter interface for mfs optionThe `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is t...The `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1724Discuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)2020-08-05T14:38:34ZWilli Mutschlerwilli@mutschler.euDiscuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. ...Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. I have a couple of questions|proposal for the best interface and call for this and would like your guys take on this.
### Declaring parameters
Here I would simply opt to what we do in a Maximum likelihood estimation and use the same syntax in an `estimated_params` or an `estimated_params_bounds` block:
```
stderr VARIABLE_NAME | corr VARIABLE_NAME_1, VARIABLE_NAME_2 | PARAMETER_NAME, LOWER_BOUND, UPPER_BOUND;
```
### Declaring which moments to use
Here I would propose a block similar to `moment_calibration`, but call it `estimated_moments`:
```
estimated_moments;
y_obs,y_obs; //[unconditional variance]
y_obs,y_obs(-(1:4)); //[some acf]
@#for ilag in -2:2
y_obs,R_obs(@{ilag}); //[ccf]
@#endfor
end;
```
### Invocation
Now the toughest question. How to invoke it? I see two options.
Option A: Add an option to `estimation`, e.g.
```
estimation(moments_estimation='GMM');
```
Option B: Have an own command for this, e.g.:
```
gmm_estimation(OPTIONS);
smm_estimation(OPTIONS);
irf_matching(OPTIONS);
```
which then internally calls a wrapper `dynare_moments_estimation.m` and runs the toolbox.
What do you guys think?5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1723Equations defining model local variables are not included in generated JSON f...2020-06-05T16:31:12ZTom HoldenEquations defining model local variables are not included in generated JSON filesThis bug came up in conversation with @MichelJuillard .
For example, this model block:
```
model;
#Pi=exp(pi);
#Pi_LEAD=exp(pi(1));
#Pi_STEADY=exp(pi_STEADY);
#kappa=(gamma/2)*(Pi-1)^2;
#kappa_STEADY=(gamma/2)*(Pi_STEADY-1)^2;
#c=log(1-...This bug came up in conversation with @MichelJuillard .
For example, this model block:
```
model;
#Pi=exp(pi);
#Pi_LEAD=exp(pi(1));
#Pi_STEADY=exp(pi_STEADY);
#kappa=(gamma/2)*(Pi-1)^2;
#kappa_STEADY=(gamma/2)*(Pi_STEADY-1)^2;
#c=log(1-kappa-eta)+y;
#c_LEAD=log(1-(gamma/2)*(Pi_LEAD-1)^2-eta)+y(1);
#h=y-z;
#w=sigma*c+nu*h-log(1-tauw);
#re=-log(beta)-d(1)+pi_STEADY;
#y_STEADY=(1/(sigma+nu))*(log((1-tauw)*((1-beta)*(Pi_STEADY-1)*Pi_STEADY/theta*gamma+1))-sigma*log(1-kappa_STEADY-eta));
#gdp=log(1-kappa)+y;
#gdp_STEADY=log(1-kappa_STEADY)+y_STEADY;
#dynareOBCMaxArgA1=(0);
#dynareOBCMaxArgB1=(re+phi_pi*(pi-pi_STEADY)+phi_y*(gdp-gdp_STEADY));
#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);
r=(dynareOBCMaxFunc1);
1=beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD));
(Pi-1)*Pi=theta/gamma*(exp(w-z)-1)+beta*exp(d(1)+sigma*(c-c_LEAD)+y(1)-y)*(Pi_LEAD-1)*Pi_LEAD;
d=rhod*d(-1)+sigmad*epsilond;
z=rhoz*z(-1)+sigmaz*epsilonz;
end;
```
becomes this in the JSON file (with `json=parse`):
```
...
"model":[
{"lhs": "r", "rhs": "dynareOBCMaxFunc1", "line": 37}
, {"lhs": "1", "rhs": "beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD))", "line": 38}
, {"lhs": "Pi*(Pi-1)", "rhs": "theta/gamma*(exp(w-z)-1)+Pi_LEAD*(Pi_LEAD-1)*beta*exp(y(1)+d(1)+sigma*(c-c_LEAD)-y)", "line": 39}
, {"lhs": "d", "rhs": "rhod*d(-1)+sigmad*epsilond", "line": 40}
, {"lhs": "z", "rhs": "rhoz*z(-1)+sigmaz*epsilonz", "line": 41}
]
, "xrefs": {"parameters": [], "endogenous": [], "exogenous": [], "exogenous_deterministic": []}
, "abstract_syntax_tree":[
{ "number":0, "line":37, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "dynareOBCMaxFunc1", "type" : "modelLocalVariable", "lag" : 0}}}, { "number":1, "line":38, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "NumConstNode", "value" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}}, "arg2" : {"node_type" : "VariableNode", "name" : "pi", "type" : "endogenous", "lag" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}}}}, { "number":2, "line":39, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "/", "arg1" : {"node_type" : "VariableNode", "name" : "theta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "gamma", "type" : "parameter", "lag" : 0}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "w", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}}}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}, "arg2" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 0}}}}}}}}}, { "number":3, "line":40, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhod", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmad", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilond", "type" : "exogenous", "lag" : 0}}}}}, { "number":4, "line":41, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhoz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmaz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilonz", "type" : "exogenous", "lag" : 0}}}}}], "variable_mapping":[
], "statements": [{"statementName": "param_init", "name": "beta", "value": "0.997"},
...
```5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1722Provide mapping between model local variable names and indices in the T vector2020-06-05T16:31:12ZTom HoldenProvide mapping between model local variable names and indices in the T vectorPer a request from a DynareOBC user, today I started working on making DynareOBC compatible with Dynare 4.6.
This is proving harder than expected due to the changes to preprocessor output.
Previously, DynareOBC relied on the *_static.m...Per a request from a DynareOBC user, today I started working on making DynareOBC compatible with Dynare 4.6.
This is proving harder than expected due to the changes to preprocessor output.
Previously, DynareOBC relied on the *_static.m and *_dynamic.m files containing lines giving the value of model local variables (MLVs). This is used in multiple places, e.g. for obtaining the steady state of the augmented model, or for generating code for MLV simulation.
Of course, it is not your duty to support DynareOBC, but having this information in the static and dynamic files was generally useful. For example, in code prepared for the Dynare summer school I used to teach, I used this feature to facilitate writing code for a "perturbation plus" type simulation algorithm (i.e. perturbation used for next period values conditional on today's state and future shock, but given this approximation, the full nonlinear equations + cubature were used to derive today's value).
To make things easy again, it would be sufficient if the generated *_tt.m added comments at the end of each line defining a temporary variable (i.e. T(*)) definition with the name of the MLV to which the given element T(*) corresponds. E.g.:
`#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);`
would become:
`T(14) = max(T(12),T(13)); % dynareOBCMaxFunc1`
Alternatively, the optionally generated JSON could contain this information.
However, I guess that for either of these approaches to be viable as a strategy for DynareOBC to support Dynare 4.6, this would need to be added to Dynare fairly quickly (e.g. for 4.6.2), which may not be viable.
If this is not possible, (and in any case), it would be good to have some documentation of what users can safely assume about the elements of the T vector. A few relevant questions follow:
1. Are all MLVs defined in the model block and used somewhere in the model guaranteed to be in the T vector?
2. If MLV A is defined before MLV B in the model block, then will A definitely be before B in the T vector?
3. Are the MLVs guaranteed to be the first elements of the T vector, or could MLVs and generated temporaries be interspersed?5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1720lmmcp does not work with purely forward or backward models2020-10-22T13:37:07ZJohannes Pfeiferlmmcp does not work with purely forward or backward modelsIn this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constr...In this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constraints. A current workaround is using dummy equations.5.xSébastien VillemotSébastien Villemot