rht

I think being able to pass in a DataFrame as params to `batch_run` is a useful feature.

> I have the same type of issue, a str passed as a parameter to batch_run is then interpreted character by character, not ideal! I actually don't fully understand this...

``` [{'key': 'v'}, {'key': 'a'}, {'key': 'l'}, {'key': 'u'}, {'key': 'e'}] ``` This is definitely a gotcha, but this is something that can be quickly fixed (into Mesa main branch).

With #1289 (just merged), the output will be `[{'key': 'value'}]` instead of `[{'key': 'v'}, {'key': 'a'}, {'key': 'l'}, {'key': 'u'}, {'key': 'e'}]`. However, since the DataFrame as an input is...

I'd prioritize implementing #1263 over this issue, but you are welcome to help to implement the DF input.

- `self.agent_name_index` is redundant with `self.agent_reporters`. - I find the extra `agent_attr_index` construct to be unnecessary. You can define aggregate measure of agent variables within the framework of the existing...

I wasn't referring to `_agent_records`. i was referring to storing the values in `model_vars`. The aggregated agent metric is a *model-wide* measure, a summary of individual agent properties.

Any aggregate metric, by definition, is a model-level variable. The examples you showed in https://github.com/projectmesa/mesa/pull/1145#issue-1111995305 can be put `model_vars`. Avoiding data collection key name collision is a separate problem. If...

No data are thrown away. See my example. I took the agent-level vars from an existing, separately-defined agent reporter.

> (Unless something like this can already be accomplished, in which case it should maybe be documented?) For now, if your simulation isn't multithreaded, you can just use `random.seed` and...