===============
                        clot-demo-7.occ
                        ===============


This is a development of the "clot-demo-6" program mailed earlier.

It runs a *lazy* cellular automaton representing the space in which
the clots (or activated platelets) exist.  Clots are implemented
directly as forked processes that flow through the cells, bumping
and coalescing as they go.  Only these clot processes, their generator
and the display process are continually active, barrier synchronising
to keep in step and model time.  Cell processes only become active
transiently, as the forward and backward edges of clots move over them.
Clot processes move by pulling themselves along the server channels held
by the cells.  This implementation relies on occam-pi mobile barriers,
channel-ends and forking (a special case of parallel recursion).

It runs the same user controls and visualisation as "clot-demo-6",
reporting timing using the same measures (cycle times per cell).
It runs around 50 times faster than "clot-demo-6".

Generation of blood clots at the start of the blood vessel is automated.
There is a user-defined probability of clot generation.  Initially,
this probability is zero.  Such automatically generated blood clots
are always of size 1.

Individual blood clots (of sizes 1-9) may also be injected at any time.

The blood vessel is rendered every 'n' cycles, where 'n' is user defined
(between 1 and 65536 in powers of 2).  Initially, rendering takes place
every cycle.  Text rendering takes a significant time.  Reducing the
rendering frequency exposes the true speed of the model.

The whole system may be user-frozen at any time.

The system may be user-terminated at any time.  All processes terminate
cleanly -- there is no "system.exit(0)" cheating!

The display also shows the current cycle count and the average cell
cycle time (in nanoseconds) over the previous 1024 cycles.  These times
include the cost of display rendering.  To factor this out, increase
the cycle interval between frames (see below) to at least 4096.

In "clot-demo-6", cell cycle times depend on the "busyness" of the system.
Very long blood clots are expensive in this version of the system (as its
size is computed each cycle by sending a signal along its whole length).

In "clot-demo-7", cell cycle times depend on the number of clots in the
system (and how often they bump!).  It is independent of the size of the
clots and the number of cells (if we ignore visualisation costs).
However, more cells does imply the possibility of more clots.

The controls are by keyboard character input:

  G - increase the probability of clot generation (by 1/256)
  g - decrease the probability of clot generation (by 1/256)

  D - increase the cycle interval between frames (by doubling)
  d - decrease the cycle interval between frames (by halving)

  1 - inject a clot of size 1
  2 - inject a clot of size 2
  .
  .
  9 - inject a clot of size 9

  F/f - freeze the system (any character resumes)

  Q/q - quit the system


This version of the program has a blood vessel of (60 x 30) 1800 cells.
The screen window needs to be at least 80 across by 40 down for best viewing.

Setting the automatic clot generation probability above around (20/256)
causes a fatal clot build-up to occur ... after a short while.

The generator cell does not allow a backlog of more than 16 clot cells.
So, if a clot builds back to the start of the vessel, reducing the
clot generation probability to below around (4/256) allows the big
clot to break away.

If you freeze the system and then resume it, the timing becomes invalid
for the cell cycle and it is not shown.  Cell cycle times are only
shown for uninterrupted sequences of 512 cycles.


Note: version "clot-demo-6" uses the BARRIER SYNC mechanism introduced
(by Fred Barnes) into KRoC occam version 1.3.4-pre6.  That automates
the registration of processes into BARRIERs (CSP mulitway events), making
it impossible for an unregistered process to SYNChronise on the BARRIER.
Such a mistake was possible with the previous implementation of barriers
as a user-defined type.  The new mechanism is also faster (approximately
18 nanoseconds per SYNC per process, measured on the Dell 3.2 GHz. P4
TUNA nodes).

Note: version "clot-demo-7" uses the MOBILE BARRIERs introduced (by Fred)
into KRoC occam version 1.3.4-pre8.  Mobile barriers are needed to allow
them to be passed to FORKed processes, whose parameters must be passed by
communication.


Note: sorry, these BARRIERs may only be used for committed SYNChronisation.
An extension allowing them to be used as ALT (CSP choice) guards is being
considered.


Compilation:

  kroc clot-demo-7.occ -lcourse


Peter Welch.
(4th. April, 2005)