Print

Print


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/
>