RE: record & replay of probe activity

[Sven N. Thommesen]

Rick & Steve: 

I believe we discussed at Swarmfest a concept that went a little beyond
what you are getting at here: instead of thinking in terms of 'setting a
variable', think in terms of arbitrary messages being sent to specified
objects. These messages *may* just alter some variable, or may cause the
receiver to alter its behavior in a more complex way. Or perhaps it
triggers a cascade of messages being sent to other objects...

While much of this can be done using the existing Swarm scheduling
mechanism (taking input from that saved log file / edited log file / brand
new script file) -- there's a possible problem: how do you schedule a
message to an object (agent) who hasn't been created yet (but presumably
will exist by the time the message is to be delivered) ?

I strongly support the inclusion of a facility like this in Swarm, because
it will allow us not only to replay simulations where the operator
interacted with  the application, but also to create simulations that play
out a script that represents a possible history of (external?) events.

Sven Thommesen
Auburn University

At 11:45 AM 5/29/97 -0400, you wrote:
>
>Steve,
>I agree there are two functions as you mention,
>recording what one did and playback of a run including
>all the changes via gui one did,
>and that one might use one without the other.
>(I'm sorry if that wasn't clear in my posting.)
>
>I'm not totally comfortable with having the probe
>do the recording directly, but maybe I can be convinced
>of the errors of my thinking.
>My concerns are:
>
>1. I like to record all these changes in with the
>   same file of initialization state *and* with
>   the data that is produced.
>   That way I can look at/save one file and have
>   all I need to see what happened and/or to do the run again.
>   I'm not sure that can be done cleanly if everything
>   is turned over to probes.  (eg my report file
>   will already be an open file, so I'd want to pass a
>   FILE ptr to the probe, or an equivalent swarm 
>   output file object.)
>
>   Of course I can imagine other people will have a preference
>   for some other approach, eg, having different files
>   for initial state, for recording during-run changes,
>   and for output data.
> 
>2. I like having more control over what happens
>   when I set a variable.
>   For the recording purposes, I like having control
>   of the format.
>   But having a setMyVar: method allows me to do
>   other things, eg, check the value being set
>   and conditionally accepting it based on
>   the values of other variables.
>   (Of course this can get complicated and not
>   work in some cases.)
>   
>In short, yes, its nice to have Swarm do as much
>as possible along these lines, so users don't have
>to do it, where "it" is some standard common approach.
>
>But...I still think tools like Probes can also be much
>more powerful (flexible) if they provide some
>judiciously placed hooks that allow users to easily
>add some custom processing.
>
>That's why I too like the idea of an setMyVar:
>method being optionally provided by the user, but if
>its there, having swarm use it at all the right places
>(eg in VarProbes).
>
>I don't know...maybe I am just furiously agreeing with you!
>
> - r
>
>Rick Riolo                       address@hidden
>Program for Study of Complex Systems (PSCS)
>1061 Randall Lab     University of Michigan
>Ann Arbor MI 48109-1120
>http://pscs.physics.lsa.umich.edu/PEOPLE/rlr-home.html
>
>On Thu, 29 May 1997, Steven Clark wrote:
>
>> Date: Thu, 29 May 1997 11:16:55 -0400
>> From: Steven Clark <address@hidden>
>> To: "'address@hidden'" <address@hidden>
>> Subject: RE: record & replay of probe activity
>> 
>> Rick,
>> 
>> To incorporate your ideas neatly into Swarm you need Swarm itself to do
>> all the work.  The design you mentioned requires the object being set to
>> have a setMethod that records the setting of the IV into a file.  I
>> suggest that the probe itself record the activity into the file.
>> 
>> I agree that things would be cleaner from Swarm's point of view if we
>> insisted that all probe-settable IVs had setMyVar: methods, but that
>> would put a burden on the simulation programmer.  I like the idea of
>> using setMyVar: if it exists, otherwise directly modifying the data of
>> the object.
>> 
>> Back to recording and replaying probe activity, I suggest that you
>> really want two related, but independent capabilities:  record and
>> playback.  The record facility would capture all IV settings done via
>> probes during a run, into a file.  The playback facility would read a
>> file (of the same format) and schedule all the activities therein to
>> take place at the appropriate times.  I can imagine situations where one
>> might want to use either one without the other, or to manually (or
>> programmatically) edit the file.
>> 
>> (I bet that with a fully functional palyback facility we could have
>> written a script to generate a playback file that would get our "sc01"
>> simulation into a steady state.)
>> 
>> I am suspicious that there were some interesting details in the playback
>> that you didn't bother to mention in your posting.
>> 
>> Steven J. Clark       address@hidden       313-769-4396
>> Center for Electronic Commerce, Industrial Technology Institute
>> Box 1485, Ann Arbor, MI  48106
>> 
>> 
>>                   ==================================
>>    Swarm-Support is for discussion of the technical details of the day
>>    to day usage of Swarm.  For list administration needs (esp.
>>    [un]subscribing), please send a message to <address@hidden>
>>    with "help" in the body of the message.
>>                   ==================================
>> 
>
>                  ==================================
>   Swarm-Support is for discussion of the technical details of the day
>   to day usage of Swarm.  For list administration needs (esp.
>   [un]subscribing), please send a message to <address@hidden>
>   with "help" in the body of the message.
>                  ==================================
>

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================