vivarium-core
vivarium-core copied to clipboard
vivarium-collective
Core Interface and Engine for Vivarium
Consider the case when there are two processes A and B which by default each update a store X by setting. Currently, the order A and B are added to...
We lack robust support for processes with more than one port to the same store. The multi-update workaround introduced in #28 allows ports that point to multiple leaf stores to...
## Current Approach ### Message Passing When a process has `Process.parallel` set to true, we launch a parallel OS process that runs `vivarium.core.process._run_update()`. `run_update()` contains a loop that repeatedly receives...
In #192 it became clear that it would be nice for us to be able to create v2 releases that break v1 functionality without pushing those releases out to all...
## Status Quo ### Current Approach Currently, processes have a `defaults` class variable that specifies the parameters they expect. Then when calling a process, you can provide parameters in a...
Scattered throughout Vivarium, we have functions to perform operations on schemas, topologies, and hierarchies, e.g. `inverse_topology`. I think the codebase would be easier to understand if we pulled these functions...
Consider a process (e.g. multibody physics) with a ports schema like this: ```python { 'agents': { '*': { 'a': {...}, 'b': {...}, }, }, } ``` Now imagine that we...
Currently, when we emit data that has a unit in the state hierarchy and format it as a timeseries, we put the unit into the key and strip the units...
Currently `Engine.front` tracks all processes next updates, with a dict that has the next update times and the updates that will be applied: `{'time': 14.0, 'update': {update-to-be-applied}}`. The process's next...
* [ ] Verify that the notebook tutorials still work * [ ] Document Composer and MetaComposer better * [ ] Document the available arguments for the Engine constructor *...