repast-developer

Re: [Repast-developer] PGM files in the demo jars but not in the repast.jar

[<gu...@la...>]

Hi,

I'd also vote for some package-restructuring, especially
w.r.t. demos and tests. Whenever you guys find the time and
strength.

Cheers,

Gulya

PS: Just showing that I'm active over this side of the 
pond, I guess... :)



Id=E9z=E9s "Thomas R. Howe" <th...@sr...>:

> I agree.  This seems like a fairly unobtrusive change.  Both Nick and =
I
> would like to do a massive package restructuring at some point, also. 
> Probably not until 3.0, though.  I'll look into making these changes.
> 
> 
> -Tom
> 
> On Thu, 2002-12-26 at 11:45, Mark R. Diggory wrote:
> > Just a suggestion, but wouldn't it be better to consolidate the demo=
s 
> > into their own directory separate of the "sim" directory?
> > 
> > uchicago.src.sim.engine
> > uchicago.src.sim...
> > 
> > uchicago.src.demo.hexaBugs
> > uchicago.src.demo...
> > 
> > then you wouldn't need complex "exclude" ant rules that needed to be=
 
> > updated whenever a new demo is added.
> > 
> > In fact, if you look at distributions like jakarta commons, you find=
 
> > that there is an even greater separation between demos/tests and the=
 
> > core package similar to the following:
> > 
> > / =3D cvs directory
> > . =3D java package
> > 
> > /repast/src/uchicago.src.sim.engine
> > /repast/src/uchicago.src.sim...
> > /repast/build.xml
> > 
> > /repast/demo/HeatBugs/src/uchicago.src.demo.heatBugs
> > /repast/demo/HeatBugs/build.xml
> > 
> > /repast/demo/HexaBugs/src/uchicago.src.demo.hexaBugs
> > /repast/demo/HexaBugs/build.xml
> > /repast/demo/build.xml
> > 
> > by dividing the core and demos into separate cvs directories with 
> > separate build scripts, you can inherently enforce the rule that the=
 
> > core build success is never be dependent on any of the demo build. U=
sing 
> > "fail on error/don't fail on error" switches in ant makes it so a bu=
ild 
> > failure in a demo never breaks the entire build of the core.
> > 
> > You also get the benifit that separate build.xml scripts for each de=
mo 
> > can be kept small. In the end it's kindof like a "make" environment 
> > where build.xml scripts in lower directories get called by those in 
> > higher directories. This way its always easy to create new demos and=
 
> > include them with thier own build.xml files. The "core" build files 
> > never really would have to be modified to add a demo in the future.
> > 
> > 2cents,
> > Mark
> > 
> > Thomas R. Howe wrote:
> > > Yeah, none of the demos are supposed to be included in the repast.=
jar. 
> 
> > > This is what happened:
> > > I wrote these two demos.  Nick usually builds the distribution fro=
m an
> > > ant build.xml file.  The build file excludes the demo directories =
from
> > > the output, but these two weren't added to the build file, so they
> ended
> > > up getting added to repast.jar. 
> > > 
> > > I'll go ahead and make the changes in the build.xml file, so that =
these
> > > won't be included in the repast.jar of future releases.
> > > 
> > > -Tom
> > > 
> > > 
> > > On Wed, 2002-12-25 at 18:36, Mark R. Diggory wrote:
> > > 
> > >>Actually, It looks like its only hexaBugs and gisModel that are 
> > >>replicated inside repast.jar.
> > >>
> > >>
> > >>Mark R. Diggory wrote:
> > >>
> > >>>Nick and Repast Team,
> > >>>
> > >>>I was playing around in the 2.0 repast jar and I came to a little=
 mess
> 
> > >>>you might want to know about.
> > >>>
> > >>>I recognize that in the available binary distribution of repast t=
hat the
> 
> > >>>  individual demo examples each are contained in their own jars (=
and 
> > >>>that some of these jars also contain the "pgm" files required by =
those
> 
> > >>>simulations, which get loaded as resources off the classloader).
> > >>>
> > >>>I was also noticing that the "repast.jar" also contains these cla=
sses 
> > >>>for all the demos as well. Is this a replication of compiled clas=
ses 
> > >>>that could be done away with?
> > >>>
> > >>>It is the case that the repast.jar, while having the classes for =
the 
> > >>>examples, does not contain the non-class files, like "pgm" files 
> > >>>required by the demo to execute properly, these files appear to b=
e 
> > >>>loaded as resources in the same namespace as each demo package so=
 these
> 
> > >>>demos break when you try to run them straight out of repast.jar.
> > >>>
> > >>>I might recommend either:
> > >>>1.) removing the demo classes from the repast.jar or
> > >>>2.) including the support files for each demo into the repast.jar=
.
> > >>>
> > >>>As its probibly the case that the number of demos will grow over =
time. I
> 
> > >>>would suggest (1) just removing the demos from the repast.jar as =
a more
> 
> > >>>logical solution.
> > >>>
> > >>>Happy Holidays,
> > >>>Mark
> > >>>
> > >>>
> > >>>
> > >>>-------------------------------------------------------
> > >>>This sf.net email is sponsored by:ThinkGeek
> > >>>Welcome to geek heaven.
> > >>>http://thinkgeek.com/sf
> > >>>_______________________________________________
> > >>>Repast-developer mailing list
> > >>>Rep...@li...
> > >>>https://lists.sourceforge.net/lists/listinfo/repast-developer
> > >>
> > >>
> > >>
> > >>-------------------------------------------------------
> > >>This sf.net email is sponsored by:ThinkGeek
> > >>Welcome to geek heaven.
> > >>http://thinkgeek.com/sf
> > >>_______________________________________________
> > >>Repast-developer mailing list
> > >>Rep...@li...
> > >>https://lists.sourceforge.net/lists/listinfo/repast-developer
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Repast-developer mailing list
> > Rep...@li...
> > https://lists.sourceforge.net/lists/listinfo/repast-developer
> -- 
> Tom Howe
> Social Science Research Computing
> University of Chicago
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
> 

[Repast-developer] Gui/Batch Control via Controllers

[Mark R. D. <mdi...@la...>]

I've also encountered some conceptual issue with GUI'ness and 
Batchi'ness in the BaseController that might be good to toss your way.

1.) A model may have GUI's and DataRecorders that are sensitive to 
whether the model is being run as GUI and/or Batch.

2.) "Run with GUI" and "run as batch" are related but separate concepts 
and appear out of different needs I.E. a batch controller could include 
some GUI activity within it (independent of the main controller gui that 
is).

With this in mind it might be good to include setters/getters for 
GUI'ness and Batchi'ness into IController and BaseConroller.

public boolean isGui();
public boolean isBatch();
public void setGui();
public void setBatch();


This because,

(1)
public boolean isGUI();
public boolean isBatch();

are present in AbstractGUIController

(2)
public boolean isGUI();

is present in ThinController

(3)
public boolean isBatch();
is present in BatchController and BaseController


Maybe having these be standard methods defined in IController and 
Implemented by default in BaseController will allow models to use them 
when running reguardless of the Controller implementation. It would 
still be the case that an Implementation could overide the methods in 
their code.

Other Notes:

There also seems to be a variable "isGui" in both ThinController and 
BaseController, that could be confusing.

It might be clear for bean property introspection if isGUI() was 
actually isGui. Then the property name would be "gui" instead of "gUI".

Cheers,
Mark

[Repast-developer] Default "empty" constructors for Controllers.

[Mark R. D. <mdi...@la...>]

Nick,

Is it possible to also enforce some rules that IControllers need to 
support at least an empty constructor for "Beanish" related 
capabilities? This is an issue because, while BaseController does have 
an empty constructor, it isn't automatically available to classes that 
extend it.

The reason I suggest this is that having an empty constructor and 
get/set methods provides for a clean separation between the creating of 
an object and its "configuration", something that is valuable in other 
areas of repast such as constructing models and then setting the model's 
properties. As well, for my work in jelly to be extensible (and easier 
to code) it would be benifical to have empty constructors available for 
the construction of IControllers.

This constructor issue can be seen in both BatchController and 
ThinController.


-Mark

>> Hi,
>>
>> The new IController interface defines methods for executing (starting,
>> stopping etc.) a simulation. The BaseController implements this
>> Interface in an asynchronous way, that is, it creates a thread and
>> executes scheduled actions in this thread. Start, stop etc. merely
>> (oversimplifying a bit) start and stop this thread. The batch controller
>> and gui controller add parameter handling on top of this. A new
>> controller, Thin Controller, adds a bit more that is necessary for a
>> non-abstract controller, but it still relies on BaseController to set up
>> the thread.
>>
>> So, if you want a controller that not so asynchronous then what repast
>> supplies won't work. However, it would be fairly easy to construct such
>> a thing using BaseController as a model. In fact it sounds like all you
>> want is to create a Schedule add actions to it for execution and then
>> iterate over the Schedule calling execute some number of times. Again,
>> looking at the code in Schedule and ScheduleBase would might help you
>> out here.

Re: [Repast-developer] PGM files in the demo jars but not in the repast.jar

[Thomas R. H. <th...@sr...>]

I agree.  This seems like a fairly unobtrusive change.  Both Nick and I
would like to do a massive package restructuring at some point, also. 
Probably not until 3.0, though.  I'll look into making these changes.


-Tom

