Feature Request: Agent DataCollection Can't Handle Different Attributes in ActivationByType

[tpike3]

Describe the Feature
Receive attribute error when running an agent reporter through datacollector when using RandomActivationByType

Desired behavior
I can collect against different attributes based on agent type

To Reproduce
Create a model with different agent types and attributes and try to collect against that agent attribute

Additional context
Feature would need to update at line 170 of datacollection.py agent_records = map(get_reports, model.schedule.agents)

[jackiekazil]

@tpike3 I am unable to recreate the bug -- it looks like sugarscape_cg uses RandomActivationByType. Can you add it to that example & recreate it?

[tpike3]

If you use this colab you will get the error https://github.com/edgeofchaos42/ComplexityExplorer/blob/main/Session_18_Data_Collector_agent.ipynb Attached is the landscape you will need to load into your google drive. or update the sugar_distribution = line

Per the dev session this morning I should be able to add a custom function to filter out non-traders or at least return None, but so far unsuccessful on that code.

sugar-map.txt

[rht]

I think a temporary workaround is to put the trade partners in the model reporter instead.

lambda m: {k: list(a.trade_partners) for k, a in m.schedule.agents_by_type[Trader].items()}

I used list() to copy the a.trade_partners.

[EwoutH]

This is indeed a (in my opinion big) limitation. I wrote a proof of concept implementation for it in #1142, and used it in a personal project. If anyone ones to built on it, feel free to use it in any way!

[rht]

agent_reporters = {Cat: {"Weight": "weight", "Size": "size"}, Dog: {"Weight": "weight"}}

While this looks more concise for RandomActivationByType, it is a pattern that only works for this scheduler. We can't just modify DataCollector to expect more different types of schedulers. DataCollector will become more bloated. And this is not much more concise than the workaround I specified in my earlier comment. The lack of the feature is not a blocker in @tpike3's situation.

Either:

• Create a DataCollectorRABT (shorthand for DataCollectorRandomActivationByType) class that handles types for agent collector
• Tell people to put their type-specific data in the model collector, like in Feature Request: Agent DataCollection Can't Handle Different Attributes in ActivationByType  #1419 (comment). Put the guide in in best-practices.rst

We should look at how other ABM libraries choose their trade-off here.

[EwoutH]

Could we create a new switch for the DataCollector, multiple_agent_types, for example, which is False by default but can be set to True if you want to collect data from multiple agent types? That way it's still contained to a single class, which can reduce the maintenance effort.

[rht]

The maintenance effort is about the same with DataCollectorRandomActivationByType, since it will inherit from DataCollector, and only _record_agents needs to be replaced to handle agents by type. Adding an extra switch and if clause inside DataCollector doesn't scale, because what if there is a scheduler with 2-level type hierarchy (Dict[str, Dict[str, Dict[int, Agent]]], see Multi-level Mesa)? The switch and the if's keep growing.

[EwoutH]

That's a good point.

Would you be interested in creating an (draft) implementation?

[rht]

My plate is rather full right now.

[EwoutH]

Thanks for the honest reply, let's discuss at the next development meeting how we can move this project forward.

[EwoutH]

What if you would restructure the DataCollector in such way that it's split in an agent-data and model-data part?

Maybe a DataCollector superclass with a ModelDataCollector and a AgentDataCollector subclasses? In that case the ModelDataCollector always expects a single model as input, and a AgentDataCollector a single agent type. If you want to collect data for more that one agent type, you simply call the AgentDataCollector multiple times.

Many of the code is now duplicate such as _new_model_reporter and _new_agent_reporter, so why not split those? And everything that's shared can sit in the DataCollector superclass.

[jacob-thrackle]

I'm also running into this issue with respect to the agent attributes. After reading through the code, I wonder if it would be possible to just pass a specific schedule to the DataCollector constructor instead of assuming (hard-coding) that there exists an object in the model called schedule. That would seem to limit the bloat of DataCollector and remove one of the implicit assumptions in the class.

So something like this in the Model:

self.datacollector_my_agents = mesa.DataCollector(
    schedule = self.schedule_my_agents, # arbitrary schedule with an .agents attribute that returns a list of agents
    agent_reporters = {...},
    model_reporters = {...}
)

self.datacollector_your_agents = mesa.DataCollector(
    schedule = self.schedule_your_agents, # arbitrary schedule with an .agents attribute that returns a list of agents
    agent_reporters = {...},
    model_reporters = {...}
)

Then to get the data:

my_agent_data = model.datacollector_my_agents.get_agent_vars_dataframe()
your_agent_data = model.datacollector_your_agents.get_agent_vars_dataframe()

[rht]

Maybe a DataCollector superclass with a ModelDataCollector and a AgentDataCollector subclasses?
...
If you want to collect data for more that one agent type, you simply call the AgentDataCollector multiple times.

This definitely could provide ingredients for people who want to build their own data collector class. But I don't see it to be cleaner than just inheriting from the current DataCollector class and modifying the method you want to change as needed.

I think for now, for trading Sugarscape use case, we should implement the solution within the examples folder. Then wait for a while for it to become a part of the library.