Add calculation of individual steady state as mStE and individual target as mTrg to ConsIndShockModel

[llorracc]

The description of mNrmSS actually corresponded to the definition of what we are now calling the "target" level of individual resources rather than what we are now calling the "individual steady state." We have now added a calculation of the target, called mNrmTrg.

[llorracc]

Am asking @Mv77 Mv77 to check this and let @llorracc know when he has reviewed it as a final check for bugs.

Maybe in the process he will add something to do the ".checkConditions" test for whether the conditions for existence of a target are satisfied before trying to calculate the target.

[Mv77]

Maybe in the process he will add something to do the ".checkConditions" test for whether the conditions for existence of a target are satisfied before trying to calculate the target.

@llorracc This is done in #900. Please check to see if it matches what you wanted me to do. That PR points to the branch in this PR, so that one should be merged first.

I had to re-compute the conditions instead of using the built in checkGIC()-type methods. This is because the checkGIC()-type methods are part of the Agent object, while we do our calculations in the solver object. The solver is a property of the agent, but it has no way of accessing its encompassing agent's properties.

It might be worthwhile to find a way for the solver to know which conditions are satisfied. This seems like a big enough change in architecture that I've just recomputed the relevant factors. I can open an issue describing this inconvenience if you would like.

[Mv77]

The reason tests are failing is that we hard-coded checking the GIC and GIC_nrm into the ConsIndShock model.

The issue is that other models like KinkedRconsumerType inherit this solver. A condition like the GIC is not easy to translate into e.g., the kinked R model, because it has multiple interest rates. So the GIC might be satisfied with some interest rate values and not others. This issue propagates to KinkyPrefConsumerType.

I could just fix it by re-defining a solver for KinkedRconsumerType that does not check the conditions. But I'd like to ask @llorracc whether the conditions have any useful translation to settings with multiple Rfrees ?

[Mv77]

@llorracc whether the conditions have any useful translation to settings with multiple Rfrees ?

He says the right approach in such cases is to check if the GIC holds with the minimum Rfree. Working on a fix implementing this approach now.

[Mv77]

The issue is deeper than I originally thought. It's not only that the GIC is undefined in its usual form. The ConsKinkedRsolver can not re-use the mNrmSS and mNrmTrg from ConsIndShockSolver anyways, because of the multiple Rfrees.

#905 resolves the issue by implementing model-specific addStablePoints functions, which can be overwritten for models that inherit from ConsIndShockSolver.

For now, I have put a placeholder function that does nothing for ConsKinkedRsolver, so no stable points are computed for that model but the ones for ConsIndShockSolver (used in the BST paper, which I checked) are preserved.

This solution allows us to move forward without breaking BST and implement stable points for the kinked model once we define what they are.

[Mv77]

This is very odd.

One test seems to have failed while others passed. Looking at the error output, the issue seems to be related to ConsIndShockModelFast and threading? I find it strange that it passed the tests in all other operating systems and Windows with Python 3.6.

[sbenthall]

Needs CHANGELOG update.

[sbenthall]

Needs automated test.
... reproduce results of BST REMARK.

[Mv77]

Needs automated test.
... reproduce results of BST REMARK.

Done in #923, which is a PR to this PR.

[Mv77]

I noticed the ConsIndShockModelFast versions should probably be edited to add these new features and fixes regarding SS vs Target.

Not sure if that would be a separate issue or if it should be fixed in this PR before merging... dealing with Numba can be like opening Pandora's box sometimes...

[sbenthall]

Still needs CHANGELOG and review from @llorracc

[llorracc]

@sbenthall

OK, just pushed my changes -- seem to be various failures, let's connect tomorrow.

[llorracc]

Fixed a few things, but still failing. Now not immediately obvious to me why.

[sbenthall]

It looks like some of the variable and method names have been inconsistently changed.

For example, one error message is

        if GIC:
>           solution = self.addmNrmStE(solution)  # find steady state m, if it exists
E           AttributeError: 'ConsPrefShockSolver' object has no attribute 'addmNrmStE'

[sbenthall]

Chris, what's the status of this PR? I need to keep working on the release, which means merging #959
You asked me to wait for this PR to be ready before that, but that was Thursday morning.
We are running out of time.