On Thu, 2002-12-26 at 11:45, Mark R. Diggory wrote:
> Just a suggestion, but wouldn't it be better to consolidate the demos 
> into their own directory separate of the "sim" directory?
> 
> uchicago.src.sim.engine
> uchicago.src.sim...
> 
> uchicago.src.demo.hexaBugs
> uchicago.src.demo...
> 
> then you wouldn't need complex "exclude" ant rules that needed to be 
> updated whenever a new demo is added.
> 
> In fact, if you look at distributions like jakarta commons, you find 
> that there is an even greater separation between demos/tests and the 
> core package similar to the following:
> 
> / = cvs directory
> . = java package
> 
> /repast/src/uchicago.src.sim.engine
> /repast/src/uchicago.src.sim...
> /repast/build.xml
> 
> /repast/demo/HeatBugs/src/uchicago.src.demo.heatBugs
> /repast/demo/HeatBugs/build.xml
> 
> /repast/demo/HexaBugs/src/uchicago.src.demo.hexaBugs
> /repast/demo/HexaBugs/build.xml
> /repast/demo/build.xml
> 
> by dividing the core and demos into separate cvs directories with 
> separate build scripts, you can inherently enforce the rule that the 
> core build success is never be dependent on any of the demo build. Using 
> "fail on error/don't fail on error" switches in ant makes it so a build 
> failure in a demo never breaks the entire build of the core.
> 
> You also get the benifit that separate build.xml scripts for each demo 
> can be kept small. In the end it's kindof like a "make" environment 
> where build.xml scripts in lower directories get called by those in 
> higher directories. This way its always easy to create new demos and 
> include them with thier own build.xml files. The "core" build files 
> never really would have to be modified to add a demo in the future.
> 
> 2cents,
> Mark
> 
> Thomas R. Howe wrote:
> > Yeah, none of the demos are supposed to be included in the repast.jar.  
> > This is what happened:
> > I wrote these two demos.  Nick usually builds the distribution from an
> > ant build.xml file.  The build file excludes the demo directories from
> > the output, but these two weren't added to the build file, so they ended
> > up getting added to repast.jar. 
> > 
> > I'll go ahead and make the changes in the build.xml file, so that these
> > won't be included in the repast.jar of future releases.
> > 
> > -Tom
> > 
> > 
> > On Wed, 2002-12-25 at 18:36, Mark R. Diggory wrote:
> > 
> >>Actually, It looks like its only hexaBugs and gisModel that are 
> >>replicated inside repast.jar.
> >>
> >>
> >>Mark R. Diggory wrote:
> >>
> >>>Nick and Repast Team,
> >>>
> >>>I was playing around in the 2.0 repast jar and I came to a little mess 
> >>>you might want to know about.
> >>>
> >>>I recognize that in the available binary distribution of repast that the 
> >>>  individual demo examples each are contained in their own jars (and 
> >>>that some of these jars also contain the "pgm" files required by those 
> >>>simulations, which get loaded as resources off the classloader).
> >>>
> >>>I was also noticing that the "repast.jar" also contains these classes 
> >>>for all the demos as well. Is this a replication of compiled classes 
> >>>that could be done away with?
> >>>
> >>>It is the case that the repast.jar, while having the classes for the 
> >>>examples, does not contain the non-class files, like "pgm" files 
> >>>required by the demo to execute properly, these files appear to be 
> >>>loaded as resources in the same namespace as each demo package so these 
> >>>demos break when you try to run them straight out of repast.jar.
> >>>
> >>>I might recommend either:
> >>>1.) removing the demo classes from the repast.jar or
> >>>2.) including the support files for each demo into the repast.jar.
> >>>
> >>>As its probibly the case that the number of demos will grow over time. I 
> >>>would suggest (1) just removing the demos from the repast.jar as a more 
> >>>logical solution.
> >>>
> >>>Happy Holidays,
> >>>Mark
> >>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This sf.net email is sponsored by:ThinkGeek
> >>>Welcome to geek heaven.
> >>>http://thinkgeek.com/sf
> >>>_______________________________________________
> >>>Repast-developer mailing list
> >>>Rep...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/repast-developer
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Repast-developer mailing list
> >>Rep...@li...
> >>https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Tom Howe
Social Science Research Computing
University of Chicago

Re: [Repast-developer] PGM files in the demo jars but not in the repast.jar

[Mark R. D. <mdi...@la...>]

Just a suggestion, but wouldn't it be better to consolidate the demos 
into their own directory separate of the "sim" directory?

uchicago.src.sim.engine
uchicago.src.sim...

uchicago.src.demo.hexaBugs
uchicago.src.demo...

then you wouldn't need complex "exclude" ant rules that needed to be 
updated whenever a new demo is added.

In fact, if you look at distributions like jakarta commons, you find 
that there is an even greater separation between demos/tests and the 
core package similar to the following:

/ = cvs directory
. = java package

/repast/src/uchicago.src.sim.engine
/repast/src/uchicago.src.sim...
/repast/build.xml

/repast/demo/HeatBugs/src/uchicago.src.demo.heatBugs
/repast/demo/HeatBugs/build.xml

/repast/demo/HexaBugs/src/uchicago.src.demo.hexaBugs
/repast/demo/HexaBugs/build.xml
/repast/demo/build.xml

by dividing the core and demos into separate cvs directories with 
separate build scripts, you can inherently enforce the rule that the 
core build success is never be dependent on any of the demo build. Using 
"fail on error/don't fail on error" switches in ant makes it so a build 
failure in a demo never breaks the entire build of the core.

You also get the benifit that separate build.xml scripts for each demo 
can be kept small. In the end it's kindof like a "make" environment 
where build.xml scripts in lower directories get called by those in 
higher directories. This way its always easy to create new demos and 
include them with thier own build.xml files. The "core" build files 
never really would have to be modified to add a demo in the future.

2cents,
Mark

Thomas R. Howe wrote:
> Yeah, none of the demos are supposed to be included in the repast.jar.  
> This is what happened:
> I wrote these two demos.  Nick usually builds the distribution from an
> ant build.xml file.  The build file excludes the demo directories from
> the output, but these two weren't added to the build file, so they ended
> up getting added to repast.jar. 
> 
> I'll go ahead and make the changes in the build.xml file, so that these
> won't be included in the repast.jar of future releases.
> 
> -Tom
> 
> 
> On Wed, 2002-12-25 at 18:36, Mark R. Diggory wrote:
> 
>>Actually, It looks like its only hexaBugs and gisModel that are 
>>replicated inside repast.jar.
>>
>>
>>Mark R. Diggory wrote:
>>
>>>Nick and Repast Team,
>>>
>>>I was playing around in the 2.0 repast jar and I came to a little mess 
>>>you might want to know about.
>>>
>>>I recognize that in the available binary distribution of repast that the 
>>>  individual demo examples each are contained in their own jars (and 
>>>that some of these jars also contain the "pgm" files required by those 
>>>simulations, which get loaded as resources off the classloader).
>>>
>>>I was also noticing that the "repast.jar" also contains these classes 
>>>for all the demos as well. Is this a replication of compiled classes 
>>>that could be done away with?
>>>
>>>It is the case that the repast.jar, while having the classes for the 
>>>examples, does not contain the non-class files, like "pgm" files 
>>>required by the demo to execute properly, these files appear to be 
>>>loaded as resources in the same namespace as each demo package so these 
>>>demos break when you try to run them straight out of repast.jar.
>>>
>>>I might recommend either:
>>>1.) removing the demo classes from the repast.jar or
>>>2.) including the support files for each demo into the repast.jar.
>>>
>>>As its probibly the case that the number of demos will grow over time. I 
>>>would suggest (1) just removing the demos from the repast.jar as a more 
>>>logical solution.
>>>
>>>Happy Holidays,
>>>Mark
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This sf.net email is sponsored by:ThinkGeek
>>>Welcome to geek heaven.
>>>http://thinkgeek.com/sf
>>>_______________________________________________
>>>Repast-developer mailing list
>>>Rep...@li...
>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] PGM files in the demo jars but not in the repast.jar

[Thomas R. H. <th...@sr...>]

Yeah, none of the demos are supposed to be included in the repast.jar.  
This is what happened:
I wrote these two demos.  Nick usually builds the distribution from an
ant build.xml file.  The build file excludes the demo directories from
the output, but these two weren't added to the build file, so they ended
up getting added to repast.jar. 

I'll go ahead and make the changes in the build.xml file, so that these
won't be included in the repast.jar of future releases.

-Tom


On Wed, 2002-12-25 at 18:36, Mark R. Diggory wrote:
> Actually, It looks like its only hexaBugs and gisModel that are 
> replicated inside repast.jar.
> 
> 
> Mark R. Diggory wrote:
> > Nick and Repast Team,
> > 
> > I was playing around in the 2.0 repast jar and I came to a little mess 
> > you might want to know about.
> > 
> > I recognize that in the available binary distribution of repast that the 
> >   individual demo examples each are contained in their own jars (and 
> > that some of these jars also contain the "pgm" files required by those 
> > simulations, which get loaded as resources off the classloader).
> > 
> > I was also noticing that the "repast.jar" also contains these classes 
> > for all the demos as well. Is this a replication of compiled classes 
> > that could be done away with?
> > 
> > It is the case that the repast.jar, while having the classes for the 
> > examples, does not contain the non-class files, like "pgm" files 
> > required by the demo to execute properly, these files appear to be 
> > loaded as resources in the same namespace as each demo package so these 
> > demos break when you try to run them straight out of repast.jar.
> > 
> > I might recommend either:
> > 1.) removing the demo classes from the repast.jar or
> > 2.) including the support files for each demo into the repast.jar.
> > 
> > As its probibly the case that the number of demos will grow over time. I 
> > would suggest (1) just removing the demos from the repast.jar as a more 
> > logical solution.
> > 
> > Happy Holidays,
> > Mark
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Repast-developer mailing list
> > Rep...@li...
> > https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Tom Howe
Social Science Research Computing
University of Chicago

