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.
============================================