dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-09-25T08:38:53Zhttps://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2020-09-25T08:38:53ZMichelJuillardAdding support for dates in perfect_foresight_setupThe user should be able to control the dates of the dseries produced by ``perfect_foresight_solver``
- Currently, `histval``,``histval_file`` and ``initval_file`` pass a ``dseries` to ``perfect_foresight_setup``
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this ``dseries``
- dates must be permitted in ``histval`` instead of only signed integers
- ``first_obs``: sets the dates used for the first initial conditions. Must be consistent with ``histval`` or ``histval_file`` if they are used
- ``first_simulation_period``: sets the dates used for the first period of the simulation. It is an alternative to specifying ``first_obs`` and must be consistent if ``first_obs``is also used as an option. Values for initial conditions before this date must be available. Must be consistent with ``histval`` or ``histval_file`` if they are used.
- ``last_simulation_period``: sets the date of the last period of simulation. It is an alternative to specifying ``periods`` and must be consistent if ``periods``is also used as an option. Data for terminal conditions past the last period must be availableThe user should be able to control the dates of the dseries produced by ``perfect_foresight_solver``
- Currently, `histval``,``histval_file`` and ``initval_file`` pass a ``dseries` to ``perfect_foresight_setup``
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this ``dseries``
- dates must be permitted in ``histval`` instead of only signed integers
- ``first_obs``: sets the dates used for the first initial conditions. Must be consistent with ``histval`` or ``histval_file`` if they are used
- ``first_simulation_period``: sets the dates used for the first period of the simulation. It is an alternative to specifying ``first_obs`` and must be consistent if ``first_obs``is also used as an option. Values for initial conditions before this date must be available. Must be consistent with ``histval`` or ``histval_file`` if they are used.
- ``last_simulation_period``: sets the date of the last period of simulation. It is an alternative to specifying ``periods`` and must be consistent if ``periods``is also used as an option. Data for terminal conditions past the last period must be available4.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1744endogenous_prior with missing observation2020-09-21T10:32:53Znaivejendogenous_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 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
```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
```4.7https://git.dynare.org/Dynare/dynare/-/issues/1743Start diary earlier to include input arguments and Dynare version2020-09-21T10:32:05ZJohannes Pfeifer Start 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.4.7https://git.dynare.org/Dynare/dynare/-/issues/1742Fix reported problems in extended path2020-09-10T12:25:41ZJohannes Pfeifer Fix reported problems in extended pathSee https://forum.dynare.org/t/extended-path-bytecode/16577See https://forum.dynare.org/t/extended-path-bytecode/165774.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1739Investigate parallel issues2020-07-13T14:00:20ZJohannes Pfeifer Investigate 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/44.7https://git.dynare.org/Dynare/dynare/-/issues/1738Publication-quality plots2020-07-15T10:44:06ZWilli Mutschlerwilli@mutschler.euPublication-quality plotsMatlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?Matlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?https://git.dynare.org/Dynare/dynare/-/issues/1735Change treatment of jnl-file of k_order_perturbation2020-06-30T14:07:41ZJohannes Pfeifer Change 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.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1734Finish nonlinear prior restrictions2020-06-22T10:25:28ZJohannes Pfeifer Finish nonlinear prior restrictionsSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292aSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292a4.7https://git.dynare.org/Dynare/dynare/-/issues/1732Improve debugging options for perfect foresight2020-06-10T06:15:36ZJohannes Pfeifer Improve debugging options for perfect foresightWe occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)We occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)https://git.dynare.org/Dynare/dynare/-/issues/1731Error in derivatives of perfect foresight models with leaded or lagged exogen...2020-09-04T14:09:13ZMichelJuillardError 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](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.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.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1730Consider saving results using -v7.3 flag2020-06-15T10:29:17ZJohannes Pfeifer Consider saving results using -v7.3 flagWe may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.We may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.https://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2020-07-28T08:34:19ZSé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 a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.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/`.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2020-05-20T10:26:56ZSé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 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.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.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2020-05-20T10:14:37ZSé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 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.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.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2020-05-04T16:22:55ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16534.7https://git.dynare.org/Dynare/dynare/-/issues/1720lmmcp does not work with purely forward or backward models2020-04-11T19:23:48ZJohannes Pfeifer lmmcp 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 constraints. A current workaround is using dummy equations.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.4.7https://git.dynare.org/Dynare/dynare/-/issues/1718Auxillary particle filter --- number_of_state_variables is undefined2020-03-30T10:09:49ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes Pfeifer Fix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2020-03-07T17:21:34ZJohannes Pfeifer Clean root folder of /testsAll integration tests should be in subfolders. The current structure is a messAll integration tests should be in subfolders. The current structure is a mess4.7https://git.dynare.org/Dynare/dynare/-/issues/1709Automatic detrending2020-03-06T17:35:41ZFerhatMihoubiAutomatic detrendingFor the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.For the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.