Re: [Repast-developer] PGM files in the demo jars but not in the repast.jar

[Mark R. D. <mdi...@la...>]

Actually, It looks like its only hexaBugs and gisModel that are 
replicated inside repast.jar.


Mark R. Diggory wrote:
> Nick and Repast Team,
> 
> I was playing around in the 2.0 repast jar and I came to a little mess 
> you might want to know about.
> 
> I recognize that in the available binary distribution of repast that the 
>   individual demo examples each are contained in their own jars (and 
> that some of these jars also contain the "pgm" files required by those 
> simulations, which get loaded as resources off the classloader).
> 
> I was also noticing that the "repast.jar" also contains these classes 
> for all the demos as well. Is this a replication of compiled classes 
> that could be done away with?
> 
> It is the case that the repast.jar, while having the classes for the 
> examples, does not contain the non-class files, like "pgm" files 
> required by the demo to execute properly, these files appear to be 
> loaded as resources in the same namespace as each demo package so these 
> demos break when you try to run them straight out of repast.jar.
> 
> I might recommend either:
> 1.) removing the demo classes from the repast.jar or
> 2.) including the support files for each demo into the repast.jar.
> 
> As its probibly the case that the number of demos will grow over time. I 
> would suggest (1) just removing the demos from the repast.jar as a more 
> logical solution.
> 
> Happy Holidays,
> Mark
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] PGM files in the demo jars but not in the repast.jar

[Mark R. D. <mdi...@la...>]

Nick and Repast Team,

I was playing around in the 2.0 repast jar and I came to a little mess 
you might want to know about.

I recognize that in the available binary distribution of repast that the 
   individual demo examples each are contained in their own jars (and 
that some of these jars also contain the "pgm" files required by those 
simulations, which get loaded as resources off the classloader).

I was also noticing that the "repast.jar" also contains these classes 
for all the demos as well. Is this a replication of compiled classes 
that could be done away with?

It is the case that the repast.jar, while having the classes for the 
examples, does not contain the non-class files, like "pgm" files 
required by the demo to execute properly, these files appear to be 
loaded as resources in the same namespace as each demo package so these 
demos break when you try to run them straight out of repast.jar.

I might recommend either:
1.) removing the demo classes from the repast.jar or
2.) including the support files for each demo into the repast.jar.

As its probibly the case that the number of demos will grow over time. I 
would suggest (1) just removing the demos from the repast.jar as a more 
logical solution.

Happy Holidays,
Mark

Re: [Repast-developer] Re: [Repast-interest] BaseController, Controller and BatchController (and Jelly)

[Andy C. <ac...@ll...>]

At 03:35 PM 12/16/2002 -0500, you wrote:
>Hi,
>
>The new IController interface defines methods for executing (starting,
>stopping etc.) a simulation. The BaseController implements this
>Interface in an asynchronous way, that is, it creates a thread and
>executes scheduled actions in this thread. Start, stop etc. merely
>(oversimplifying a bit) start and stop this thread. The batch controller
>and gui controller add parameter handling on top of this. A new
>controller, Thin Controller, adds a bit more that is necessary for a
>non-abstract controller, but it still relies on BaseController to set up
>the thread.
>
>So, if you want a controller that not so asynchronous then what repast
>supplies won't work. However, it would be fairly easy to construct such
>a thing using BaseController as a model. In fact it sounds like all you
>want is to create a Schedule add actions to it for execution and then
>iterate over the Schedule calling execute some number of times. Again,
>looking at the code in Schedule and ScheduleBase would might help you
>out here.

After studying the APIs and the code (out of 2.0) for the above classes, I 
can say... I partially get it. ;-)

Do you happen to have any documents, scribbles, backs of envelopes, etc., 
that help layout the "object interaction" amongst these various things? I 
forget what the official UML-ish name for that is, but the point is that 
the APIs do a fine job of laying out the class hierarchy and such; the 
pattern of communication between controllers, simModels, and Schedules 
remains confusing to me, probably largely because of the separate threads 
being used, and partially because I formed preconceived notions based only 
on the names of these classes and they don't seem to match what is there, 
and mostly because one has to read the code to figure it out rather than 
being able to see it in some sort of documentation. As you correctly 
surmised, my case should actually be easier since I will be controlling 
things programmatically and can, for example, avoid separate threads.

Obviously, though, I want to A) make changes that actually work, B) do the 
minimal amount of changes so that any future change to repast will have a 
minimal effect on whatever I write. To do that intelligently means I need a 
better understanding of the overall vision of the architecture associated 
with these things. The long way to do this is to keep studying the code, 
run it through the debugger and follow the call stack, etc., but if there's 
a headstart I'll take it.


>I've often thought that it should be possible to create composite nested
>simulations out of pieces that repast provides, and it would be good to
>see someone try!

I am going to try... How long I'll go before I give up remains unclear. If 
I get it working, we can discuss whether there is anything that can be 
reused in the Repast framework more generally...

Cheers,
Andy
============================================
Andrew J. Cleary, Software Engineer/Computational Scientist
Lawrence Livermore National Labs, 925-424-5890.
============================================

[Repast-developer] Nick out

[Nick C. <nic...@ve...>]

Hi,

I'm afraid I'll be unable to anwer any repast related queries this week. I'm away for the holidays, and forgot to bring the power supply for my laptop. I'll try and answer any unanswered questions when I return next week.

Nick

[Repast-developer] ProbeUtilities question

[Phil F. <pfe...@co...>]

Hi All,

I'm setting up a 3D version of DisplaySurface and am working on probing. 
I've put together a small class that implements CustomProbable and 
returns a double. When I determine that I've picked an object in 3D 
space, I place an instance of this class in a call to 
ProbeUtilities.probe(). As near as I can tell, this should fire up a 
pop-up window that shows my double and allows me to set it.
When I do this, I get an empty, untitled window. Any thoughts on how I 
get the data to display?

Thanks,

Phil Feldman

[Repast-developer] Descriptor question

[Phil F. <pfe...@co...>]

Hi All,

I've been integrating Java3D into the RePast framework (currently under 
1.4.1. Hopefully with few issues in the transition to 2.0). So far, the 
only significant change has been that I had to replace DisplaySurface 
with a new class, cleverly named DisplaySurface3D. I've enclosed a jpeg 
of some current work.

My question has to do with the rendering of the Probeable pop-up 
windows. The Probeable interface is inherently 2D, so I'll need 
something like a Probeable3D that's integrated with the J3D picking 
scheme. But where do I interface with the PropertyDescriptors? I'm a 
little lost there, and need a hint. It looks like I use IntrospectPanel, 
under ProbeUtilities, but I'm not quite sure how.

Thanks,

Phil Feldman

[Repast-developer] Re: [Repast-interest] RePast 2.0 released

[Rick R. <rl...@fi...>]

hi nick,
this is great, thanks.

a couple of notes:

- in the download, readme.html says its from 1.4 

- at sourceforge the how_to and api seem to be for 1.4.1
  but after a quick scan it looks like the download docs/ has 2.0,
  eg the how_to mentions vector GIS, so i guess you just
  have to move it in place on sourceforge

thanks,

 - r

-- 
Rick Riolo                           rl...@um...
Center for Study of Complex Systems (CSCS)
4477 Randall Lab                
University of Michigan         Ann Arbor MI 48109-1120
Phone: 734 763 3323                  Fax: 734 763 9267
http://cscs.umich.edu/~rlr

On 20 Dec 2002, Nick Collier wrote:

> Date: 20 Dec 2002 10:42:43 -0500
> From: Nick Collier <nic...@ve...>
> To: "Rep...@li..."
>     <Rep...@li...>,
>      repast-developer <rep...@li...>
> Subject: [Repast-interest] RePast 2.0 released
> 
> Hi,
> 
> RePast 2.0 has been released at long last. Thanks especially to Tom
> Howe, and Laszlo Gulyas and Mike North for their contributions to this
> release.
> 
> Note that there have been some important changes to RePast in this
> version, and users are encouraged to read the UPGRADING document in
> the repast directory.
> 
> We've provided some self-installers in addition to the usual zip and tgz
> files. Note that RePast 2.0 requires java 1.4 or java 1.4.1. However we
> have included a release for OSX users that have not upgraded to java
> 1.4, but that version does not have GIS support. Non-Mac users can get
> java 1.4 at: 
> 
> http://java.sun.com/j2se/downloads.html
> 
> Those of you have not upgraded to 1.4.1 will probably want to do so.
> Note that there is a bug in the ATI display drivers on windows for
> laptops that causes problems with java 1.4.1. In that case, 1.4 might be
> better, unless you can update your drivers.
> 
> You can get RePast 2.0 here:
> 
> http://repast.sourceforge.net/#download
> 
> A selection from the release notes follows:
> 
> ** New Features
> 
> *** New scheduling mechanism allowing for scheduling on doubles and for
> the execution of true threaded background actions.
> 
> *** Improved support for GIS, including support for vector gis as a
> spatial network.
> 
> *** Improved loading of models through the RePast toolbar.
> 
> *** EdgeFactory class for automating aspects of network link creation.
> 
> *** Improved network drawing.
> 
> *** Easier creation of graph sequences and histogram items through
> dynamic byte code compilation.
> 
> *** Draggable resizing of displays surfaces.
> 
> *** Support for quicktime movies of graphs and charts.
> 
> *** Includes the latest version of the colt library, patched for the
> Normal distribution bug.
> 
> *** Refactored core classes to allow more experienced programmers to
> more easily extend RePast.
> 
> ...
> 
> 
> 

