Re: ObjectLoader & batch processing

[Sven Thommesen]

At 04:11 PM 10/29/96 -0500, Rick Riolo wrote:
>
>daring to speak for ted...
>
>I think drone will be released within a week.
>(we've been using it and making changes based on our
>experience....we made some recent changes and after we exercise
>them a bit in the next few days, and get the doc caught up
>to those changes, I think its ready to go.)
>
>Re. Sven's other question about not using run time parameters:
>
>Sven, I'm not sure I understand how you were thinking of doing
>things like sweep over some values for a parameter (or more).
>Were you thinking to have a separate file to load for each case?

Well,

before I read Roger's piece, I was thinking that a few nested
*for* loops in the Batch Swarm would do fine, with a 'cleanup'
step added to the present code for each run.

Until that works, I suppose an external scripting language doing
the same for-loops will do. 

As for how to give parameters to Swarm, if you're only altering a
very small set I suppose command-line arguments are ok. In my
(first, very simple) model, there's some 60 input parameters to
play with. I imagined an input record of 60 fields for ObjectLoader
to fetch, with the script language generating a new one for each
invocation. 

Not that I'm planning to sweep over all 60 parameters! I firmly believe
that achieving tenure before retirement is a worthy goal ... :-)

My model also has 4 state variables for each of 500 bugs for a full
output snapshot per time period, not counting possible totals or 
averagers! Practical suggestions for how to manage the deluge of 
data are welcome...

One thing we need to keep in mind is how easy it is to preserve our
input & output for documentation purposes -- perhaps a reviewer of
a paper (or, heaven forbid, an actual reader) would want to replicate
our path-breaking experiment ? Then I suppose a text file full of 
parameters is easier to keep than a batchSwarm or script file that's 
since been edited for further runs ...

Isn't science wonderful?

--Sven



>Drone's approach is to have one file with the
>"basic" parameter settings, and then uses command line arguments
>to override those during a sweep of parameters.
>
>One reason for this approach is so that drone doesn't have
>to worry about the structure of the parameter settings file
>for any particular program used with it.  Your parameter file
>can be whatever your program needs, from simple swarm objectsave/load
>format to whatever complexity you need.   
>It also means drone will work with non-swarm programs.
>
> - 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 Tue, 29 Oct 1996, Manor Askenazi wrote:
>
>> Date: Tue, 29 Oct 1996 13:55:24 -0700
>> From: Manor Askenazi <address@hidden>
>> To: address@hidden
>> Cc: address@hidden
>> Subject: Re: ObjectLoader & batch processing
>> 
>> 
>>    Boy, that was a bummer.
>> 
>> I know.
>> 
>>    Well, on to the next question: do you see it as a reasonable thing to do 
>>    (or even a possible thing to do) to allow the Swarm app to execute a 
>>    number of runs itself (resetting simTime to 0, killing and re-generating 
>>    swarms & objects, etc between runs)
>> 
>> Roger might have some guidelines on this... This seems quite difficult.
>> 
>>    or is it preferable to do it Ted's way with a script external to Swarm 
>>    invoking the app a number of times with different parameters?
>> 
>> Ted's way works. Hopefully he will soon release his framework, and then
>> it won't just work, it'll work on many machines at once!!!
>> 
>> Manor.
>> 
>
>