tierra.doc

地球模拟器

     This documentation was written by Tom Uffner.

Arg(1)                   USER COMMANDS                     Arg(1)

NAME
     arg - genbank archive utility

SYNOPSIS
     arg c|r[v12...9] afile size file1 [file2...]
     arg x|t[v12...9] afile [gen1 [gen2...]]

DESCRIPTION
     The arg utility is used to manipulate the genebank  archives
     that  are used by tierra(1).  It is used to assemble or dis-
     sasemble tierra code, list the genomes contained in a  file,
     and also to convert between the old and new file formats.

     The arg commands are:

          c - create afile and add genomes in file1...filen

          r - replace  in  afile  (or  add  to  end)  genomes  in
               file1...filen

          x - extract entire contents or specified  genomes  from
               afile

          t - list entire contents or specified genomes in afile

     The optional modifiers are:

          v - verbose output

          1,2...9 - instruction set (defaults to Format: parameter
				     of ascii source or to INST = 1)

     Where filen and afile are any legal filenames, genn is  a  3
     character genome label, and size is a decimal integer. (Note
     that tierra(1) expects archives to have names consisting  of
     4 digits, and an extension of .gen, or .tmp.

FILES
     GenebankPath/nnnn.gen permanantly saved genomes
     GenebankPath/nnnn.tmp genomes from periodic saves

SEE ALSO
     An Approach to the Synthesis of Life
     tierra(1), ov(1X), beagle(1DOS), genio(3), arg(5)

BUGS
     Genome extraction and internal  search  functions  could  be
     faster, and will be in the next release.

Tierra, V 4.0      Last change: 8 September 1992                  2

Please remember that this new form of arg needs the file opcode.map
to be in the current working directory.  Arg ALWAYS reads the file
opcode.map for the mappings for assembling/disassembling genebank
archives.

  5.3) The Birth-Death Output

     During a run, if the DiskOut parameter is non-zero, a record of births
and deaths will be written to disk in the path specified by OutPath, to
files whose names depend on the BrkupSiz parameter.  The format of this
file is a bit cryptic, so it will be explained here.  The file has either
three or four columns of output, depending on whether the GeneBnker parameter
is set.  Three of the columns remain the same either way: 1) elapsed time
since last birth or death event in instructions, output in hexidecimal format.
2) a `b' or a `d' depending on whether this is a birth or a death.  3) the size
of the creature in instructions, output in decimal format.  If the genebanker
is on, then there will be a fourth column containg the three letter code
identifying the genotype of the creature.  Mutations appear in the
birth-death record as the death of one genotype followed by the birth of
another, with an elapsed time of zero between the two events.

     What makes the file cryptic, and also compact, is that columns are
implied to be identical in successive records unless otherwise indicated.
Only the first column, elapsed time since last record, must be printed on
every line, and only the first record must have all three or four columns.
Therefore, if there is a series of successive births, only the first birth
record in the series will contain the b.  Notice that at the beginning of
the file, there will generally be many lines with just one column, because
at the outset, all records are of births of the same size and genotype.

     The record of births and deaths is read by the Beagle program, and
converted into a variety of graphic displays: frequency distributions over
time, phase diagrams of the interactions between pairs of sizes or genotypes,
or diversity and related measures over time.  The source code for reading and
interpreting the record of births and deaths is in the bread.c module of the
Beagle source code.

  5.4) The Genebank Output

     If the GeneBnker parameter is set to a non-zero value, then as each
creature is born, its genome will be sequenced and compared to that of its
mother.  If they are identical, the daughter will be assigned the same name
as the mother.  If they are different, the genome of the daughter will be
compared to the same size genomes held in the RAM genebank.  If the daughter
genome is found in the bank, it will be given the same name as the matching
genome in the bank.  If the daughter genome is not found in the RAM genebank,
it will be compared to any same size genomes stored on the disk that are not
in the RAM genebank.  If the daughter genome is found in the disk genebank,
it will be given the same name as the matching genome in the disk genebank,
and that genome will be brougt back into RAM from the disk.  If the
daughter genome does not match the mother or any genome in either the RAM
or disk banks, then it will be assigned an arbitrary but unique three letter
code for identification.

     The genebanker keeps track of the frequency of each size class and each
