AgentType class attribute AgentCount never initialized

[sbenthall]

Several methods in the class AgentType refer to a class attribute self.AgentCount.

But this attribute is never initialized in the class code, or documented in the API docs.

It is mentioned in some of the other notebooks and examples documentation.
It looks like it plays a role that is not essential to the definition of an agent, but rather is there for convenience for implementing certain simulation methods.

[mnwhite]

It's required to run simulations in all of the subclasses of AgentType, if they use the simulate() framework in AgentType. AgentCount is just a natural number that indicates how many people there are that have *these* parameters for *this* class of problem. You're correct that there's probably no documentation of the simulation structure anywhere.

…

On Fri, Feb 7, 2020 at 9:59 AM Sebastian Benthall ***@***.***> wrote: Several methods in the class AgentType refer to a class attribute self.AgentCount. But this attribute is never initialized in the class code, or documented in the API docs. It is mentioned in some of the other notebooks and examples documentation. It looks like it plays a role that is not essential to the definition of an agent, but rather is there for convenience for implementing certain simulation methods. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#493?email_source=notifications&email_token=ADKRAFJQS5KR4YOGPZONSCTRBVZOBA5CNFSM4KRP3RM2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IL2WRQA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFLV3AEYYGSGANWBH5TRBVZOBANCNFSM4KRP3RMQ> .

[sbenthall]

Is the simulation functionality more or less distinct from the solver functionality?

[llorracc]

Yes. In fact, it might be a good idea to disentangle them a bit; that is, to write some simulation machinery that takes an agent or a set of agents with decision rules as inputs, and simulates them. Specifically, Pablo has some very nice simulation machinery in Dolo. I haven't delved into it much, but it would be useful to have a sense of how much work would be required to simulate a HARK model using the Dolo machinery. If that is reasonably feasible, then my sense is that we should probably move in that direction (that is, of disentangling the solution and the simulation parts of HARK, and adopting Dolo for the latter).

…

On Sat, Feb 8, 2020 at 1:15 AM Sebastian Benthall ***@***.***> wrote: Is the simulation functionality more or less distinct from the solver functionality? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#493?email_source=notifications&email_token=AAKCK76R7LFJAL2AHEUMKA3RBX2QZA5CNFSM4KRP3RM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELFBULI#issuecomment-583670317>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK76RF3QECND4Q7JQV23RBX2QZANCNFSM4KRP3RMQ> .

-- - Chris Carroll

[sbenthall]

Super.

I had a good meeting with Pablo today and a better idea of how Dolo works.
What I learned from him will definitely be helpful in integrating HARK and Dolo.
I hope to have some demonstrations related to that in DARKolo soon.

I see your point about disentangling the simulation from the solution in HARK. I'll make an issue for it.

[sbenthall]

Related to #660