Inequality constraints in deterministic simulation

Dynare help (legacy posts)
1

Helllo everyone,

I am writing about the implementation of inequality constraints in Dynare within a deterministic simulation.
In particular I am referring to an example of irreversible investment (e.g i>=0) I found in some notes from Prof. Villemot here: dynare.org/DynareShanghai201 … nistic.pdf
(see pag. 37)
I attach below the relative Dynare code from Villemot which can be found here: github.com/DynareTeam/dynare/issues/439

There are few questions about it I would like to ask:

  1. I was not able to find any detailed documentation about inequality constraints in Dynare within deterministic simulation. Is there any reference you can suggest me?

  2. In the page where the code is, it is mentioned about a bug when the simulation is implemented with bytecode+block.
    I was wondering if this problem has been fully solved. And, more importantly, if the implementation of inequality constraints in Dynare is well-tested and reliable.

  3. While simulating Villemot code, I realised that it produces an error when replacing the condition on investments (i>=0 and i<0) with a condition on the multiplier associated with its non-negativity constraint (mu==0 and mu>0). From the perspective of the slackness conditions, shouldn’t they be equivalent? I don’t understand then why the second one doesn’t work.

  4. Also, I futher notice that the error at point 3) disappears when changing the solver algorithm (e.g it works with stack_solve_algo=2). In this case the results produced are the same under either (mu==0 and mu>0) or (i>=0 and i<0) .

Thank you very much for your time.
VillemotCode2.mod (2.01 KB)

2
  1. There is no detailed documentation, because inequalities are just one way to write a constraint. You could also use a complementary slackness condition.
  2. You can see that the issue has not been closed and that it is still open. But if you are not using block+bytecode, there should not be an issue.
  3. They should be theoretically equivalent, but the way particular algorithms handle the problem might result in practical differences.
  4. See 3)