Hi Sean,

Thanks alot. This makes sense to me for my use. Sometimes I'll be
running from the GUI to see what is going on but I'll also want to do
large parameter sweeps without visualization just gathering data.

For the large parameter sweeps the current plan is to write a script
that starts each parameter set as a different simulation run from the
command-line, ships each particular run to a node on our cluster,
output appropriate checkpoints, and then grab back the final results
and collate them for further analysis. The paramDB example gave me
ideas on how to go about getting the script to send a parameter set
to a simulation.

As to a suggestion about a parameter facility within the Mason
library, whether you'd want to add a facility probably depends on
what the main users of Mason are trying to do and/or whether adding
such a facility would attract a new class of users. As I'm sure
you're aware both RePast and NetLogo provide built-in facilities for
constructing parameter sweeps. I'm partial to specifying a parameter
file (ala Repast) that can be called to control a set of runs. Would
an expansion of your doLoop to handle that make sense?

Again, thank you for the good advice!

Mark


On Oct 12, 2006, at 11:27 AM, Sean Luke wrote:

Hi Mark. If you're ONLY going to be running the simulation on the
command-line, then it's probably easiest to just write your own
doLoop. If not, you might do it like this:

1. Make a Steppable which shuts down the simulation.

public class KillSteppable implements Steppable
{
public void step(SimState state)
{
state.kill();
}
}

2. Stick it in a MultiStep (a convenience class we wrote which only
calls its subsidiary Steppable once every N times, among other options):

Steppable a = new MultiStep(new KillSteppable(), numTimeSteps, true);

3. Schedule the MultiStep repeating every timestep. After
numTimeSteps, it'll fire its KillSteppable, which will stop the
simulation.

This approach would work inside the simulation and has the benefit of
being part of the model -- it can get serialized and will work in the
GUI and on the command line.

Other points:

- MASON doesn't have an extensive parameter facility. We have a
tutorial online on one way we do it, but we've always considered
parameters as a roll-your-own thing, mostly because we typically
embed MASON in a larger optimization or parameter-iteration facility,
so it never made sense for us to have a second one in the MASON
library per se. But maybe that should change. Suggestion?

- The GUI has an option for stopping the run after a certain number
of time ticks, but it's only user settable.

Sean


On Oct 12, 2006, at 10:56 AM, Mark Mcbride wrote:

> Hi Everyone,
>
> I'm new to using Mason although I've been using Repast and NetLogo
> for awhile. I really like Mason's separation of the code for the
> simulation versus the visualization and decided to use it for a new
> project I'm working on. I've worked through the tutorials, how-
> to's, and archives and have a question about basic design.
>
> What is the cleanest way to have the number of ticks the schedule
> is to run be a parameter that is set by the user either in the GUI
> interface or from a command-line call to the simulation? Would it
> be better to write my own doLoop (ala, tutorial 1/2) or would is
> there a way to cleanly use the doLoop method in your main but have
> the number of ticks passed by the command-line call or by the GUI?
>
> Thanks!
>
> Mark
>
> Mark E. McBride
> Professor and Director of Graduate Studies
> Department of Economics
> 208 Laws Hall - Miami University
> Oxford, OH 45056
> 513 529-2864
> email: [log in to unmask]
> IM: mcbridme
> http://mcbridme.sba.muohio.edu/
>