dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2024-02-16T09:37:44Zhttps://git.dynare.org/Dynare/dynare/-/issues/1921Rebase docker containers on Debian2024-02-16T09:37:44ZWilli Mutschlerwilli@mutschler.euRebase docker containers on DebianCurrently the Docker images are based on images that MATHWORKs provides and maintains. This has some benefits:
- easier to maintain
- user-friendly ways to interact with the container
- no hassle with the MATLAB license, and if so, we ca...Currently the Docker images are based on images that MATHWORKs provides and maintains. This has some benefits:
- easier to maintain
- user-friendly ways to interact with the container
- no hassle with the MATLAB license, and if so, we can easily direct users towards the MATLAB support
- sponsored MATLAB licenses (e.g. on GitHub) work
But also some disadvantages:
- we are not in full control of the image
- image size is somewhat large
- Octave version is too old in Ubuntu 22.04
- Octave compatibility is not great (the testsuite for Octave typically does not pass for some system-related reason)
- requires additional hacking to improve compatibility with Dynare
- MATLAB does change things from time-to-time and we (or I) need to keep track of the corresponding GitHub repositories
A natural alternative would be to create a vanilla image along the lines we set up the runners that are based on Debian. We would then need to provide similar ways to interact with the container (e.g. [noVNC](https://novnc.com)) and check whether sponsored licenses still work. We would probably loose some user-friendliness here, but then again those who are using Docker might not really need those interactive features.
So, I would like to open this issue to discuss how we should proceed in the future? I'm leaning towards keeping it based on MATHWORK's containers as this is probably easier to maintain; but I have no problem to investigate time and resources towards the Debian option.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1909macOS distribution: pkg installer vs homebrew2023-10-02T11:57:33ZWilli Mutschlerwilli@mutschler.eumacOS distribution: pkg installer vs homebrew1) Dynare for Octave is distributed already via Homebrew in this [dynare.rb](https://github.com/Homebrew/homebrew-core/blob/d01b7db772f9fa2df063db360ca3dd884f0a1047/Formula/d/dynare.rb). We should probably also try to get Dynare with MAT...1) Dynare for Octave is distributed already via Homebrew in this [dynare.rb](https://github.com/Homebrew/homebrew-core/blob/d01b7db772f9fa2df063db360ca3dd884f0a1047/Formula/d/dynare.rb). We should probably also try to get Dynare with MATLAB available with brew as well, similar to how we package on Debian.
2) Additionally, or alternatively, we should also add the Octave files in the pkg installer that we distribute.
3) Lastly, we should decide whether we keep the pkg installer, go solely the homebrew way, or do both.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1896Discuss detrending of lagged trend_var2023-07-28T08:06:08ZJohannes PfeiferDiscuss detrending of lagged trend_varConsider
```
var gd, gu;
trend_var(growth_factor=gu) Bu;
trend_var(growth_factor=gd) Bd;
varexo vd,vu;
parameters gamu,gamd,thetadu;
gamu=.01;
gamd=.003;
thetadu=0.3;
model;
log(gu)=log(1+gamu)+vu;
log(gd)=log(1+gamd)+thetadu*l...Consider
```
var gd, gu;
trend_var(growth_factor=gu) Bu;
trend_var(growth_factor=gd) Bd;
varexo vd,vu;
parameters gamu,gamd,thetadu;
gamu=.01;
gamd=.003;
thetadu=0.3;
model;
log(gu)=log(1+gamu)+vu;
log(gd)=log(1+gamd)+thetadu*log(Bu(-1)/Bd(-1))+thetadu*log((1+gamu)/(1+gamd))+vd;
end;
initval;
gu=1.01;
gd=1.003;
vd = 0; vu=0;
end;
steady;
check;
shocks;
var vd; stderr 0.02;
var vu; stderr 0.02;
end;
write_latex_dynamic_model;
collect_latex_files;
stoch_simul(irf=150,order=1) gu gd;
```
from https://forum.dynare.org/t/impulse-responses-with-cointegrated-stochastic-trends/22756
Internally, we replace the lagged `trend_var Bu`, i.e. `Bu(-1)`, by its definition `Bu/gu`. The problem is that we then use the normalization `Bu=1`, i.e. we fix today's value of the trend and have `gu` implicitly determine the predetermined value yesterday. As a consequence, the variable `gd` on the left suddenly reacts contemporaneously to `gu`, although in the original equation everything on the right was predetermined. My understanding is that for a stochastic `growth_factor` this detrending approach is problematic as we are violating predeterminedness. What is the solution to this issue? Normalizing an endogenous object at time $t$ to 1 seems to be poor practice. At a minimum, we need to document the current behavior.https://git.dynare.org/Dynare/dynare/-/issues/1788Equations for expectation variables in the .mod file of a model2021-11-10T09:58:39ZAnastasia ZhEquations for expectation variables in the .mod file of a modelAt this stage equations for the PV variables are created by `var_expectation(varexp)` or `pac_expectation(pacman)` which can be found then in the generated .inc files.
It is preferable to have them appear directly in the .mod file of t...At this stage equations for the PV variables are created by `var_expectation(varexp)` or `pac_expectation(pacman)` which can be found then in the generated .inc files.
It is preferable to have them appear directly in the .mod file of the model.
Here is one way of doing it. Say we cherrypick a pac equation from an estimation file. Then the generated simulation file used afterward to aggregate a big model shall automatically include an equation for expectation variable used in this pac equation.https://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2023-10-02T15:42:24ZMichelJuillardAdding 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_...The 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 availablehttps://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...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/1700Proposal for a generalized solver2023-09-27T15:13:41ZMichelJuillardProposal for a generalized solverModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function tha...Model inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithm7.xhttps://git.dynare.org/Dynare/dynare/-/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2023-10-02T15:45:03ZStéphane Adjemianstepan@adjemian.euBehavior of STEADY_STATE() in perfect foresight models with anticipated permanent shocks.In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent sh...In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).