Re: Parameter Managers and all that...

[Ginger Booth]

-- long warning --

Chris,
    Thanks for the invite to get going on this topic.  

>   So - all those who were/are interested in the topic, can we start
> out by having you post a recap of your views/work on parameter
> management in Swarm (or simulation in general)? 

    Recap:  I believe parameters are a fundamental object in Swarm-based
simulations, and need to be elevated in stature as such.  All agent-based
models (abms--I can't deal with the ibm acronym ;) have parameters.  They
belong to the -simulation-, not classes within the simulation.  They form 
the backbone of the protocol of an experiment.  They are thus archive 
objects--to be input from a single file, written as de rigeur output of every 
simulation, along with date/time and random number seed to reproduce the 
results. 

    Parameters are apply-able.  Each parameter has a routine for 
applying it to the simulation correctly.  If set via a probe, the probe has
to call the proper apply routine.  Parameters have int, double, string, etc.
values as a base, but need to be subclassable for more complex types.  
An -apply routine might have multiple arguments.  A parameter thus has a
type, an apply message hook, and an owner.  (Who to call -apply on.)  Plus
sundry behaviors, name, etc. fiddly bits.  You can count on the need to
subclass Parameters.

    Each simulation has a parameter -list-.  A parameter list can be 
algorithmically manipulated and -apply'd to spawn further simulations.
In practice, lists are put together out of lists.  (Each simulation has 
global control parameters, display parameters, and a list of proto-agents, 
each of which has at least one list of parameters.)

    Parameters don't have unique names, unfortunately.  A fully-qualified
naming scheme is needed for the protocol i/o.

    In addition to the mandatory file i/o on parameter lists, it would of
course be nice to have an auto-generated popup menu for any parameter list.
    
    
>   Those of you who have implemented parameter managers of one sort
> or another, could you summarize your approach and your implementation?

    I wouldn't recommend my implementation.  But for what it's worth....
    
    Classes:
        Param - name, owner, message ([Param apply] => [owner message: value]), 
                absolute value (int, double, string, label)
        OffsetParam - full value is offset value + someone else's value
            Parameterized - something with list of Params/OffsetParams
                ControlParams
                ModelParams
                Site    - sample member "grandma" + parameters 
                Species - sample member "grandma" + parameters 
                ESCombo - list of multi-class parameters for algorithmic 
                          manipulation
                ESTable - ESCombos for current round of evaluation process
                
I did as little as I could get away with to accomplish what I needed, 
did it in the wrong order, and it's not implemented high enough up, logically.
Anyway, a sketch of how this works:

I have a protocol for specifying an experiment.  Here's a simple one:
        
        @begin RunControl
                StatCycle       1       
                ButtonTimeStep  1       
                Display         1
                Runs            1       
                ESRun           0       
                OutputStem      bacteria
        @end RunControl
        
        @begin World
        # RNG seed belongs here, haven't done that yet.
                StopDay         10000   
                ReQuad          10      
        @end World
        
        @begin Site OnlySite
                Type            FeedQuad
                Color           17      
                McrLX           0.000000
                McrLY           0.000000
                McrUX           300.000000
                McrUY           0 Offset OnlySite:McrUX
                ProdFunc        1.000000
                Limit           1.000000
        @end Site OnlySite
        
        @begin Species Bacteria
                Type            Fission2D
                Mobile          0       
                BioScale        5.400000
                Birthday        0       
                Deathday        0       
                InitNum         2       
                Color           2       
                TaxRate         0.145
                BreedSize       3.0 
                Roll            1.0
                observePop
                observeBiomass
        @end Species Bacteria
        
There are lots of other things one can do in a Gecko protocol, but we'll
deal with this trivial one.  Gecko, if told to set up from a protocol, reads
in the first section.  (GeckoControlSwarm-buildObjects, similar to the 
observer Swarm concept, I think, although I set a controller above the display
and model.)  The list of parameters for RunControl exists before reading the 
protocol.  At @end of reading RunControl, that list is -apply'd.  Same 
happens for "World" (GeckoModelSwarm-buildObjects). 

    The model -buildObjects also knows to expect arbitrarily many Site, Species,
and CompositeSpecies (CompositeSpecies Plants=smallplant & bigplant & 
purpleplant, etc.) directives in the protocol.

    These are uglier, because until the directive and "Type" are hit, no
parameter list for these things can exist.  So, when reading, once the Type
is known, a Species/Site can be created of specified Type (class).  There's
a default "grandma" progenitor of each Type.  Grandma creates its parameter
list with default values.  After that, parameter loading can continue.
Parameters get -apply'd to the grandma.  These Parameterized lists are actually
composed of two lists of parameters--those common to Species, etc., and
those added on by the grandma of specific Type.  (For "Bacteria", the 
parameters down to "Color" are all-Species, then "TaxRate", "BreedSize", and
"Roll" are peculiar to class "Fission2D".)

    Each @address@hidden is operating on a single Parameterized object.
At any point in here, a non-parameter may be encountered.  Execute it on the
current Parameterized object.  (So, above, "observePop" is executed on 
Species "Bacteria".)  I'd like these to take (parameter) arguments, but
haven't done it yet.  Some parameters are offsets from others.  That's 
important in the parameter search engine, as well as preventing multiple
(error-prone) entry of the same parameter.  It would be lovely if params
allowed arbitrarily complex specification (this is one-third that, etc.)
but I didn't put that kind of effort into this.  My parameters have an 
additional "Vary" flag.  Any parameter can be flagged to "Vary" in the
search engine.  In my implementation, the varyflag is part of the basic 
Param.

    After the protocol is loaded, the simulation starts.  Instantiating
agents into the world happens during the simulation.

    I have an Evolution Strategy search engine for exploring parameter space.
Historically, this came first, then the parameter engine, and last the 
protocol, which is about exactly backwards.  Anyway, this engine can take over
and direct the simulation.  It starts after the protocol is loaded and before
simulation begins.  It forms the first parameter list by reading the model
already constructed.  (The model holds lists of Species and Sites.)  This list
is turned into a table of varied candidate lists for evaluation.  Then the 
simulations are run round-robin to score the parameter combinations.  And so
on.  (Table begets table until "done".)

    It would be nice to hook in/out different search engines.

    Dunno if this helps any.
    
Ciao,   
    Ginger