genotype in the soup.  If a genotype exceeds one of the two genotype frequency
thresholds, SavThrMem or SavThrPop, its assigned name will be made permanent,
and it will be saved to disk in a .gen file.  Genotypes are grouped into
individual files on the basis of size.  For example, all permanent genotypes
of size 80 will be stored together in binary form in a file called 0080.gen.

     When the simulator comes down, or when the state of the simulator is
saved periodically during a run, all genotypes present in the soup which have
not been assigned permanent names will be stored in files with a .tmp
extension.  For example, all temporary genotype names of size 45 would be
stored in binary form in a file called 0045.tmp.

     The parameter RamBankSiz places a limit on how many genotypes will be
stored in RAM.  If there are more than RamBankSiz genotypes in the RAM bank,
if any of them have permanent genotype names but have gone extinct in the
soup, they will be swapped out to disk into a .gen file.  Genotypes without
permanent names are deleted when they go extinct.  If the number
of living genotypes in the soup is greater than RamBankSiz, then the value
of RamBankSiz is essentially ignored (actually it is treated as if the
value were equal to the number of living genotypes).  Living genotypes are
never swapped out to disk, only extinct ones.  Under DOS, the parameter
RamBankSiz is of little importance, because it is raised if there are more
living genotypes and if the simulator uses all 640K of RAM, RamBankSiz is
lowered so that genotypes will be swapped out to avoid running out of
memory.  Under Unix, this parameter does determine how many genotypes
will be held in the rambank, as long as there are not more than RamBankSiz
living genotypes.

     The binary genebank files can be examined with the assembler-disassembler
arg (see the relevant documentation, section 5.2 above).  Also, the Beagle
Explorer program contains utilities for examing the structure of genomes.
One tool condenses the code by pulling out all instructions using templates,
which can reveal the pattern of control flow of the algorithm.  Another
function allows one genome to be used as a probe of another, to compare
the similarities and differences between genomes, or to look for the presence
of a certain sequence in a genome.  A completely separate tool called probe
will scan the genebank pulling out any genomes that meet a variety of
criteria that the user may define.

  5.5) Restarting an Old Run

     When you start Tierra by typing tierra to the prompt, you may provide
an optional command line argument, which is the name of the file to use as
input.  This is the file that contains the startup parameters.  The default
file name is soup_in.  When a simulator comes down, and periodically during
a run, the complete state of the machine is saved so that the simulator can
start up again where it left off.  In order to do this you must have the
simulator read the file soup_out on startup.  This means that you must type:

tierra soup_out

     That is all there is to it.

  5.6) The User Interface

     There are two interfaces available for Tierra.  The source code and
executables are shipped in a form that is configured for the nicer of the
two, the Basic interface.  However, if you make the appropriate modifications
to the configur.h file, you can recompile with the Standard Output interface
(useful for running Tierra in the background).  Documentation for each of
these interfaces follows.

    5.6.1) The Basic Interface

      5.6.1.1) The Basic Screen

     The Basic frontend features a dynamic interface to the simulation.
The screen area is divided into five basic areas:

The STATS area consists of the top two lines of the screen.  This area
displays several important variables, whose values are updated after every
birth:

> InstExec  = 75,529993  Cells =  387  Genotypes =  191  Sizes =  23
> Extracted = 0080aad @ 8

InstExec  = 75,529993 tells us that the simulation has executed a total of
75,529,993 instructions.  Cells =  387 tells us that there are presently
387 adult cells living in the soup.  Genotypes =  191 tells us that there
are presently 191 distinct genotypes of adult cells living in the soup.
Sizes =  23 tells us that there are presently 23 distinct sizes of adult
cells living in the soup.  Extracted =  0080aad @ 8 tells us that the last
genotype to cross one of the frequency thresholds (SavThrMem or SavThrPop)
and get saved to disk and get a permanent name was a creature of size 80
with the name aad, which had a population of 8 adult cells when it crossed
the threshold.

