Equations in Models

[sbenthall]

This PR is aimed at several interrelated issues, including: #479 #857 and #889

The idea is to make the definition of the mathematical relationships between variables, 'equations' logically separate from the operational code that checks conditions, solves problems, and runs simulations.

Currently, the mathematical aspects of the model are blended in with the operational code. We've been trying to get away from this for some time.

This PR has one solution and a partial demonstration of how it would work. The Model class takes an equations argument, which is a dictionary. The equations are then used as appropriate. I've demonstrated how this refactoring could work for the assignments of thorn and aNrm.

This is just one way to do it. Here are two considerations:

• It wouldn't be too hard to write a formula resolver, so that resolve('thorn') would:
  • look up the equation for thorn
  • know from its arguments that it needs the parameters dictionary as input
  • pass in that dictionary, and
  • get return the value. (Or a dictionary, with thorn assigned to the value).
• Ultimately, we want these equations to be composable and built in such a way that they can be compiled by JAX. Maybe a PyTenson implementation would be more efficient down the line. But it would be harder to refactor the current HARK code to do this without doing the more basic Python version first.

• [x] Tests for new functionality/models or Tests to reproduce the bug-fix in code.
• [ ] Updated documentation of features that add new functionality.
• [x] Update CHANGELOG.md with major/minor changes.