Re: Drone (was Re: ObjectLoader & batch processing)

[Theodore C. Belding]

That's more or less the way Drone worked last week.  Some parameters (such
as the path of the input file) were passed to the target program using
command-line options; most of them were passed in an input file that was
generated by the Drone script.  The input file had to be in an arcane
format that we specified.

This week, everything's different. Each run of the target program is
started up from scratch as a new process, just as before.  But we made the
input file optional, and Drone doesn't generate it, it just spits out a
chunk of text verbatim that you specify.  Any program parameters that
change from run to run, such as the seed or any swept parameters, are
passed via command-line options.  You can also pass any other parameters
you like using the command-line.  The intent is to be able to use Drone
with as many different kinds of simulation programs as possible, including
those that don't use any input file at all.

Currently you need command line options to specify the seed, the run number
(along with an optional prefix or base file name for that run), and the
ability to set a runtime parameter.  If you use an input file, you also
need to be able to specify the input file path.  And finally there's an
option to get version info from the target program, which would require
another command line option.  The actual option used for each of these (-D,
-IF=, or whatever) is specified by you.

I really don't see a way to avoid using command line options for this kind
of batch processing.  At the very least, you need to specify the input file
path.  And if you require using an input file, the Drone script needs to
know the file's syntax.  This means that you can't run Drone out of the box
with pre-existing programs with their own input file syntax, etc., such as
lilgp or Genesis, say.  If you have any ideas on how to avoid using
command-line options entirely, please let us know!

So, to sum up, I think there needs to be a convention of what command-line
options get parsed by initSwarm and which get parsed by
application-specific code.  At the very least, we need to know what
initSwarm does if it runs across an option it doesn't recognize.

More on this later.
-Ted

At 2:31 PM -0600 10/29/96, Sven Thommesen wrote:
>At 06:39 PM 10/28/96 -0500, Theodore C. Belding wrote:
>
>>programs as possible. (There's nothing in Drone that is Swarm-specific.)
>>And we still need a good convention for passing command-line arguments to
>>Swarm applications.
>>
>Ted,
>
>for my own use I had in mind defining a 'parameter' object containing as
>data a set of parameters for one run of my application, and using the
>ObjectLoader to read an instance in from disk. The parameter object could
>then distribute the relevant parameters to their target agents/swarms
>internally to the application during the object creation phase.
>
>Left for Drone to do would be generating a different parameter set disk file
>for each run, and to invoke the application. No command line parameters
>needed.
>
>Does this sound reasonable to you, and would Drone handle such a scenario?
>
>--Sven

--
Ted Belding                      <mailto:address@hidden>
University of Michigan Program for the Study of Complex Systems
<http://www-personal.engin.umich.edu/~streak/>