dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2024-02-29T12:53:15Zhttps://git.dynare.org/Dynare/dynare/-/issues/1884Investigate why det_cond_forecast does not distinguish between surprise and a...2024-02-29T12:53:15ZJohannes PfeiferInvestigate why det_cond_forecast does not distinguish between surprise and anticipated shocksSee [simulation_det_cond.mod](/uploads/f162f70fa8cd7a060919c6902e6ca1da/simulation_det_cond.mod)See [simulation_det_cond.mod](/uploads/f162f70fa8cd7a060919c6902e6ca1da/simulation_det_cond.mod)Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1815bytecode locks .bin file after entering homotopy.2021-09-20T16:44:50ZJohannes Pfeiferbytecode locks .bin file after entering homotopy.Running [ireland.mod](/uploads/27aa0ebc6b17c399aa0a9f0ee2929c23/ireland.mod) triggers an exception
`Fatal error in bytecode: umfpack_dl_solve failed`
in the first iteration so that we enter homotopy mode. This it successful. But subseque...Running [ireland.mod](/uploads/27aa0ebc6b17c399aa0a9f0ee2929c23/ireland.mod) triggers an exception
`Fatal error in bytecode: umfpack_dl_solve failed`
in the first iteration so that we enter homotopy mode. This it successful. But subsequently, the mod-file cannot be run a second time due to `model/bytecode/dynamic.bin` being locked. It seems that
`SparseMatrix.cc` opens
```
SaveCode.open(file_name + "/model/bytecode/dynamic.bin", ios::in | ios::binary);
```
but never closes it in case of an exception.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1243Allow model-local variables with block and bytecode2020-11-13T09:06:11ZJohannes PfeiferAllow 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 variable...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?
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/1652Crash in bytecode2019-12-03T14:45:18ZSébastien VillemotCrash in bytecodeI attach an example ([surprise_solution.zip](/uploads/17158ceefc6fbf59f6810d17cbcdc084/surprise_solution.zip)) that crashes bytecode (just by running `surprise_solution_2019_05_20.mod`).
The problem can be reproduced both with unstable ...I attach an example ([surprise_solution.zip](/uploads/17158ceefc6fbf59f6810d17cbcdc084/surprise_solution.zip)) that crashes bytecode (just by running `surprise_solution_2019_05_20.mod`).
The problem can be reproduced both with unstable and 4.5.
*Note:* comes from https://forum.dynare.org/t/matlab-shutdown-deterministic-solution-stack-solve-algo-1/138824.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/841Investigate crash in bytecode due to incompatible dimensions of jacobia_2019-06-19T15:38:02ZJohannes PfeiferInvestigate crash in bytecode due to incompatible dimensions of jacobia_See Email from 22.01.2015
The problem is due to some exogenous (e7, e8) being declared but not used in the model. Removing them solves the issue.
See Email from 22.01.2015
The problem is due to some exogenous (e7, e8) being declared but not used in the model. Removing them solves the issue.
4.5MichelJuillardHoutan BastaniMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1285bytecode crash in Octave2019-06-19T15:37:47ZHoutan Bastanibytecode crash in Octave`tests/conditional_forecasts/5/fs2000_cal.mod` causes Octave 4.0.3 to crash. Seems like a memory management problem as the error message is:
```
computing the first order solution of the model as initial guess...*** Error in '/usr/bin/o...`tests/conditional_forecasts/5/fs2000_cal.mod` causes Octave 4.0.3 to crash. Seems like a memory management problem as the error message is:
```
computing the first order solution of the model as initial guess...*** Error in '/usr/bin/octave-cli': double free or corruption (out): 0x00000000020b3630 ***
panic: Aborted -- stopping myself...
```
This may also be linked to the testsuite error in Matlab.
4.5https://git.dynare.org/Dynare/dynare/-/issues/1439Fix bytecode memory problem introduced in #14202019-06-19T15:37:44ZJohannes PfeiferFix bytecode memory problem introduced in #1420#1420 changed the memory allocation. Since then `ramst_normcdf_and_friends_static` fails with
```
Fatal error in bytecode: mxMalloc: out of memory 352 bytes required at line 1915 in function Init_GE (file ../../../sources/bytecode/Spar...#1420 changed the memory allocation. Since then `ramst_normcdf_and_friends_static` fails with
```
Fatal error in bytecode: mxMalloc: out of memory 352 bytes required at line 1915 in function Init_GE (file ../../../sources/bytecode/SparseMatrix.cc
```https://git.dynare.org/Dynare/dynare/-/issues/439Bytecode does not enforce positivity constraint on irreversible investment model2019-02-08T08:31:00ZSébastien VillemotBytecode does not enforce positivity constraint on irreversible investment modelIn the following RBC model with irreversible investment, the positivity constraint is not enforced if simulated with block+bytecode. On the contrary, if block+bytecode is removed, the classic deterministic solver gives the right result.
...In the following RBC model with irreversible investment, the positivity constraint is not enforced if simulated with block+bytecode. On the contrary, if block+bytecode is removed, the classic deterministic solver gives the right result.
```
var k, y, l, c, i, A, a, expterm, mu;
varexo epsilon;
parameters beta, theta, tau, alpha, psi, delta, rho, Astar, sigma;
beta = 0.990;
theta = 0.357;
tau = 2.000;
alpha = 0.450;
psi = -2.500;
delta = 0.020;
rho = 0.998;
Astar = 1.000;
sigma = 0.100;
model(differentiate_forward_vars,block,bytecode,cutoff=0);
a = rho*a(-1) + sigma*epsilon;
A = Astar*exp(a);
mu = max(0,(((c^theta)*((1-l)^(1-theta)))^(1-tau))/c - expterm(1)+beta*mu(1)*(1-delta));
(i<=0)*(k - (1-delta)*k(-1)) + (i>0)*((((c^theta)*((1-l)^(1-theta)))^(1-tau))/c - expterm(1)+beta*mu(1)*(1-delta)) = 0;
expterm = beta*((((c^theta)*((1-l)^(1-theta)))^(1-tau))/c)*(alpha*((y/k(-1))^(1-psi))+1-delta);
((1-theta)/theta)*(c/(1-l)) - (1-alpha)*(y/l)^(1-psi);
y = A*(alpha*(k(-1)^psi)+(1-alpha)*(l^psi))^(1/psi);
k = y-c+(1-delta)*k(-1);
i = k-(1-delta)*k(-1);
end;
steady_state_model;
a=0;
mu=0;
A=Astar;
// Steady state ratios
Output_per_unit_of_Capital=((1/beta-1+delta)/alpha)^(1/(1-psi));
Consumption_per_unit_of_Capital=Output_per_unit_of_Capital-delta;
Labour_per_unit_of_Capital=(((Output_per_unit_of_Capital/A)^psi-alpha)/(1-alpha))^(1/psi);
Output_per_unit_of_Labour=Output_per_unit_of_Capital/Labour_per_unit_of_Capital;
Consumption_per_unit_of_Labour=Consumption_per_unit_of_Capital/Labour_per_unit_of_Capital;
l=1/(1+Consumption_per_unit_of_Labour/((1-alpha)*theta/(1-theta)*Output_per_unit_of_Labour^(1-psi)));
c=Consumption_per_unit_of_Labour*l;
k=l/Labour_per_unit_of_Capital;
y=Output_per_unit_of_Capital*k;
i=delta*k;
expterm=beta*(c^theta*(1-l)^(1-theta))^(1-tau)/c*(1+alpha*(y/k)^(1-psi)-delta);
end;
shocks;
var epsilon;
periods 10;
values -1;
end;
steady;
options_.maxit_ = 200;
simul(periods=400);
n = 40;
figure(2);
subplot(3,2,1); plot(1:n,A(1:n)); title('A');
subplot(3,2,2); plot(2:n,y(2:n)); title('y');
subplot(3,2,3); plot(2:n,l(2:n)); title('l');
subplot(3,2,4); plot(1:n,k(1:n)); title('k');
subplot(3,2,5); plot(2:n,c(2:n)); title('c');
subplot(3,2,6); plot(2:n, y(2:n)-c(2:n)); title('i');
```
4.5https://git.dynare.org/Dynare/dynare/-/issues/501bytecode still relies on options_.maxit_2019-02-08T08:30:47ZMichelJuillardbytecode still relies on options_.maxit_options_.maxit_ has been removed, but bytecode.cc line 728 still expects it. I'm not sure which new option should be used here.
options_.maxit_ has been removed, but bytecode.cc line 728 still expects it. I'm not sure which new option should be used here.
4.4