[Repast-developer] RePast 2.0 released

[Nick C. <nic...@ve...>]

Hi,

RePast 2.0 has been released at long last. Thanks especially to Tom
Howe, and Laszlo Gulyas and Mike North for their contributions to this
release.

Note that there have been some important changes to RePast in this
version, and users are encouraged to read the UPGRADING document in
the repast directory.

We've provided some self-installers in addition to the usual zip and tgz
files. Note that RePast 2.0 requires java 1.4 or java 1.4.1. However we
have included a release for OSX users that have not upgraded to java
1.4, but that version does not have GIS support. Non-Mac users can get
java 1.4 at: 

http://java.sun.com/j2se/downloads.html

Those of you have not upgraded to 1.4.1 will probably want to do so.
Note that there is a bug in the ATI display drivers on windows for
laptops that causes problems with java 1.4.1. In that case, 1.4 might be
better, unless you can update your drivers.

You can get RePast 2.0 here:

http://repast.sourceforge.net/#download

A selection from the release notes follows:

** New Features

*** New scheduling mechanism allowing for scheduling on doubles and for
the execution of true threaded background actions.

*** Improved support for GIS, including support for vector gis as a
spatial network.

*** Improved loading of models through the RePast toolbar.

*** EdgeFactory class for automating aspects of network link creation.

*** Improved network drawing.

*** Easier creation of graph sequences and histogram items through
dynamic byte code compilation.

*** Draggable resizing of displays surfaces.

*** Support for quicktime movies of graphs and charts.

*** Includes the latest version of the colt library, patched for the
Normal distribution bug.

*** Refactored core classes to allow more experienced programmers to
more easily extend RePast.

...


-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] Re: [Repast-interest] BaseController, Controller and BatchController (and Jelly)

[Nick C. <nic...@ve...>]

Hi,

The new IController interface defines methods for executing (starting,
stopping etc.) a simulation. The BaseController implements this
Interface in an asynchronous way, that is, it creates a thread and
executes scheduled actions in this thread. Start, stop etc. merely
(oversimplifying a bit) start and stop this thread. The batch controller
and gui controller add parameter handling on top of this. A new
controller, Thin Controller, adds a bit more that is necessary for a
non-abstract controller, but it still relies on BaseController to set up
the thread. 

So, if you want a controller that not so asynchronous then what repast
supplies won't work. However, it would be fairly easy to construct such
a thing using BaseController as a model. In fact it sounds like all you
want is to create a Schedule add actions to it for execution and then
iterate over the Schedule calling execute some number of times. Again,
looking at the code in Schedule and ScheduleBase would might help you
out here. 

I've often thought that it should be possible to create composite nested
simulations out of pieces that repast provides, and it would be good to
see someone try!

As for posting post-doc announcements etc. repast-interest is a fine
place for that.

Nick

