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