Frames in the Market class

[Mv77]

@sbenthall and I were discussing the move towards a 'frame'-oriented architecture (#798) today. He mentioned that something he was thinking about was how to deal with aggregate variables like pLvlAggNow. The issue is that these variables do have transition equations and get updated in well-defined frames, but it is not clear what HARK object that frame should belong to.

I argued that frames updating aggregate variables should belong to some external entity that contains the agents, like the Market class that is currently implemented.

My argument is that I assume it is within HARK's vision to eventually allow users to create ABM-type models in which different AgentTypes can interact (say, construct an economy with both IndShockConsumerTypes and PortfolioConsumerTypes). In such an environment, it would be arbitrary to give either of the agent types the responsibility of updating aggregate variables like total factor productivity or pLvlAggNow. These transitions should, in my opinion, be executed by the object that contains the agents (a Market or Economy).

@sbenthall thought that the argument was persuasive and wanted me to share it with everyone else. Hopefully it can spur useful discussions.

[sbenthall]

Thanks for posting this @Mv77

One idea this points to is how the Economy/Market class will look in cases where Agents are implemented with Frames.
Does the Economy also get frames? (i.e., corresponding to reap, mill, sow, etc.)
How do we determine the order in which frames get resolved?

paging @mnwhite

[Mv77]

A literature that you might want to look into and which I studied in a past life is that of "Discrete-event Simulation".

This is a technique used in operational research to simulate things like production chains. I am sure there are many parts of their architectures that are irrelevant to HARK's purposes. The relevant aspect, which I remember very vaguely, is that there is an external "queue" of events that need to happen. Events are (I think) analogous to what we are calling frames and the queue is external in the sense that it does not belong to any of the objects (agents, markets,...) interacting in the simulation, but is a property of the simulation itself.

I naively imagine some external object with an ordered list of all frames that happen within a period (regardless of the object to which they belong). The list has pointers to the transition function of every frame, and time advances by iterating through the list and calling the transition functions.

[sbenthall]

Ah, thank you, that is very interesting.
I've been looking into agent based models (ABMs) more generally, which are more commonly invoked in the heterogeneous agent modeling (HAM) literature as an alternative to stochastic dynamic programming, which is also a HAM method (the one used currently in HARK and Dolo).

Discrete-event Simulations might be a good intermediary framework or point of reference, especially as the object relations between elements of the economy can be more complex. I like the idea of being able to model a production chain in the same system.

[sbenthall]

In the meeting today, we seem to be agreeing that the Economy/Market classes should also use Frames.

i.e. reap, mill, and sow should be frames.

This ticket can be for this task.

[sbenthall]

Question for @mnwhite : my understanding is that the most important part of the Market class for the solver is the calcDynamics method, which is user-defined and computers the aggregate dynamic rule.

Should this method also potentially depend on equations from the model specification, as has been proposed for AgentType solvers? See #856

[mnwhite]

*Sort of*. But it will be hard to describe by equations per se, as it's often the estimated parameters of a model that uses the previous history as data.

…

On Tue, Dec 8, 2020 at 3:22 PM Sebastian Benthall ***@***.***> wrote: Question for @mnwhite <https://github.com/mnwhite> : my understanding is that the most important part of the Market class for the solver is the calcDynamics method, which is user-defined and computers the aggregate dynamic rule. Should this method also potentially depend on equations from the model specification, as has been proposed for AgentType solvers? See #856 <#856> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#872 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFNR3KDCUJWFCPAFDD3ST2DH5ANCNFSM4TXK4U4A> .

[sbenthall]

Ok. This ticket is for the Frames in the Market simulation.
We'll have to punt on calcDynamics.

[sbenthall]

Revisiting (and claiming) this ticket in light of new Block architecture.

Some notes based on a recent meeting with @mnwhite:

• We already have Blocks which represent some part of the dynamic equations governing the system.
• Currently, they are only used by an 'AgentTypeMonteCarloSimulator', which interprets these to be equations governing a specific agent, isolated from other agents.
• The same DBlocks (and RBlocks) could be used by something else, which interprets them as operating at the aggregate level.
• The main issue is that when an aggregate block follows an agent block, it should see the exposed agent state as vector values, and its equations should be able to compute aggregate statistics (such as the mean).
• To support agent interaction with such a block, the aggregate block outputs (exposed end state) can also be vector valued.
• Implementing this doesn't so much require a change to the block data structure, but rather requires something which creates these interpretations.
• Ergo, a TODO is a MonteCarloSimulator (note, not an agent type) which takes in model configurations (blocks, with appropriate metadata, for example, as to whether or not a block is for an agent), and simulates forward.