SAPERE Incarnation Tutorial
An explanation of the basics of the SAPERE Incarnation is available here. A tutorial similar to the base tutorial, with increasingly rich examples, focused on the SAPERE incarnation. Reference descriptions of the SAPERE LSA language inside the simulator are available here
The tutorial can be found on GitHub.
The README.md file of the project explains the use and the steps to follow.
Something went wrong along the line? Drop us an issue report and we’ll get back to you.
LSAs
Syntax details are available in the reference.
The following code creates an irregular grid of devices,
of which those located around the center of such grid contain the tuple { token }:
The relevant part here is molecule: token.
If we wanted to inject the tuple { foo, 1, bar, 2 }, we could have written molecule: foo, 1, bar, 2.
Eco-Laws
Nodes can be programmed with Eco-Laws as follows:
Eco-Laws can be programmed to send LSAs to neighbors, as well as to look into neighboring nodes for getting LSAs.
In order to do so, the LSA template in the Eco-Law must be preceded by a neighbor operator, either + or *.
+ means in a neighbor:
if used on the left hand side,
it considers the condition satisfied if at least one neighbor has at least one LSA matching the provided template;
if used on the right hand side,
sends the LSA to one random neighbor.
* means in all neighbors:
if used on the left hand side,
it considers the condition satisfied if all neighbors have at least one LSA matching the provided template;
if used on the right hand side,
sends a copy of the LSA to all neighbors.
The following code exemplifies a diffusion program:
when { token } is present locally, it is copied into neighboring nodes once per second;
and as soon as two copies of { token } are present, one gets removed.
Rates
The time distribution with which reactions should get scheduled can be controlled by thinkering with the yaml specification
as per every reaction in Alchemist.
If no
TimeDistribution
is specified,
the Eco-Law is assumed to run “as soon as possible” (ASAP).
This may lead to unwanted behaviour.
For instance, programming a single node with:
--> { foo }
will cause the simulation to schedule a reaction producing { foo } at time zero,
and at each execution the time will remain zero:
the simulator will be producing copies over copies of the tuple,
never advancing in time (Alchemist is a discrete event simulator),
and possibly going on until the JVM memory limit is reached.
If a number is specified as time distribution, using the time-distribution key,
then it will be interpreted as the Markovian rate
of an exponentially distributed time.
Other distributions found at
it.unibo.alchemist.model.timedistributions
can be used leveraging the
arbitrary class loading system.
In the following example, two Eco-Laws are configured, and one of them is bound to an
ExponentialTime
with rate 1, namely, when the reaction can be executed
(the left hand LSAs have local matches),
it will execute at an average of once per second
(with a variance of 1 s²).
Exercise
To better grasp details of the incarnation, we recommend looking at the examples available on the Alchemist SAPERE Incarnation tutorial on GitHub.
Besides examples with growing complexity, there are a number of proposed exercises that should help you get acquainted with the SAPERE way of writing self-organizing behaviors.