Nanoverse v1.0.0-a11: New filters, Scale process

@borenstein borenstein released this Mar 2, 2016 · 2 commits to master since this release

Major changes:

  • Not filter negates other filters
  • HasNeighbors filter
  • Scale continuum process

Not filter

David Bruce Borenstein

Existing filters can now be negated using the Not filter. The Not filter takes as its child another filter, which may be a composite filter. The Not filter returns whichever sites were filtered by the other filter. Note that ActiveSites restrictions are applied before filters. As a result, if you restrict ActiveSites to a region A and then specify any filter (including a Not filter), all of your results will still be inside of region A.

HasNeighbors filter

David Bruce Borenstein

The HasNeighbors filter includes any sites that have non-vacant neighbors, and removes all that do not.

Scale continuum process

The Scale continuum process scales a continuum layer by some fixed amount. Formally, it is equivalent to multiplying the layer's state vector by a scalar coefficient.

Nanoverse v1.0.0-a10: Simplified continuum process specification

@borenstein borenstein released this Dec 17, 2015 · 6 commits to master since this release

Major changes:

  • Agent relationships now handled through ApplyRelationships process
  • CompositeContinuumProcess container

Minor changes

No minor changes.

Overview

Prior to this version, continuum processes were specified in between two meta-processes: Hold and Release. Every continuum process scheduled in between these two processes would be superposed, and they would be executed all at once. Additionally, if the agents had any effect on the continuum layer (exponential growth/decay, constant value increase/decrease), those relationships were resolved at the time of Release.

This approach proved to have two major limitations: first, it was impossible to schedule continuum processes to resolve, say, once every 20 cycles, or with some stochastic waiting time. Second, it was totally opaque to users. To this end, Nanoverse v1.0.0-a10 has two major changes to continuum processes.

Agent Relationships now handled through ApplyRelationships process

Agent relationships are no longer automatically resolved at any time. Instead, agent relationships are resolved by triggering an ApplyRelationships process. As with all continuum processes, you must specify which layer you want to be affected by the ApplyRelationships process. See the aerobe.nano and continuum.nano samples for example usage.

CompositeContinuumProcess container

In addition to Hold and Release, Nanoverse users can now apply several continuum processes at once through the CompositeContinuumProcess container. The container takes standard process arguments (period, start, etc.). When triggered, it causes each of the continuum processes in the children argument to be superposed and then resolved all at once. An example can be found in the aerobe.nano sample.

Nanoverse v1.0.0-a9: the "Make" action

@borenstein borenstein released this Dec 11, 2015 · 18 commits to master since this release

Major changes:

  • Make action lets agents create non-self-similar agents

Minor changes

  • Compiler errors report line numbers
  • Improvements to dictionary generator

Make process

David Bruce Borenstein

Behaviors can now include the Make action. Make is identical to Expand, except that rather than creating a copy of the Expanding agent, it creates a different, user-defined agent. The agent to be created is defined in the description argument. The new biofilm.nano example illustrates its use.

Nanoverse v1.0.0-a8: custom color palettes

@borenstein borenstein released this Nov 25, 2015 · 37 commits to master since this release

Major changes:

  • Custom color palettes

Custom color palettes

Users can now associate agent class names with a particular color. For example, in a Lotka-Volterra model, "predators" could be red and "prey" could be blue. For an example of how this is used, see hdr.nano in the samples directory, which maps "Hawks" to red, "Doves" to blue and "Retaliators" to yellow.

Nanoverse v1.0.0-a7: Real-world applications

@borenstein borenstein released this Nov 19, 2015 · 52 commits to master since this release

Major changes

  • Added examples demonstrating the use of Nanoverse for research applications.
  • Support for composite actions in behaviors and stochastic choices.

Minor changes

  • Changed internal logic for handling lattice goemetries.
  • Fixed bugs related to switch from "maximum" target argument to a filter-based approach.

New examples

David Bruce Borenstein

Provided real-life examples of Nanoverse being used for research. Included so far are aerobe.nano, hdr.nano and t6ss_ava.nano.

The first, aerobe.nano couples an agent's growth to the local value of a scalar field. The agent depletes this scalar field, resulting in high field values only far away from the bulk of the agent domain. This leads to fingering instabilities.

hdr.nano is a spatial version of the Hawk-Dove-Retaliator game, based on work by J. Maynard Smith and George Price. All three agent types have a fixed potential to replace neighbors, with the Hawks and Retaliators triggering additional turnover under specific circumstances. Given the correct parameters, the system appears to exhibit 3-way coexistence with dramatic fluctuations between them.

The third simulation, t6ss_ava.nano, is based on a work from the Nanoverse development group (Borenstein, et al. 2015) that explores the evolutionary significance of the Type VI secretion (T6S) system. The simulation represents a competition between two T6S+ species during a range expansion from a well-mixed state.

Composite actions

David Bruce Borenstein

It is now possible to define behaviors that contain multiple actions to be performed in sequence. Likewise, it is now possible to define composite options in stochastic choices.

Nanoverse v1.0.0-a6: Normalized stochastic choices

@borenstein borenstein released this Nov 7, 2015 · 69 commits to master since this release

Major changes

  • Normalized stochastic choice

Minor changes

Fixed bug were empty spaces were assigned a color when using indexed color, resulting in a pink background.

Normalized stochastic choice

If you set normalized: true in a stochastic choice, then it will create a null option with probability 1 - (total probability of other events). If probability of other events exceeds 1 while using normalized mode, an error will be thrown.

Nanoverse v1.0.0-a5: Bug fix

@borenstein borenstein released this Nov 6, 2015 · 75 commits to master since this release

Major changes

No major changes.

Minor changes

Fixed bug resulting in an exception when using the Null action. (Believe it or not, it was a NullPointerException that had nothing to do with the fact that this is a "Null" action!)

Nanoverse v1.0.0-a4: agent class names

@borenstein borenstein released this Nov 2, 2015 · 79 commits to master since this release

Major changes

  • Agent classes now have names instead of numeric type identifiers
  • Major internal changes

Minor changes

  • AgentClass filter renamed to Name
  • Agent type/class parameter removed
  • Agent health/fitness parameter removed
  • Agent divisible flag removed
  • Divide process removed
  • maximum argument removed from TargetRule.
  • New filter Sample now can be used in place of maximum in TargetRule and maxTargets in Process.
  • Removed legacy OccupiedNeighborSwap and GeneralNeighborSwap processes (same can be accomplished by using the Swap action with a filter)

Temporarily disabled

  • Cull process removed temporarily.
  • Temporarily disabled SurfaceCensusWriter and InterfaceCensusWriter.

Nanoverse v1.0.0-a3: Neighborhood probability

@borenstein borenstein released this Oct 14, 2015 · 114 commits to master since this release

Nanoverse v1.0.0-a3

Major changes

  • Neighborhood probability

Minor changes

  • Minor bug fixes
  • Dependent weight renamed to Continuum

Neighborhood probability

David Bruce Borenstein

When creating a StochasticChoice action, you can now specify an option weighted by Neighborhood. The Neighborhood weight increases by coefficient (from offset) for each occupied neighbor.

In an upcoming release, all of these ad-hoc ways to specify weight will be replaced by a unified, algebraic syntax.