# Negative hours worked after temporary shock

Hi,

I took the traditional deterministic neoclassical growth model and extended it by adding a female agent. So now, in the representative household, there is a male and a female supplying hours. I called the time endowment of each agent as `thetam` and `thetaf`. The idea of the exercise is to temporarily reduce the time endowment of females and simulate the model. However, for some values of `thetaf`, the female agent starts to supply negative hours.

How can I constraint the hours to be positive?

Thanks!

simulation2.mod (4.6 KB)

Hi,

I found a way to solve the issue, but I’m not sure if it’s the best one. I was reading the manual and realized that Dynare works with the `max()` function. Therefore, I updated the hour’s equation by adding the maximum between its value and zero. The model is running smoothly. The file is attached.

However, I’m bugged about something. When I calculate the hours FOC and set it to zero, it means that I’m looking for an interior solution, i.e., a solution different from zero. But when using the above approach, the hour’s result during the temporary shock is exactly equal to zero. It seems that there is something theoretical not adding up. That’s why I suspect that should be a better way of solving the issue of negative hours.

Any ideas?

Thanks!

simulation3.mod (4.6 KB)

sometimes you can get negative hours (that is, more leisure) due to the income-substitution trade off between consumption and leisure. Whether labor falls or rise after the shock depends on which effect is stronger…

Sure. I’m using additive log utility:

`u(c, lm, lf) = log(c) + lambdam*sm*log(thetam - lm) + lambdaf*sf*log(thetaf - lf)`,

where `sm` and `sf` are the shares of males and females workers, `lambdam` and `lambdaf` the weights on leisure, and `thetam` and `thetaf` the time endowments. I’m shocking the female time endowment.

But we cannot have negative hours, right? So what is the best way to implement this constraint?

Thanks!

1. Did you get a message that the perfect foresight simulation converged?
2. Usually, the type of Kuhn-Tucker problem with a non-negativity constrained requires setting it up as a mixed complementarity problem (`mcp`-tag)
1. I got the following message with both codes: “Perfect foresight solution found.”

2. Can you point me some references and/or examples on this approach?

Besides:

1. Why don’t people ever use this mixed complementarity approach since hours must never be negative? Shouldn’t it be the standard when modeling hours?

Thanks!

1. See https://github.com/JohannesPfeifer/DSGE_mod/blob/master/Gali_2015/Gali_2015_chapter_5_discretion_ZLB.mod
2. As long as you get an interior solution, there is no point in defining where the corner of the problem is.

Hi,

Thanks for the reference! I studied the `lmmcp` approach and here is what I have so far:

1. I was able to implement it in the model mentioned above. The result is exactly the same as using the `max` operator. However, the code with the `lmmcp` method gets much slower to run. Here are both codes:
simulation_v0_3_maxop.mod (4.6 KB)
simulation_v0_3_lmmcp.mod (4.6 KB)

2. I then upgraded the model by adding on-the-job human capital accumulation for both men and women. I applied the `mcp-tag` to the same equation as the previous version, namely the FOC for female hours. Now, the `lmmcp` method is not able to find a solution. However, using the `max` operator approach provides a solution. Here are both codes:
simulation_v2_3_maxop.mod (8.2 KB)
simulation_v2_3_lmmcp.mod (8.0 KB)

3. A piece of important information, I guess, is that in the version with human capital the hours FOC gets a bit more complicated. Now, it also contains the labor hours for next period (`lf(+1)`).

Should I do anything different due to the fact that now I have `lf(+1)` in the equation? Does anyone have any clue on why it’s not working in the new version with human capital?

Thanks!

From what I can see, you are solving different problems in the two mod-files. The max one implies that the FOC still holds exactly at the corner, which is not true. You can see this by feeding the results as starting values into the LMMCP problem.