Mutable / simulation-owned communication specialisation properties

[ptheywood]

Specialised communication patterns currently have properties which are fixed for a given model at simulation (/ensemble) construction time, such as the number of buckets, the min/max bounds and communcation radii for spatial communication.

This has 2 downsides:

1. Independent simulations within an ensemble must all use the same communication bounds / bucket counts
   • Harming performance for some models within an ensemble which use not fit for purpose comm radii
2. The communcation bounds must be the same for the lifetime of the simulation.
   • For simulations which may grow over time this may be sub optimial for performance (initially, or if the communicaiton bounds are set too low)

Ensembles

Ensembles are a practical solution for optimising device utilsiaton when many simulations are required, with different parameters.

I.e. boids wiht different environment scales or communciation radii.

The current workaround is for the communication bounds / radii to be defined as the largest required by the ensemble. Individual simulations which use smaller communication radii must iterate all the messages in the larger bin, and the agent functions must include a a distance check to ensure only the relevant messages for that simulation are required.

This will have a significant performance impact where the change in radii is sigcant.

Bounds over simualtion lifetime

The construction PBOs or similar messaging data structures once messages have been output can be expensive for large numbers of bins, which is wasted effort / time if a lot of the space is currently empty.

For instrance, a cell simulation where iniitally only a small portion of the total potential volume is occupuied a significant number of bins will be empty, leading to expensive scans / iteration of empty bins.

If the number of bins were to change over the duration of the simulation, would improve performance.

Feature Request(s)

• Properties such as bounds / bin size of a communcation pattern should be owned by the individual simulation rather than the model, to support/optimise different communication radii within different simulations within an ensemble.
  • This will require an API, change, so this can set per simulation within an ensemble.
• Properties such as bounds / bin size of a communcation specialisation should be owned by the individual simualtion, and mutable during the lifetime of the simulation (either explicitly in host functions or automatically as required, if opted into).
  • The initial value would be provided during model definiiton
  • The host api would expose methods to set these properties. If the new properites are differnent, new data structures are allocatied, and used going forwards.
    • Potentially, existing data would be mapped into the new data structure based on the position in the new coordinates, but this might have other currently unforseen issues

---

edit

This may also require adding the ability to query the message properties at runtime (i.e. get the bounds / radius).

If changing shape is allowed during model execution, this would either need clearly documenting that the current message data is purged, otherwise pbm reconstruction would be requried (for spatial) which is not free.

[Robadob]

Jack A was trying to do something which required this.

[ptheywood]

The fixed upper limit on BucketMessage at model definiation time is not ideal for an internaction-network based model currently being worked on, especaially if ensembles are to be used.

• The number of buckets is not known till population generation time (ideally in an INIT func for ensembles)
• The number of buckets may change throughout the simulation.

This could be resolved by having a method in the host API object (init, step, host layer) which allows changing the number of buckets, without breaking the existing API by using the model-definition time value as the default. If the new number of bins is larger then the old one, existing message data could be retained (by alloc, copy, free), but if the number of bins are shrunk then some bins may no longer be accessible, so care would be needed.

Having this be accessible on teh simulation object itself prior to simulate() would also be useful for non-esembles.