The PLAN area displays the values of several variables, whose values are
updated every million instructions:

> InstExeC      =     75  Generations  =    188  Thu Apr 30 11:49:46 1992
>     NumCells  =    356  NumGenotypes =    178  NumSizes  =     21
>     AvgSize   =     76  NumGenDG     =    171  NumGenRQ  =    239
>     AvgPop    =    376  Births       =   1007  Deaths    =   1034
>     RateMut   =  10966  RateMovMut   =   1216  RateFlaw  =  97280
>     MaxGenPop =     21  (0078aak)    MaxGenMem =     21 (0078aak)

InstExeC = 75 tells us that this set of variables was written when
the simulation had executed 75 million instructions.  Generations = 188
tells us that the simulation had run for about 188 generations at this time.
Thu Apr 30 11:49:46 1992 tells us the actual time and date that this data
was printed.

NumCells = 356 tells us that there were 356 adult cells living in the soup.
NumGenotypes = 178 tells us that there were 178 distinct genotypes of adult
cells living in the soup.  NumSizes = 21 tells us that there were 21 distinct
sizes of adult cells living in the soup.

AvgSize = 76 tells us that during the last million instructions, the
average size was 76.  NumGenDG = 171 tells us that there are 171 genotypes
that have received permanent names and been saved to disk as .gen files in
the genebank directory gb.  NumGenRQ = 239 tells us that at this time there
were 239 distinct genotypes being held in the genebank in RAM (the ramqueue).

AvgPop = 376 tells us that during the last million instructions, the
population was 376 adult cells.  Births = 1007 tells us that during the last
million instructions, there were 1007 births.  Deaths = 1034 tells us that
during the last million instructions, there were 1034 deaths.

     RateMut = 10966 tells us that the actual average background (cosmic ray)
mutation rate for the upcoming million instructions will be one mutation per
10966/2 instructions exectued.  RateMovMut = 1216 tells us that the actual
average move mutation rate (copy error) for the upcoming million instructions
will be one mutation for every 1216/2 instructions copied.  RateFlaw = 97280
tells us that the actual average flaw rate for the upcoming million
instructions will be one flaw for every 97280/2 instructions exectued.  The
reason that these numbers represent twice the average mutation rates is that
they are used to set the range of a uniform random variate determining the
interval between mutations.

     MaxGenPop = 21 (0078aak) tells us that at this time, the genotype
with the largest population is 0078aak, and that it has a population of 21
adult cells.  MaxGenMem = 21 (0078aak) tells us that the genotype whose
adult cells occupy the largest share of space in the soup is 0078aak, and
that it has a population of 21 adult cells.

The MESSAGE area, for state changes, and Genebank data.  This area serves
many purposes - memory reallocation messages, Genebank information displays,
large interface prompts (eg changing a soup_in variable ).

The ERROR area at the second to the last line of the screen.
All simulation errors and exit conditions are passed through this area.

The HELP area at the last line of the screen.  This area provides
suggestions for keystroke navigation.  Under DOS it will usually look
like this:

>                  Press any Key for menu ...

Under Unix it will generally look like this:

>                  Press Interupt Key for menu ...

Under DOS, pressing any key will get you the menu, under Unix, pressing the
interrupt key (usually Ctrl C) will get you the menu, described in the
next section.

      5.6.1.2) The Menu Options

     Please note that if the Tierra simulator is started with two arguments,
it will come up with the menu system activated.  The first argument must be
the name of the soup_in file, the second argument is a dummy and anything will
do:  tierra soup_in1 junk

The frontend menu looks like this:

> TIERRA |  i-info  v-var  s-save  q-save&quit  Q-quit  m-misc c-continue |->

      These options allow for rapid IO from the simulation, in a user friendly
format.  The interface allows transition between any data display mode.  The
features are ativated by a single keypress ("Enter/Return" is usually not
needed).

The options are: 

            i-info  v-var  s-save  q-save&quit  Q-quit  m-misc c-continue |->

i-info: will display some information about creatures stored in the Genebank.
     See below for details.

v-var: allows you to alter the value of any of the variables in the
     soup_in file at any point during a run.