min () in deterministic simulation

[mricci]

Dear all,

I am currently simulating a deterministic model with capital variable capacity utilization.
By economic theory capacity utilization is suppose to be bounded between 0 and 1; however, in my model simulation it happens that in some periods capacity utilization exceeds 1.
This result looks consistent with the related literature suggesting that the inequality constraint on capacity utilization (e.g to be less or equal than 1) is occasionally binding in this class of models.

I am trying to deal with it employing a min() operator.
In particular, I have replaced everywhere in my model capacity utilization ‘m’ with ‘min(1,m)’ .
All the sanity checks performed by Dynare seem to indicate that such a formulation of the model is fine.
However, when running the simulation under alternative solvers and options (e.g with or without bytecode and block, default cutoff or cutoff=0, increasing maxit ect.), dynare typically crashes.

Interestingly, if I slightly modify the ‘min’ condition into e.g. min(1.008,m), where 1.008 has been chosen so as min function always returns ‘m’ (e.g the constraint never binds), the simulation works and returns me the same results of the unrestricted model.

I am wondering at this point if this is a problem with Dynare rather than with my model.

I attach below the .mod file together with the two matlab solvers called by Dynare for solving for initial and terminal conditions.

[jpfeifer]

You need to look into this a bit more. I tried it with min(1.001,m) without (bytecode, block, cutoff=0) and with

Code: Select all

simul(periods=200, maxit=2000);


on the unstable version. There, convergence was obtained after quite some time. Convergence is easier, the bigger the upper bound is. A robust feature across all trials is that m increases slightly from the beginning. However, I don't know whether that actually is a prerequisite for the existence of a solution or just gives the algorithms a hard time.

What do you mean when you say

dynare typically crashes

It does not find a solution and then provides an error message? Or it really crashes during the computations like in a bug? If the latter, please provide more information on when exactly this happens.

[mricci]

Dear Professor Pfeifer,

Thank you very much for your answer and for your time.

I have repeated the experiment you did (e.g using the settings you suggested) employing the stable version of Dynare (e.g 4.4.3).
I can confirm that, with this version of Dynare, no convergence is obtained unless the ‘upper bound on m is not binding’
(e.g min(1.001,m) and min(1.004,m) don’t work, but min(1.01,m) does)
I guess, at this point, that deterministic simulation has been somehow modified in the new version.


You said

A robust feature across all trials is that m increases slightly from the beginning. However, I don't know whether that actually is a prerequisite for the existence of a solution...

But, if the ability of ‘m’ to increase initially is a condition for a solution to exist, then shouldn’t it be reflected in the violations of the Blanchard-Kuhn conditions in the model with min(1,m) ?

Finally, to reply to your question, what I mean with crash is the error message I report below which occurs, on the stable version, in the model with min(1,m) under algorithms 0,1,4,5 (with the option bytecode and block activated)

Code: Select all

Error using mexErrCheck (line 41)
Error encountered in: bytecode.
Error in simul (line 106)
        mexErrCheck('bytecode', info);
Error in PrimalRamsey_mMin (line 428)
simul();
Error in dynare (line 180)
evalin('base',fname) ;

[jpfeifer]

The crash you report seems to be due to a bug in bytecode. It has been fixed in the unstable version. There, I get the model to run with

Code: Select all

min(1.00001,m)

but not with

Code: Select all

min(1,m)

which is strange. Maybe you can get some intuition what is going on by looking at the changes in IRFs when you make the upper bound tighter.

[mricci]

Dear Professor Pfeifer,

Thank you very much for your time and willingness.