Refactor checkConditions() code

[sbenthall]

The checkConditions() code is a bit messy.

Here's one reason:
525cb7e#commitcomment-37457605

There is a lot more that could be done to streamline this code.

[sbenthall]

Other checkConditions() related issues to take into account in this refactor:

• AIC condition is not checked on IndShockConsumerType #534
• IndShockConsumerType checkConditions() returns nothing, always #525
• Why doesn't checkConditions() work in ConsPortfolioModel?  #416

[sbenthall]

This issue is also related: #283

[sbenthall]

Based on a chat with @llorracc last week, my understanding is that there are three classes of conditions:

• Conditions that must be met for a model to have non-degenerate solutions
• Conditions that must be met for the model to have a steady state distribution when solved and simulated for an indefinite amount of time
• Conditions that are worth noting but have no direct implications for the functionality of software

In the current code, there is only one method for testing for the violation of these conditions.

But since one set of tests matters for solving the model, and another set of tests matters for simulating it, it follows that these tests should be handled separately and executed at different times.

[llorracc]

Based on a chat with @llorracc last week, my understanding is that there are three classes of conditions:

• Conditions that must be met for a model to have non-degenerate solutions
• Conditions that must be met for the model to have a steady state distribution when solved and simulated for an indefinite amount of time
• Conditions that are worth noting but have no direct implications for the functionality of software

In the current code, there is only one method for testing for the violation of these conditions.

Right; the original code, though messy, did give varying responses attuned to these varying conditions.

But since one set of tests matters for solving the model, and another set of tests matters for simulating it, it follows that these tests should be handled separately and executed at different times.

I don't agree with that. People using these kinds of models are almost always going to want to simulate them, and it would be best for them to be forewarned at the time when they are solving the model if there will be problems simulating it. No point in working hard on calibrating or solving the solution part only to find that it is useless for your purposes when you get to the sim part.

[sbenthall]

did give varying responses attuned to these varying conditions.

Do you mean varying responses in the print statements?
If so, I believe these statements are still there in #568 in its current state.

People using these kinds of models are almost always going to want to simulate them, and it would be best for them to be forewarned at the time when they are solving the model if there will be problems simulating it.

I don't disagree with this.

But is it always a problem if a simulation does not have a steady-state distribution?

I would propose that:

• before running the solver, the user is warned if the result is known to be degenerate.
• before running the simulation, the user is warned if conditions are such that there is no ergodic distribution

Even if you disagree and believe both checks should happen before running the solver, I think the main thing I'm getting at is that the two checks for model properties (nondegeneracy and ergodicity) should be separated in the code so it's possible to call one without the other. A user who knows what they are doing might want to calibrate a model and then test for one property, then the other. A designer of a dashboard might want to prevent a user from selecting values that lead to degeneracy, but not non-ergodicity. They can easily be different functions.

[sbenthall]

Has this been resolved?