Linking to Dolo documentation about the Model for inspiration here:
https://dolo.readthedocs.io/en/latest/model_api.html

Also for reference...

I different way to implement a representation of mathematical equations has already been committed in the frame module. In that work, the equations (called Frame in that code, but really I should rename that to Equation or remove frames entirely in favor of whatever system replaces is) are objects that include a target value, the arguments to its equation, the equation itself (as a Python function), and/or a flag to say if the target value is a control variable (needing a decision rule to be fully specified):

https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsPortfolioFrameModel.py#L114-L231

The equations get evaluated in simulation in the scope of the current state/shock/parameter values:

https://github.com/econ-ark/HARK/blob/master/HARK/frame.py#L591-L670

At the time I wrote that, I had no idea how to integrate equations like these into the solver. #1283 provides a way to do that.

But also, there are pros and cons to the implementation in frame.py and the version currently in this PR is an alternative.

The failing tests in the ConsAggShockModels are due to the fact that the AggShockModel constructor does not call the constructor of its superclass (IndShockConsumerType), but rather the AgentType base class constructor.

https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsAggShockModel.py#L135-L156

This is not how other model inheritance in HARK works, where the superclass is called.

Is this intentional? Or just an oversight in how the ConsAggShockModel works? if the latter, I can easily fix it in this PR.

Let's try changing the inheritance and see if it runs properly.

Ok, I changed it locally and it got tests passing. This change has been committed to this PR.

Codecov Report

Patch coverage: 96.72% and project coverage change: +0.06 🎉

Comparison is base (2209109) 72.55% compared to head (97a1740) 72.61%.

@@            Coverage Diff             @@
##           master    #1292      +/-   ##
==========================================
+ Coverage   72.55%   72.61%   +0.06%     
==========================================
  Files          78       80       +2     
  Lines       13009    13038      +29     
==========================================
+ Hits         9439     9468      +29     
  Misses       3570     3570              

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Tests are now passing. KinkedR had a similar issue with inheritance.

The substance of this PR is now in and ready for review. Requesting review from @mnwhite

I know I need to do tests, docs, and changelog, and will start on that next.

Not sure why this just popped up in my inbox, but it prompted me to look again.

I think thinking about all this is premature. It will really need to be integrated with whatever structure gets created from Pablo's architecture. At most, at this point we could perhaps fruitfully build on what is already in dolo or nolib.

It's unfortunate that you've been missing the regular HARK meetings @llorracc I think we're quite resolved that this is a good idea.

Essentially, no matter what Pablo's architecture is, the HARK models will need to be moved in this sort of direction in order to integrate with that. This is a necessary incremental improvement to HARK no matter what.

I'd like to revisit this PR, which is now almost a year old, and perhaps out of date with respect to recent HARK changes. But it was trying to accomplish something that we are still trying to move towards.

The main point of this PR was to try attaching dynamics to the existing ConsumptionSaving models, so that they could be rewritten with a single source of truth about their model equations.

These dynamics, in this PR, looked like this:

IndShockConsumerType_dynamics = {
    **PerfForesightConsumerType_dynamics,
    'G' : lambda gamma, psi : gamma * psi,
    'Rnrm' : lambda R, G : R / G,
    'bNrm' : lambda Rnrm, aNrm : Rnrm * aNrm,
    'mNrm' : lambda bNrm, theta : bNrm + theta,
    'cNrm' : Control(['mNrm']),
    'aNrm' : lambda mNrm, cNrm : mNrm - cNrm
}

This is now essentially the same thing as what's included in the 'block' based consumption model, which was recently merged in:

https://github.com/econ-ark/HARK/blob/master/HARK/models/consumer.py#L26-L44

Now that there's a compact format for model equations already in HARK, it would be a good idea to implement a solution to #1346 and put the equations onto the old models.