Difference in model solution and actual binding constaint


I have a model with the following constraint.

N_t \geq \chi P_t^bB_t.

N_t refers to the net worth of a bank, P_t^b is the price of the asset that the bank holds, and B_t is the quantity of the asset that the bank holds.

I let \lambda_t be the lagrangian multiplier for the constraint.

I am able to successfully solve the model with Occbin, but I noticed that when \lambda_t>0, which is when the constraint is binding, N_t - \chi P_t^bB_t does not equal 0. It is a relatively small number, but not small enough to always be smaller than the values when the constraint is not binding.

Is this something that happens for all model solutions using Occbin? And is there a way to fix this so that N_t - \chi P_t^bB_t is exactly zero when the constraint binds (or at least something quite small like 10^{-4}?

I think I found the problem, though I do not understand why this is so.

I use log values for the variables, so the constraint is defined as
exp(n_t) \geq \chi exp(p^b_t)exp(b_t)
If I write the constraint in this form, I get that exp(n_t) - \chi exp(p^b_t)exp(b_t) does not equal 0 when the constraint is binding.

However, if I write the constraint in log form as
n_t \geq log(\chi) + p^b_t + b_t
then I get that exp(n_t) - \chi exp(p^b_t)exp(b_t) does equal 0 (not exactly, but almost) when the constraint is binding.

So it seems how I write the constraint matters a lot.

Is this difference in how I write the constraint supposed to matter much?

Dynare solves a first order approximation of the model. So the first specification of the constraint is approximated as well but not the second one

I see. Thank you for the clarification!

The manual states for the occbin_constraints-block:

Second, Dynare will at the current stage not linearly approximate the entered expressions. Because Occbin will work with a linearized model, consistency will
often require the user to enter a linearized constraint. Otherwise, the condition employed for checking constraint violations may differ from the one employed within model simulations based on the piecewise linear model solution.

Ah, thank you for pointing this out from the manual.