On Sun, 2002-12-15 at 15:23, Andy Cleary wrote:
> [My take on this seemed more appropriate to repast-developer than 
> repast-interest, so I've cross posted it...]
> 
> At 01:35 PM 12/8/2002 -0500, Mark R. Diggory wrote:
> >Hi all,
> >
> >I'm trying to do some development that involves using the Jelly/Ant 
> >scripting env (Apache Jakarta Commons) to build and execute my simulation 
> >in batch processes. Where before I was just execing my model as a Java 
> >Runnable using Ant's Java Task, now I am actaully trying to instantiate 
> >the model class and controller from within Jelly Tags. (Analogous to "JSP 
> >tags in JSP/Servlets" or "Ant tasks in Ant".  Jelly is a really powerfull 
> >XML based scripting environment that can be extended with other scripting 
> >languages (java,javascript,jpython...).
> >
> >http://jakarta.apache.org/commons/sandbox/jelly/
> >
> >I'm finding that the Controller class hierarchy is a little hard to work 
> >with as an Interface/Extensible group of classes.
> >
> >BaseController --> Controller
> >
> >and
> >
> >BaseController --> BatchController
> 
> I know this is a bit late since Nick has already done his refactoring, but 
> I didn't realize until now that this discussion is close to one of my own 
> interests, and I wanted to express that interest and see if anyone has a 
> quick answer as to whether the new refactoring works for this.
> 
> We have an interest in constructing simulations in which many Repast 
> simulations will be parts, but not all, of the simulation. At its simplest, 
> imagine a piece of code sitting on top of a bunch of Repast simulations, 
> acting as the master that tells the individual simulations when it is their 
> turn to execute, for how long, that sort of thing.
> 
> Conceptually, this appears to clearly be a job of a "Controller", in the 
> sense of a well-defined interface, that is, the "master" would want to have 
> access to a "Controller" for each simulation. But there are some 
> differences, I think, between the main two imagined uses of controllers so 
> far. This isn't a batch controller exploring a parameter space that wants 
> to run a simulation all the way to the end and then start up a new one. Nor 
> am I going to be controlling the simulations "asynchronously" via user 
> intervention in a GUI. I want to switch back and forth between simulations 
> with very tight control of how long they simulate.
> 
> I'm still looking at the API documentation that I'm sure existed before 
> this refactoring but it wasn't obvious to me that this would be easy at 
> least given the current documentation. The BaseController functionality 
> seems to be based on a notion that the controller and the simulation itself 
> are pretty asynchronous (the simulation being a different thread), but I 
> wanted tighter control than that, for example to tell a simulation to run X 
> ticks and then return control to the controller.
> 
> In your opinion, will this fit fairly naturally into the refactoring of the 
> controller hierarchy, and by what suggested mechanism?
> 
> I'm interested at a conceptual level whether you Repast developers see a 
> distinction, which is driving this, in the following: we are interested in 
> a "recursion" in which agents themselves may be entire agent-based 
> simulations. I contrast this with what *appears* to me to be the recursion 
> generally allowed for in Swarm/Repast, in which an agent may in fact be a 
> "collection of agents" (correction: I went ahead and looked at Swarm, and 
> they at least discuss this more complicated case in their 
> documentation...). In my opinion, the latter is a "much simpler" subset 
> (perhaps) of the former. In the latter, essentially every agent in the 
> collective agent is merely "doing the same thing". In the former notion, 
> however, you actually need an entire "sub simulation" inside of your agent, 
> the internal agents interact, you need an internal schedule, etc.
> 
> 
> 
> >Option 2:
> >
> >In which case something like this might be better:
> >
> >*Interface Controller*
> >         public void startSim()
> >         public void pauseSim()
> >         public void stopSim()
> >         public void pauseSim()
> >         public void exitSim()
> >         public void get/setModel()
> >         public void get/setSchedule()
> >         public void addSimEventListener(SimEventListener l)
> >         public void removeSimEventListener(SimEventListener l)
> >
> >*BasicController implements Controller*
> >
> >The implementaion of the basic functionality to control the sim. This can 
> >be used to control the sim programatically.
> 
> Right, this is what I am looking for: to control the sim programatically.
> 
> Cheers,
> Andy
> ============================================
> Andrew J. Cleary, Software Engineer/Computational Scientist
> Lawrence Livermore National Labs, 925-424-5890.
> ============================================
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Repast-interest mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-interest
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Re: [Repast-interest] BaseController, Controller and BatchController (and Jelly)

[Laszlo G. <gu...@la...>]

Hi,

As far as I can tell, the concept of sub-swarms (in Swarm and hopefully, in 
Repast in the future)
is exactly what you have in mind. It's intended to be more than just a 
simple collection of agents.
In any case, it is definitely NOT the agents doing the same thing. The 
sub-swarm has its own
schedule, the agents interact, etc.

My 2 cents.

Gulya

At 12:23 PM 12/15/2002 -0800, Andy Cleary wrote:
[...]
I'm interested at a conceptual level whether you Repast developers see a 
distinction, which is driving this, in the following: we are interested in 
a "recursion" in which agents themselves may be entire agent-based 
simulations. I contrast this with what *appears* to me to be the recursion 
generally allowed for in Swarm/Repast, in which an agent may in fact be a 
"collection of agents" (correction: I went ahead and looked at Swarm, and 
they at least discuss this more complicated case in their 
documentation...). In my opinion, the latter is a "much simpler" subset 
(perhaps) of the former. In the latter, essentially every agent in the 
collective agent is merely "doing the same thing". In the former notion, 
however, you actually need an entire "sub simulation" inside of your agent, 
the internal agents interact, you need an internal schedule, etc.

RE: [Repast-developer] Controller hierarchy

[Andy C. <ac...@ll...>]

At 12:52 PM 12/13/2002 -0500, Nick Collier wrote:
>Hi,
>
>
>I agree, that is my head tells me, that #1 would be more useful given
>our current user base. As for which would be "cooler" to work on, I'd
>have to go with #2.

[snipped: #1 discussed "embarrassingly parallel" ABM, while #2 was a 
"massively parallel" ABM]

An FYI: my group at Livermore has a modest amount of funding to develop #2 
(not necessarily for Repast but for "entity based simulation" in general) 
that started in October (which is why I am just beginning to show up on 
this list)... I've had a preliminary discussion with Mike North about this. 
I think we are all in agreement that the uses for #2 are probably much more 
specialized than #1, but to be perfectly frank, I wouldn't have gotten 
funding except for #2 because our lab is generally interested in "macho 
computing" which is #2, and that's where most of our expertise lies.

At this point, we've settled on working with Repast for our initial work, 
though it's still a little unclear exactly what form we will ultimately 
deliver it (there are some legitimate if unfortunate language concerns when 
one talks about the big parallel supercomputers: if Java is a choice at 
all, it may not always be a very maintained choice, there are no parallel 
debuggers, parallel java code generally requires nonstandard layers like 
JavaMPI that may not be all that bulletproof, etc). I'd certainly like to 
hold on to the idea of being able to do it in a form that would be 
relatively easy to plug into Repast as long as I can, though.

Anyways, the point is that we'd be glad to trade notes or ideas on this 
topic with any of you who have spent some time thinking along these lines...

p.s. Is this a good place to solicit potential applicants for positions, 
particularly postdocs, in this area? We don't have money yet but I am 
hopeful, and my first choice would be to bring in someone with direct R&D 
experience in this field... So I'd like to ask those with students in the 
field first...

Best,
Andy
============================================
Andrew J. Cleary, Software Engineer/Computational Scientist
Lawrence Livermore National Labs, 925-424-5890.
============================================

[Repast-developer] Re: [Repast-interest] BaseController, Controller and BatchController (and Jelly)

[Andy C. <ac...@ll...>]

[My take on this seemed more appropriate to repast-developer than 
repast-interest, so I've cross posted it...]

At 01:35 PM 12/8/2002 -0500, Mark R. Diggory wrote:
>Hi all,
>
>I'm trying to do some development that involves using the Jelly/Ant 
>scripting env (Apache Jakarta Commons) to build and execute my simulation 
>in batch processes. Where before I was just execing my model as a Java 
>Runnable using Ant's Java Task, now I am actaully trying to instantiate 
>the model class and controller from within Jelly Tags. (Analogous to "JSP 
>tags in JSP/Servlets" or "Ant tasks in Ant".  Jelly is a really powerfull 
>XML based scripting environment that can be extended with other scripting 
>languages (java,javascript,jpython...).
>
>http://jakarta.apache.org/commons/sandbox/jelly/
>
>I'm finding that the Controller class hierarchy is a little hard to work 
>with as an Interface/Extensible group of classes.
>
>BaseController --> Controller
>
>and
>
>BaseController --> BatchController

I know this is a bit late since Nick has already done his refactoring, but 
I didn't realize until now that this discussion is close to one of my own 
interests, and I wanted to express that interest and see if anyone has a 
quick answer as to whether the new refactoring works for this.

We have an interest in constructing simulations in which many Repast 
simulations will be parts, but not all, of the simulation. At its simplest, 
imagine a piece of code sitting on top of a bunch of Repast simulations, 
acting as the master that tells the individual simulations when it is their 
turn to execute, for how long, that sort of thing.

Conceptually, this appears to clearly be a job of a "Controller", in the 
sense of a well-defined interface, that is, the "master" would want to have 
access to a "Controller" for each simulation. But there are some 
differences, I think, between the main two imagined uses of controllers so 
far. This isn't a batch controller exploring a parameter space that wants 
to run a simulation all the way to the end and then start up a new one. Nor 
am I going to be controlling the simulations "asynchronously" via user 
intervention in a GUI. I want to switch back and forth between simulations 
with very tight control of how long they simulate.

I'm still looking at the API documentation that I'm sure existed before 
this refactoring but it wasn't obvious to me that this would be easy at 
least given the current documentation. The BaseController functionality 
seems to be based on a notion that the controller and the simulation itself 
are pretty asynchronous (the simulation being a different thread), but I 
wanted tighter control than that, for example to tell a simulation to run X 
ticks and then return control to the controller.

In your opinion, will this fit fairly naturally into the refactoring of the 
controller hierarchy, and by what suggested mechanism?

I'm interested at a conceptual level whether you Repast developers see a 
distinction, which is driving this, in the following: we are interested in 
a "recursion" in which agents themselves may be entire agent-based 
simulations. I contrast this with what *appears* to me to be the recursion 
generally allowed for in Swarm/Repast, in which an agent may in fact be a 
"collection of agents" (correction: I went ahead and looked at Swarm, and 
they at least discuss this more complicated case in their 
documentation...). In my opinion, the latter is a "much simpler" subset 
(perhaps) of the former. In the latter, essentially every agent in the 
collective agent is merely "doing the same thing". In the former notion, 
however, you actually need an entire "sub simulation" inside of your agent, 
the internal agents interact, you need an internal schedule, etc.



>Option 2:
>
>In which case something like this might be better:
>
>*Interface Controller*
>         public void startSim()
>         public void pauseSim()
>         public void stopSim()
>         public void pauseSim()
>         public void exitSim()
>         public void get/setModel()
>         public void get/setSchedule()
>         public void addSimEventListener(SimEventListener l)
>         public void removeSimEventListener(SimEventListener l)
>
>*BasicController implements Controller*
>
>The implementaion of the basic functionality to control the sim. This can 
>be used to control the sim programatically.

Right, this is what I am looking for: to control the sim programatically.

Cheers,
Andy
============================================
Andrew J. Cleary, Software Engineer/Computational Scientist
Lawrence Livermore National Labs, 925-424-5890.
============================================

RE: [Repast-developer] Controller hierarchy

[Nick C. <nic...@ve...>]

Hi,

That's great! When exactly do you leave? I feel like we should have a
party for you, but not being anywhere near each other that might not
work too well :). 

I agree, that is my head tells me, that #1 would be more useful given
our current user base. As for which would be "cooler" to work on, I'd
have to go with #2.

nick 

On Fri, 2002-12-13 at 12:38, Laszlo Gulyas wrote:
> Hi,
> 
> Thanks for the clarifying notes. While I think both goals seem
> worth pursuing, I was more like thinking about item #1.
> Now that I come to think about it, I have a CS undergraduate
> I advise back in Hungary, who already put a simple, but modular,
> Condor-like framework together in Java. I might redirect him
> to hook it up with Repast.
> 
> This is in addition to another CS undergrad. who has agreed
> to work on 'something for Repast'. Maybe, the two of them
> could round up nicely what Tom has in mind....
> 
> I'll talk to them in January and get back to you!
> 
> Gulya
> 
> At 10:27 AM 12/13/2002 -0500, Nick Collier wrote:
> >I also want to say that we have two goals with respect to distributed
> >simulation.
> >
> >1. Do multiple batch runs on multiple computers from a single computer,
> >collecting the data on that single computer. The idea here is to split
> >the parameter space into pieces and explore these spaces individually on
> >individual computers. This can be started and controlled from a single
> >computer and the results should be recorded on that computer. Of course,
> >something like this can already be done with Drone or Drone-like
> >toolkits. However, our target hardware here is something like a
> >computing lab full of win2K machines that are otherwise idle over night,
> >or 4 or 5 scrounged and freely available windows boxes.
> >
> >This is not that difficult and shouldn't require a parallel distributed
> >scheduler.
> >
> >2. Spread a single simulation run over multiple computers. This is more
> >traditional distributed parallel computing and would require a
> >distributed parallel scheduler.
> >
> >I'm not sure where we've decided to place our focus w/r to these two
> >goals, although I know my heart and my head are divided here!
> >
> >Nick
> >
> >On Fri, 2002-12-13 at 10:09, Nick Collier wrote:
> > > Hi all,
> > >
> > > I think there's a bit of confusion here. What's included in repast 2.0
> > > is not Mike's FAST framework (a framework for distributed repast -- more
> > > or less -- simulations) but rather code that enables the true
> > > parallelization of scheduled actions. The intention is that expensive or
> > > long running actions can be scheduled to run in parallel with typical
> > > sequential scheduled actions.
> > >
> > > Maybe Mike can say more about the relationship of something like FAST to
> > > these new parallel actions.
> > >
> > > Anyway, my point is that repast 2.0 doesn't give you framework for fully
> > > distributed parallel simulations out of the box. We are pursuing
> > > something like this, however. Tom has looked into Globus, Condor and
> > > lately ProActive  (http://www-sop.inria.fr/oasis/ProActive/) in this
> > > context. I think it will be a priority for him once he gets the current
> > > round of GIS code sorted. Maybe he can say more, although I know he's
> > > away for a few days at the moment.
> > >
> > > Nick
> > >
> > > On Fri, 2002-12-13 at 09:55, Frank Blecha wrote:
> > > >
> > > > I'm also curious as to the inclusion of that feature. - Frank
> > > >
> > > > On Thu, 12 Dec 2002, Scholand, Andrew J wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Work in this vein is often termed 'embarrassingly parallel' or 
> > parametric
> > > > > computing - see for example NimRod/G,
> > > > > http://www.globus.org/research/applications/nimrod.html.  Might be 
> > a good
> > > > > tie in with Mike North's parallelized RePast engines, which I 
> > believe will
> > > > > be in 2.0?
> > > > >
> > > > > Cheers,
> > > > > Andy
> > > > >
> > > > > -----Original Message-----
> > > > > From: Skye Bender-deMoll
> > > > > To: rep...@li...; nic...@ve...
> > > > > Sent: 12/12/2002 1:11 PM
> > > > > Subject: Re: [Repast-developer] Controller hierarchy
> > > > >
> > > > >
> > > > > Hi nick, and folks,
> > > > >    Was just remembering a conversation we had a long time ago about
> > > > > the idea of a ParameterSpaceExplorer, which seems relevant to the
> > > > > controller discussion.
> > > > >
> > > > > Crudely, the idea is pretty much the same as doing runs from a batch
> > > > > file, but the batch file has a GUI and data presentation of its
> > > > > results.  So after someone has finished coding a model, and wants to
> > > > > explore "results" over a particular range of parameters, they could
> > > > > load the ParameterSpaceExplorer, enter the range, parameter sampling
> > > > > density, and number of repetitions per point, and come back in a
> > > > > couple of hours to a nicely collected data set.  Of course this
> > > > > requires that models have well defined stopping conditions (or a set
> > > > > number of steps), and report clear numeric results of some kinds.
> > > > >
> > > > > In the (rare) case where there are two main input parameters of
> > > > > interest, and one result parameter, we could have nice 2.5D plots of
> > > > > results, or if multiple result params, allow switching between result
> > > > > plots...    Could also calc "pseduo"-error ranges and stdv.   Then
> > > > > the user can say, "hmm, what's this discontinuity on the graph, is it
> > > > > just randomness?  lets do another 300 runs, more closely spaced along
> > > > > parameter-x, and see what we get..click click.."
> > > > >
> > > > > Another advantage is that it might help people (us model coders)
> > > > > focus their (our) thinking on "OK, what are my inputs, and what are
> > > > > my results, and what does it mean" instead of just, "WOW! isn't that
> > > > > pretty!"  I don't by any means mean to dis good graphical
> > > > > representations of a sim, as I think they are incredibly important,
> > > > > but I think it is also good to help formulate a "question" and
> > > > > "results" approach as well.
> > > > >
> > > > > I know it is better to do things than suggest them, but I've got all
> > > > > the java I can handle at the moment with this network stuff.  But I
> > > > > thought I'd throw the idea out there again, just in case coordination
> > > > > between DataSource, DataRecorder, and the Controller interface might
> > > > > be useful or necessary in the future...
> > > > >
> > > > > cheers,
> > > > >    -skye
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:
> > > > > With Great Power, Comes Great Responsibility
> > > > > Learn to use your power at OSDN's High Performance Computing Channel
> > > > > http://hpc.devchannel.org/
> > > > > _______________________________________________
> > > > > Repast-developer mailing list
> > > > > Rep...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/repast-developer
> > > > >
> > > >
> > > --
> > > Nick Collier
> > > Social Science Research Computing
> > > University of Chicago
> > > http://repast.sourceforge.net
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:
> > > With Great Power, Comes Great Responsibility
> > > Learn to use your power at OSDN's High Performance Computing Channel
> > > http://hpc.devchannel.org/
> > > _______________________________________________
> > > Repast-developer mailing list
> > > Rep...@li...
> > > https://lists.sourceforge.net/lists/listinfo/repast-developer
> >--
> >Nick Collier
> >Social Science Research Computing
> >University of Chicago
> >http://repast.sourceforge.net
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:
> >With Great Power, Comes Great Responsibility
> >Learn to use your power at OSDN's High Performance Computing Channel
> >http://hpc.devchannel.org/
> >_______________________________________________
> >Repast-developer mailing list
> >Rep...@li...
> >https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

RE: [Repast-developer] Controller hierarchy

[Laszlo G. <gu...@la...>]

Hi,

Thanks for the clarifying notes. While I think both goals seem
worth pursuing, I was more like thinking about item #1.
Now that I come to think about it, I have a CS undergraduate
I advise back in Hungary, who already put a simple, but modular,
Condor-like framework together in Java. I might redirect him
to hook it up with Repast.

This is in addition to another CS undergrad. who has agreed
to work on 'something for Repast'. Maybe, the two of them
could round up nicely what Tom has in mind....

I'll talk to them in January and get back to you!

Gulya

At 10:27 AM 12/13/2002 -0500, Nick Collier wrote:
>I also want to say that we have two goals with respect to distributed
>simulation.
>
>1. Do multiple batch runs on multiple computers from a single computer,
>collecting the data on that single computer. The idea here is to split
>the parameter space into pieces and explore these spaces individually on
>individual computers. This can be started and controlled from a single
>computer and the results should be recorded on that computer. Of course,
>something like this can already be done with Drone or Drone-like
>toolkits. However, our target hardware here is something like a
>computing lab full of win2K machines that are otherwise idle over night,
>or 4 or 5 scrounged and freely available windows boxes.
>
>This is not that difficult and shouldn't require a parallel distributed
>scheduler.
>
>2. Spread a single simulation run over multiple computers. This is more
>traditional distributed parallel computing and would require a
>distributed parallel scheduler.
>
>I'm not sure where we've decided to place our focus w/r to these two
>goals, although I know my heart and my head are divided here!
>
>Nick
>
>On Fri, 2002-12-13 at 10:09, Nick Collier wrote:
> > Hi all,
> >
> > I think there's a bit of confusion here. What's included in repast 2.0
> > is not Mike's FAST framework (a framework for distributed repast -- more
> > or less -- simulations) but rather code that enables the true
> > parallelization of scheduled actions. The intention is that expensive or
> > long running actions can be scheduled to run in parallel with typical
> > sequential scheduled actions.
> >
> > Maybe Mike can say more about the relationship of something like FAST to
> > these new parallel actions.
> >
> > Anyway, my point is that repast 2.0 doesn't give you framework for fully
> > distributed parallel simulations out of the box. We are pursuing
> > something like this, however. Tom has looked into Globus, Condor and
> > lately ProActive  (http://www-sop.inria.fr/oasis/ProActive/) in this
> > context. I think it will be a priority for him once he gets the current
> > round of GIS code sorted. Maybe he can say more, although I know he's
> > away for a few days at the moment.
> >
> > Nick
> >
> > On Fri, 2002-12-13 at 09:55, Frank Blecha wrote:
> > >
> > > I'm also curious as to the inclusion of that feature. - Frank
> > >
> > > On Thu, 12 Dec 2002, Scholand, Andrew J wrote:
> > >
> > > > Hi,
> > > >
> > > > Work in this vein is often termed 'embarrassingly parallel' or 
> parametric
> > > > computing - see for example NimRod/G,
> > > > http://www.globus.org/research/applications/nimrod.html.  Might be 
> a good
> > > > tie in with Mike North's parallelized RePast engines, which I 
> believe will
> > > > be in 2.0?
> > > >
> > > > Cheers,
> > > > Andy
> > > >
> > > > -----Original Message-----
> > > > From: Skye Bender-deMoll
> > > > To: rep...@li...; nic...@ve...
> > > > Sent: 12/12/2002 1:11 PM
> > > > Subject: Re: [Repast-developer] Controller hierarchy
> > > >
> > > >
> > > > Hi nick, and folks,
> > > >    Was just remembering a conversation we had a long time ago about
> > > > the idea of a ParameterSpaceExplorer, which seems relevant to the
> > > > controller discussion.
> > > >
> > > > Crudely, the idea is pretty much the same as doing runs from a batch
> > > > file, but the batch file has a GUI and data presentation of its
> > > > results.  So after someone has finished coding a model, and wants to
> > > > explore "results" over a particular range of parameters, they could
> > > > load the ParameterSpaceExplorer, enter the range, parameter sampling
> > > > density, and number of repetitions per point, and come back in a
> > > > couple of hours to a nicely collected data set.  Of course this
> > > > requires that models have well defined stopping conditions (or a set
> > > > number of steps), and report clear numeric results of some kinds.
> > > >
> > > > In the (rare) case where there are two main input parameters of
> > > > interest, and one result parameter, we could have nice 2.5D plots of
> > > > results, or if multiple result params, allow switching between result
> > > > plots...    Could also calc "pseduo"-error ranges and stdv.   Then
> > > > the user can say, "hmm, what's this discontinuity on the graph, is it
> > > > just randomness?  lets do another 300 runs, more closely spaced along
> > > > parameter-x, and see what we get..click click.."
> > > >
> > > > Another advantage is that it might help people (us model coders)
> > > > focus their (our) thinking on "OK, what are my inputs, and what are
> > > > my results, and what does it mean" instead of just, "WOW! isn't that
> > > > pretty!"  I don't by any means mean to dis good graphical
> > > > representations of a sim, as I think they are incredibly important,
> > > > but I think it is also good to help formulate a "question" and
> > > > "results" approach as well.
> > > >
> > > > I know it is better to do things than suggest them, but I've got all
> > > > the java I can handle at the moment with this network stuff.  But I
> > > > thought I'd throw the idea out there again, just in case coordination
> > > > between DataSource, DataRecorder, and the Controller interface might
> > > > be useful or necessary in the future...
> > > >
> > > > cheers,
> > > >    -skye
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:
> > > > With Great Power, Comes Great Responsibility
> > > > Learn to use your power at OSDN's High Performance Computing Channel
> > > > http://hpc.devchannel.org/
> > > > _______________________________________________
> > > > Repast-developer mailing list
> > > > Rep...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/repast-developer
> > > >
> > >
> > --
> > Nick Collier
> > Social Science Research Computing
> > University of Chicago
> > http://repast.sourceforge.net
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Repast-developer mailing list
> > Rep...@li...
> > https://lists.sourceforge.net/lists/listinfo/repast-developer
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:
>With Great Power, Comes Great Responsibility
>Learn to use your power at OSDN's High Performance Computing Channel
>http://hpc.devchannel.org/
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer

RE: [Repast-developer] Controller hierarchy

[Nick C. <nic...@ve...>]

I also want to say that we have two goals with respect to distributed
simulation. 

1. Do multiple batch runs on multiple computers from a single computer,
collecting the data on that single computer. The idea here is to split
the parameter space into pieces and explore these spaces individually on
individual computers. This can be started and controlled from a single
computer and the results should be recorded on that computer. Of course,
something like this can already be done with Drone or Drone-like
toolkits. However, our target hardware here is something like a
computing lab full of win2K machines that are otherwise idle over night,
or 4 or 5 scrounged and freely available windows boxes.

This is not that difficult and shouldn't require a parallel distributed
scheduler.

2. Spread a single simulation run over multiple computers. This is more
traditional distributed parallel computing and would require a
distributed parallel scheduler. 

I'm not sure where we've decided to place our focus w/r to these two
goals, although I know my heart and my head are divided here!

Nick

On Fri, 2002-12-13 at 10:09, Nick Collier wrote:
> Hi all, 
> 
> I think there's a bit of confusion here. What's included in repast 2.0
> is not Mike's FAST framework (a framework for distributed repast -- more
> or less -- simulations) but rather code that enables the true
> parallelization of scheduled actions. The intention is that expensive or
> long running actions can be scheduled to run in parallel with typical
> sequential scheduled actions. 
> 
> Maybe Mike can say more about the relationship of something like FAST to
> these new parallel actions.
> 
> Anyway, my point is that repast 2.0 doesn't give you framework for fully
> distributed parallel simulations out of the box. We are pursuing 
> something like this, however. Tom has looked into Globus, Condor and
> lately ProActive  (http://www-sop.inria.fr/oasis/ProActive/) in this
> context. I think it will be a priority for him once he gets the current
> round of GIS code sorted. Maybe he can say more, although I know he's
> away for a few days at the moment.
> 
> Nick
> 
> On Fri, 2002-12-13 at 09:55, Frank Blecha wrote:
> > 
> > I'm also curious as to the inclusion of that feature. - Frank
> > 
> > On Thu, 12 Dec 2002, Scholand, Andrew J wrote:
> > 
> > > Hi,
> > > 
> > > Work in this vein is often termed 'embarrassingly parallel' or parametric
> > > computing - see for example NimRod/G,
> > > http://www.globus.org/research/applications/nimrod.html.  Might be a good
> > > tie in with Mike North's parallelized RePast engines, which I believe will
> > > be in 2.0? 
> > > 
> > > Cheers,
> > > Andy
> > > 
> > > -----Original Message-----
> > > From: Skye Bender-deMoll
> > > To: rep...@li...; nic...@ve...
> > > Sent: 12/12/2002 1:11 PM
> > > Subject: Re: [Repast-developer] Controller hierarchy
> > > 
> > > 
> > > Hi nick, and folks,
> > >    Was just remembering a conversation we had a long time ago about 
> > > the idea of a ParameterSpaceExplorer, which seems relevant to the 
> > > controller discussion.
> > > 
> > > Crudely, the idea is pretty much the same as doing runs from a batch 
> > > file, but the batch file has a GUI and data presentation of its 
> > > results.  So after someone has finished coding a model, and wants to 
> > > explore "results" over a particular range of parameters, they could 
> > > load the ParameterSpaceExplorer, enter the range, parameter sampling 
> > > density, and number of repetitions per point, and come back in a 
> > > couple of hours to a nicely collected data set.  Of course this 
> > > requires that models have well defined stopping conditions (or a set 
> > > number of steps), and report clear numeric results of some kinds.
> > > 
> > > In the (rare) case where there are two main input parameters of 
> > > interest, and one result parameter, we could have nice 2.5D plots of 
> > > results, or if multiple result params, allow switching between result 
> > > plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
> > > the user can say, "hmm, what's this discontinuity on the graph, is it 
> > > just randomness?  lets do another 300 runs, more closely spaced along 
> > > parameter-x, and see what we get..click click.."
> > > 
> > > Another advantage is that it might help people (us model coders) 
> > > focus their (our) thinking on "OK, what are my inputs, and what are 
> > > my results, and what does it mean" instead of just, "WOW! isn't that 
> > > pretty!"  I don't by any means mean to dis good graphical 
> > > representations of a sim, as I think they are incredibly important, 
> > > but I think it is also good to help formulate a "question" and 
> > > "results" approach as well.
> > > 
> > > I know it is better to do things than suggest them, but I've got all 
> > > the java I can handle at the moment with this network stuff.  But I 
> > > thought I'd throw the idea out there again, just in case coordination 
> > > between DataSource, DataRecorder, and the Controller interface might 
> > > be useful or necessary in the future...
> > > 
> > > cheers,
> > >    -skye
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:
> > > With Great Power, Comes Great Responsibility 
> > > Learn to use your power at OSDN's High Performance Computing Channel
> > > http://hpc.devchannel.org/
> > > _______________________________________________
> > > Repast-developer mailing list
> > > Rep...@li...
> > > https://lists.sourceforge.net/lists/listinfo/repast-developer
> > > 
> > 
> -- 
> Nick Collier 
> Social Science Research Computing 
> University of Chicago 
> http://repast.sourceforge.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

RE: [Repast-developer] Controller hierarchy

[Nick C. <nic...@ve...>]

Hi all, 

I think there's a bit of confusion here. What's included in repast 2.0
is not Mike's FAST framework (a framework for distributed repast -- more
or less -- simulations) but rather code that enables the true
parallelization of scheduled actions. The intention is that expensive or
long running actions can be scheduled to run in parallel with typical
sequential scheduled actions. 

Maybe Mike can say more about the relationship of something like FAST to
these new parallel actions.

Anyway, my point is that repast 2.0 doesn't give you framework for fully
distributed parallel simulations out of the box. We are pursuing 
something like this, however. Tom has looked into Globus, Condor and
lately ProActive  (http://www-sop.inria.fr/oasis/ProActive/) in this
context. I think it will be a priority for him once he gets the current
round of GIS code sorted. Maybe he can say more, although I know he's
away for a few days at the moment.

Nick

On Fri, 2002-12-13 at 09:55, Frank Blecha wrote:
> 
> I'm also curious as to the inclusion of that feature. - Frank
> 
> On Thu, 12 Dec 2002, Scholand, Andrew J wrote:
> 
> > Hi,
> > 
> > Work in this vein is often termed 'embarrassingly parallel' or parametric
> > computing - see for example NimRod/G,
> > http://www.globus.org/research/applications/nimrod.html.  Might be a good
> > tie in with Mike North's parallelized RePast engines, which I believe will
> > be in 2.0? 
> > 
> > Cheers,
> > Andy
> > 
> > -----Original Message-----
> > From: Skye Bender-deMoll
> > To: rep...@li...; nic...@ve...
> > Sent: 12/12/2002 1:11 PM
> > Subject: Re: [Repast-developer] Controller hierarchy
> > 
> > 
> > Hi nick, and folks,
> >    Was just remembering a conversation we had a long time ago about 
> > the idea of a ParameterSpaceExplorer, which seems relevant to the 
> > controller discussion.
> > 
> > Crudely, the idea is pretty much the same as doing runs from a batch 
> > file, but the batch file has a GUI and data presentation of its 
> > results.  So after someone has finished coding a model, and wants to 
> > explore "results" over a particular range of parameters, they could 
> > load the ParameterSpaceExplorer, enter the range, parameter sampling 
> > density, and number of repetitions per point, and come back in a 
> > couple of hours to a nicely collected data set.  Of course this 
> > requires that models have well defined stopping conditions (or a set 
> > number of steps), and report clear numeric results of some kinds.
> > 
> > In the (rare) case where there are two main input parameters of 
> > interest, and one result parameter, we could have nice 2.5D plots of 
> > results, or if multiple result params, allow switching between result 
> > plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
> > the user can say, "hmm, what's this discontinuity on the graph, is it 
> > just randomness?  lets do another 300 runs, more closely spaced along 
> > parameter-x, and see what we get..click click.."
> > 
> > Another advantage is that it might help people (us model coders) 
> > focus their (our) thinking on "OK, what are my inputs, and what are 
> > my results, and what does it mean" instead of just, "WOW! isn't that 
> > pretty!"  I don't by any means mean to dis good graphical 
> > representations of a sim, as I think they are incredibly important, 
> > but I think it is also good to help formulate a "question" and 
> > "results" approach as well.
> > 
> > I know it is better to do things than suggest them, but I've got all 
> > the java I can handle at the moment with this network stuff.  But I 
> > thought I'd throw the idea out there again, just in case coordination 
> > between DataSource, DataRecorder, and the Controller interface might 
> > be useful or necessary in the future...
> > 
> > cheers,
> >    -skye
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility 
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Repast-developer mailing list
> > Rep...@li...
> > https://lists.sourceforge.net/lists/listinfo/repast-developer
> > 
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

RE: [Repast-developer] Controller hierarchy

[Frank B. <fb...@bl...>]

I'm also curious as to the inclusion of that feature. - Frank

On Thu, 12 Dec 2002, Scholand, Andrew J wrote:

> Hi,
> 
> Work in this vein is often termed 'embarrassingly parallel' or parametric
> computing - see for example NimRod/G,
> http://www.globus.org/research/applications/nimrod.html.  Might be a good
> tie in with Mike North's parallelized RePast engines, which I believe will
> be in 2.0? 
> 
> Cheers,
> Andy
> 
> -----Original Message-----
> From: Skye Bender-deMoll
> To: rep...@li...; nic...@ve...
> Sent: 12/12/2002 1:11 PM
> Subject: Re: [Repast-developer] Controller hierarchy
> 
> 
> Hi nick, and folks,
>    Was just remembering a conversation we had a long time ago about 
> the idea of a ParameterSpaceExplorer, which seems relevant to the 
> controller discussion.
> 
> Crudely, the idea is pretty much the same as doing runs from a batch 
> file, but the batch file has a GUI and data presentation of its 
> results.  So after someone has finished coding a model, and wants to 
> explore "results" over a particular range of parameters, they could 
> load the ParameterSpaceExplorer, enter the range, parameter sampling 
> density, and number of repetitions per point, and come back in a 
> couple of hours to a nicely collected data set.  Of course this 
> requires that models have well defined stopping conditions (or a set 
> number of steps), and report clear numeric results of some kinds.
> 
> In the (rare) case where there are two main input parameters of 
> interest, and one result parameter, we could have nice 2.5D plots of 
> results, or if multiple result params, allow switching between result 
> plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
> the user can say, "hmm, what's this discontinuity on the graph, is it 
> just randomness?  lets do another 300 runs, more closely spaced along 
> parameter-x, and see what we get..click click.."
> 
> Another advantage is that it might help people (us model coders) 
> focus their (our) thinking on "OK, what are my inputs, and what are 
> my results, and what does it mean" instead of just, "WOW! isn't that 
> pretty!"  I don't by any means mean to dis good graphical 
> representations of a sim, as I think they are incredibly important, 
> but I think it is also good to help formulate a "question" and 
> "results" approach as well.
> 
> I know it is better to do things than suggest them, but I've got all 
> the java I can handle at the moment with this network stuff.  But I 
> thought I'd throw the idea out there again, just in case coordination 
> between DataSource, DataRecorder, and the Controller interface might 
> be useful or necessary in the future...
> 
> cheers,
>    -skye
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
> 

Fwd: Re: [Repast-developer] Controller hierarchy

[Laszlo G. <gu...@la...>]

>Date: Thu, 12 Dec 2002 17:02:02 -0500
>To: Skye Bender-deMoll <sky...@st...>
>From: Laszlo Gulyas <gu...@la...>
>Subject: Re: [Repast-developer] Controller hierarchy
>
>Hi Skye,
>
>Don't you worry, I keep these guys entertained with 'suggesting things
>rather than doing them'...
>
>That said, what you say sounds pretty good to me. In fact, we've been
>aiming at something like this back in the old MAML days (see
>http://jasss.soc.surrey.ac.uk/2/3/8.html). I do think Mike's semi-parallel
>execution environment will help a lot here (FAST or how he calls it), but
>having a nice GUI thrown in front of it would be terrific. I might even try
>to work on it in the future, although I shouldn't really start on anything
>else until cleaning up what I already have half-finished for Repast...
>
>Gulya
>
>
>At 12:11 PM 12/12/2002 -0800, you wrote:
>
>>Hi nick, and folks,
>>   Was just remembering a conversation we had a long time ago about the 
>> idea of a ParameterSpaceExplorer, which seems relevant to the controller 
>> discussion.
>>
>>Crudely, the idea is pretty much the same as doing runs from a batch 
>>file, but the batch file has a GUI and data presentation of its 
>>results.  So after someone has finished coding a model, and wants to 
>>explore "results" over a particular range of parameters, they could load 
>>the ParameterSpaceExplorer, enter the range, parameter sampling density, 
>>and number of repetitions per point, and come back in a couple of hours 
>>to a nicely collected data set.  Of course this requires that models have 
>>well defined stopping conditions (or a set number of steps), and report 
>>clear numeric results of some kinds.
>>
>>In the (rare) case where there are two main input parameters of interest, 
>>and one result parameter, we could have nice 2.5D plots of results, or if 
>>multiple result params, allow switching between result plots...    Could 
>>also calc "pseduo"-error ranges and stdv.   Then the user can say, "hmm, 
>>what's this discontinuity on the graph, is it just randomness?  lets do 
>>another 300 runs, more closely spaced along parameter-x, and see what we 
>>get..click click.."
>>
>>Another advantage is that it might help people (us model coders) focus 
>>their (our) thinking on "OK, what are my inputs, and what are my results, 
>>and what does it mean" instead of just, "WOW! isn't that pretty!"  I 
>>don't by any means mean to dis good graphical representations of a sim, 
>>as I think they are incredibly important, but I think it is also good to 
>>help formulate a "question" and "results" approach as well.
>>
>>I know it is better to do things than suggest them, but I've got all the 
>>java I can handle at the moment with this network stuff.  But I thought 
>>I'd throw the idea out there again, just in case coordination between 
>>DataSource, DataRecorder, and the Controller interface might be useful or 
>>necessary in the future...
>>
>>cheers,
>>   -skye
>>
>>>
>>>I refactored the controller (small c) hierarchy over the last few days.
>>>The point here was to isolate the basic semantics of a controller in an
>>>Interface. This new Interface is IController and the basic semantics
>>>have to do with the execution of a model, starting, stopping etc.
>>>BaseController implements these semantics, and retains backward
>>>compatibility with all its weird little utility methods.
>>>BatchController and AbstractGUIController add different ways of dealing
>>>with parameters and Controller adds an actual GUI (buttons and so forth)
>>>on top of AbstractGUIController. I'd rather do this with wrapping, but
>>>it was easier to preserve backward compatibility w/r to Controller this
>>>way. Wrapping can be revisited later.
>>>
>>>just to keep y'all in the loop,
>>>
>>>Nick
>>>
>>>--
>>>Nick Collier
>>>Social Science Research Computing
>>>University of Chicago
>>>http://repast.sourceforge.net
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This sf.net email is sponsored by:
>>>With Great Power, Comes Great Responsibility
>>>Learn to use your power at OSDN's High Performance Computing Channel
>>>http://hpc.devchannel.org/
>>>_______________________________________________
>>>Repast-developer mailing list
>>>Rep...@li...
>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
>>
>>--
>>--------------------------------
>>Skye's fone/Vmail: 650.853.0679
>>--------------------------------
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:
>>With Great Power, Comes Great Responsibility Learn to use your power at 
>>OSDN's High Performance Computing Channel
>>http://hpc.devchannel.org/
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer

RE: [Repast-developer] Controller hierarchy

[Scholand, A. J <aj...@sa...>]

Hi,

Work in this vein is often termed 'embarrassingly parallel' or parametric
computing - see for example NimRod/G,
http://www.globus.org/research/applications/nimrod.html.  Might be a good
tie in with Mike North's parallelized RePast engines, which I believe will
be in 2.0? 

Cheers,
Andy

-----Original Message-----
From: Skye Bender-deMoll
To: rep...@li...; nic...@ve...
Sent: 12/12/2002 1:11 PM
Subject: Re: [Repast-developer] Controller hierarchy


Hi nick, and folks,
   Was just remembering a conversation we had a long time ago about 
the idea of a ParameterSpaceExplorer, which seems relevant to the 
controller discussion.

Crudely, the idea is pretty much the same as doing runs from a batch 
file, but the batch file has a GUI and data presentation of its 
results.  So after someone has finished coding a model, and wants to 
explore "results" over a particular range of parameters, they could 
load the ParameterSpaceExplorer, enter the range, parameter sampling 
density, and number of repetitions per point, and come back in a 
couple of hours to a nicely collected data set.  Of course this 
requires that models have well defined stopping conditions (or a set 
number of steps), and report clear numeric results of some kinds.

In the (rare) case where there are two main input parameters of 
interest, and one result parameter, we could have nice 2.5D plots of 
results, or if multiple result params, allow switching between result 
plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
the user can say, "hmm, what's this discontinuity on the graph, is it 
just randomness?  lets do another 300 runs, more closely spaced along 
parameter-x, and see what we get..click click.."

Another advantage is that it might help people (us model coders) 
focus their (our) thinking on "OK, what are my inputs, and what are 
my results, and what does it mean" instead of just, "WOW! isn't that 
pretty!"  I don't by any means mean to dis good graphical 
representations of a sim, as I think they are incredibly important, 
but I think it is also good to help formulate a "question" and 
"results" approach as well.

I know it is better to do things than suggest them, but I've got all 
the java I can handle at the moment with this network stuff.  But I 
thought I'd throw the idea out there again, just in case coordination 
between DataSource, DataRecorder, and the Controller interface might 
be useful or necessary in the future...

cheers,
   -skye