repast-developer

Re: [Repast-developer] Topology Notes

[<ge...@te...>]

Thomas R. Howe writes:
 > This has been a concern for both Nick and I and is one reason why
 > we so desparately want to use aspects.

I couldn't find the reference in the email archives.  What do you
mean by "aspects"?

-- 
glen e. p. ropella              =><=                           Hail Eris!
H: 831.335.4950                              http://www.ropella.net/~gepr
M: 831.247.7901                               http://www.tempusdictum.com

Re: [Repast-developer] Topology Notes

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

This is a response to a conversation from quite a while ago on the list.

I've been working on refactoring the space library to give a bit more
coherence and (hopefully) swapability to the various spaces.  


I've been thinking about both the idea to base the space library be
based on metric spaces and also Gulya's idea below about a series of
"relations", which  as you point out are semantically typed edges.

First, I see a problem with conclusion in our previous discussions that
metric spaces can unify the space library.  Metric spaces only apply to
symmetric relationships, d(x,y) == d(y,x).  The network library has
complete support for asymmetric relationships: d(x,y) != d(y,x) or
d(y,x) == null.  In fact this is the most general case.  Symmetric
networks are the special case (albeit a rather substantial one). So it
seems that, at least for that part of the space library, metrics don't
apply.  Now it seems totally reasonable to unify, at least, all of the
grid type spaces, and perhaps even symmetric networks, using the metric
approach.

Gulya, Nick and I were talking about the relation stuff you came up with
yesterday.  That is a super neat way to unify the network stuff with the
spatial stuff.  I have some concerns, (I'm sure you can guess what they
are).  The first is performance, both memory and computation.  If there
is a large grid, the set of edges created by a Moore neighborhood will
be huge.  Computationally, I'm concerned about the update method in the
contexts.  If agents are moving, and constantly changing their
neighborhoods, the update method (where relations are updated) will be
extremely expensive.  My second concern is that all agents will have to
extend some base class (DefaultNode, RelNode, etc.).  This eliminates
some of the flexibility people could use to extend other classes.  This
has been a concern for both Nick and I and is one reason why we so
desparately want to use aspects.  The third concern I have has to do
with the Range operator.  I guess this falls under computational
expense, but it is a little different.  If someone needs to do a range
query, the agent would need to find the shortest path to each of the
other objects.  That would be prohibitively expensive.
I wonder, do you have any thoughts on how to get around this problem?  I
really like the design because it contains so much semantic information
and unify spatial models and network models.

Those are my thoughts at the moment.  Clearly, I haven't come to a
conclusion yet, so please anyone comment.  If you want to see the issues
I'm talking about there is a series of postings in the mailing list
called "Topology Notes".  They outline all of the things we've been
discussing.  Also, if anyone else has ideas on how to make spaces more
"switchable", please suggest.

BTW, If you've made it all the way through this epic email, I'm very
impressed.

-Tom


On Thu, 2002-11-21 at 22:52, Laszlo Gulyas wrote:
> Hi Guys,
> 
> I'm sorry for taking so long reacting, but there's so many things
> going on right now. (Not excluding selling the furniture and the car
> in preparation to moving back to Europe.) So, my schedule was and
> is a bit hectic. Fortunately, though, both Anita (my wife) and I have 
> saved up some days off, so we're gonna take off for a last vacation 
> soon. Hopefully, I get back for the last couple of days much more 
> relaxed/productive...
> 
> However, I wanted to get back to you on this before that happens.
> I think, Mike has summarized our discussion rather well. The only
> thing remained to say is about displaying these things. In principle,
> the Drawable interface works well: it basically maps an agent into
> a 2D coordinate system, plus provides a way for it to draw itself.
> This should be general enough.
> 
> Except that it kind of makes it hard for an agent to participate in
> several [switchable] 'spaces' or to display itself on different
> displays 
> of the same [possibly N-dimensional] space. Now, I don't necessarily 
> think that it is time now [just before 2.0] to blow up the whole gui
> package.
> However, I've been doing some experimentation and created my
> own ContextMapping (well, I call them contexts, but they are, kind
> of, generalized topologies) interface whose methods take an agent and
> - map it into an (X,Y) /screen/ coordinate,
> - return its Dimension,
> - draw it on the screen.
> 
> I just thought I'd share this with you. (See the attachment.) 
> Please, do not look at its performance yet! On the other hand,
> it's kind of complex, so I won't blame you not want to start
> with it right now.
> 
> - - - - - 
> 
> OK. In this model, I've taken the 'space/topology' issue a step 
> further. (?) [Don't think I'm suggesting you should start implementing
> any of this. Rather, I just want to share my crazy visions with you.]
> 
> Now I think that the bottom line of all these 'space/topology'
> issues is the concept of a Relation. It is really nothing else, but an
> Edge 
> on a network, so one nice thing about this approach is that it
> provides 
> a natural way to unify the 'grid-based' and the network models.
> 
> OK, so I call them relations, not Edges, what's the difference?
> Technically, my implementation is nothing more than providing
> ways to sort out edges according to their types. This way, I have
> general methods to say, "Give me the related nodes according to 
> relation R", R being a parameter.
> 
> My 'contexts' create and update the relations and all the Model/Agent 
> do is to query and use them, via these general methods. This way, by 
> replacing the context, you can place the agents into vastly different 
> environments, as long as they all define the same relations.
> 
> From this point of view, the topologies/spaces just define special,
> perhaps
> parametrized [with distance] 'neighborhood' or 'close-to' relations.
> Storing
> the agents on a grid internally is just an efficient way of
> implementing this.
> (Naturally, it is debatable whether the relations/edges define special
> kinds
> of topologies, or the other way around, but this time, I just went
> with the
> latter option.)
> 
> Well, let me know what do you think. Note, however, that I'll be out
> of
> town till December 3. So, don't get mad at me if I won't answer them
> immediately. (Well, that's kind of usual from me, sadly enough.)
> 
> Take care!
> 
> Gulya
> 
> PS: I can't resist to put this in here: as a long shot off the
> 'relation burble':
> this could, in fact, finally lead to the 'DB-based' simulation I've
> been
> 'visioning' for a while. I mean, if relations are a central concept in
> the
> architecture, and the model's and the agents' logic is formulated
> according
> to this, it could be possible to actually implement them by storing
> them
> in a relational DB. Then, in principle, one could do cool stuff, like 
> defining 'dynamic relationships' via joints, or creating triggers,
> etc.
> I'm not sure if it's necessarily more efficient, but wouldn't it be
> cool?! ;-) 
> [Enough of me now! :-)]
> 
> At 07:15 PM 11/15/2002 -0600, North, Michael wrote:
> 
> > Tom:
> > 
> >  
> > 
> > The topology issues that we discussed might be represented as
> > follows:
> > 
> >  
> > 
> > 1.)   An abstract Topology class or interface can be defined:
> > 
> > a.      The class has a method, getDistance(Object o1, Object o2),
> > that returns the distance between any two objects.
> > 
> > b.     The Topology class has appropriate methods to get neighbors
> > within a certain range such as getNeighbors(Object o1, double range)
> > .
> > 
> > 2.)   Three or more concrete Topology implementation classes can
> > then be defined:
> > 
> > a.      An implementation for Moore neighborhoods, von Neumann
> > neighborhoods, and hexagonal neighborhoods based on the current grid
> > implementation can be defined.  This would use the current
> > array-based grid storage and maintain backward compatibility.  Since
> > it is essentially the current implementation, it would run as fast
> > as the current code.
> > 
> > b.     An implementation for metric spaces can be defined that uses
> > trees to store objects and find neighbors.  This can be done since
> > the rules of a metric space allow tree storage.  For example see
> > http://www.vldb.org/conf/1997/P426.PDF.  Other implementations are
> > also available, especially for large lists.  For example, see
> > http://portal.acm.org/citation.cfm?id=328959&dl=ACM&coll=portal. 
> > This implementation would run slower than the current code but it
> > would still be reasonable for most problems.  The price of slower
> > execution is made up for by the added flexibility.
> > 
> > c.      An implementation for completely abstract (i.e. non-metric)
> > spaces can be defined that uses a simple list to store objects and a
> > naïve all pairs matching algorithm to find neighbors.  The algorithm
> > will simply test the distance between each object to find
> > neighbors.  This implementation will be much slower than the current
> > code for large lists but the slower execution will be made up for by
> > the increased flexibility, at least for initial testing.  Users that
> > find they need a particularly abstract notion of space are free to
> > develop optimized versions of the Topology class as they see fit.
> > 
> > 3.)   Users select the fastest concrete implementation class that
> > supports their model's notion of space.  Of course, users are also
> > free to extend or add to the existing concrete classes.
> > 
> >  
> > 
> > Mike
> > 
> >  
> > 
> >  
-- 
Tom Howe
Social Science Research Computing
University of Chicago

Re: [Repast-developer] cvs restructuring

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

Sure, That's fine.  I'll put it in the same place as the other jars.

-Tom

On Fri, 2003-01-10 at 13:02, Mark R. Diggory wrote:
> I was thinking just versioned releases would probibly be enough. 
> Primarily just as an alternative for deploying RePast. If you provided 
> the repast.jar via a consistent http url, then build scripts for binary 
> versions could just get that jar along with the other third party stuff 
> via ant.
> 
> The logic of this is: Often when your trying to allow others to run your 
> model, you don't neccessarily want them to have to go through and entire 
> build or install process independently to get RePast on their client. As 
> all the support for running the model is either in repast.jar or third 
> party jars, then it would be logical to provide downloadability for the 
> repast.jar if your going to do it for third party jars.
> 
> -Mark
> 
> Thomas R. Howe wrote:
> 
> >Do you mean nightly builds?  I hadn't thought about it, but I suppose we
> >could do that.
> >
> >-Tom
> >
> >On Thu, 2003-01-09 at 21:49, Mark R. Diggory wrote:
> >  
> >
> >>Thomas R. Howe wrote:
> >>    
> >>
> >>>The ant build file will now fetch the third party jars as part of the
> >>>build process, so hopefully, an entire distribution can be built quickly
> >>>from this new structure.  
> >>>
> >>>      
> >>>
> >>Great, I'm looking forward to this. Are you going to release locations 
> >>for first party repast jars as well as third party jars?
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.NET email is sponsored by:
> >>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >>http://www.vasoftware.com
> >>_______________________________________________
> >>Repast-developer mailing list
> >>Rep...@li...
> >>https://lists.sourceforge.net/lists/listinfo/repast-developer
> >>    
> >>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> 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] cvs restructuring

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

I was thinking just versioned releases would probibly be enough. 
Primarily just as an alternative for deploying RePast. If you provided 
the repast.jar via a consistent http url, then build scripts for binary 
versions could just get that jar along with the other third party stuff 
via ant.

The logic of this is: Often when your trying to allow others to run your 
model, you don't neccessarily want them to have to go through and entire 
build or install process independently to get RePast on their client. As 
all the support for running the model is either in repast.jar or third 
party jars, then it would be logical to provide downloadability for the 
repast.jar if your going to do it for third party jars.

-Mark

Thomas R. Howe wrote:

>Do you mean nightly builds?  I hadn't thought about it, but I suppose we
>could do that.
>
>-Tom
>
>On Thu, 2003-01-09 at 21:49, Mark R. Diggory wrote:
>  
>
>>Thomas R. Howe wrote:
>>    
>>
>>>The ant build file will now fetch the third party jars as part of the
>>>build process, so hopefully, an entire distribution can be built quickly
>>>from this new structure.  
>>>
>>>      
>>>
>>Great, I'm looking forward to this. Are you going to release locations 
>>for first party repast jars as well as third party jars?
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>http://www.vasoftware.com
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>    
>>

Re: [Repast-developer] cvs restructuring

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

I have nothing against either the restructuring nor the nightly builds.

Cheers,

Gulya

At 11:47 AM 1/10/2003 -0600, Thomas R. Howe wrote:
>Do you mean nightly builds?  I hadn't thought about it, but I suppose we
>could do that.
>
>-Tom
>
>On Thu, 2003-01-09 at 21:49, Mark R. Diggory wrote:
> > Thomas R. Howe wrote:
> > > The ant build file will now fetch the third party jars as part of the
> > > build process, so hopefully, an entire distribution can be built quickly
> > > from this new structure.
> > >
> >
> > Great, I'm looking forward to this. Are you going to release locations
> > for first party repast jars as well as third party jars?
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > 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:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] cvs restructuring

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

Do you mean nightly builds?  I hadn't thought about it, but I suppose we
could do that.

-Tom

On Thu, 2003-01-09 at 21:49, Mark R. Diggory wrote:
> Thomas R. Howe wrote:
> > The ant build file will now fetch the third party jars as part of the
> > build process, so hopefully, an entire distribution can be built quickly
> > from this new structure.  
> > 
> 
> Great, I'm looking forward to this. Are you going to release locations 
> for first party repast jars as well as third party jars?
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> 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] cvs restructuring

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

Thomas R. Howe wrote:
> The ant build file will now fetch the third party jars as part of the
> build process, so hopefully, an entire distribution can be built quickly
> from this new structure.  
> 

Great, I'm looking forward to this. Are you going to release locations 
for first party repast jars as well as third party jars?

[Repast-developer] cvs restructuring

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

In an effort to make builds and distribution building a bit easier, we
are going to restructure the cvs repository.  The new version will look
like this:

|_repast
        |_src
                |_Acme
                |_uchicago
                |_layout
        |_docs
                |_how_to
        |_build.xml
        |_COMPILING
        |_UPGRADING
        |_readme.html

The ant build file will now fetch the third party jars as part of the
build process, so hopefully, an entire distribution can be built quickly
from this new structure.  

In order to do this cleanly, we need to make sure that any changes you
may have made have been committed to the current cvs structure, so that
they aren't lost.  Also, after this is done, you'll need to check out
the sources again.  I'll let you know when that has happened.  I'd like
to submit the restructuring request today or tomorrow, so let me know if
you have any concerns.

Thanks,
tom
-- 
Tom Howe
Social Science Research Computing
University of Chicago

Re: [Repast-developer] DataRecorder and thread saftey

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

Hi,

Its funny because it just these kinds of dependencies that Tom and I
have been removing of the last couple of days. So, I guess we are in
practical agreement. This is a necessarily incremental process. Its
important that we don't frustrate too many users and leave them behind
otherwise the whole thing is pointless. 

The current refactoring of DataRecorder is an example of how I'd like
things to work. It should only depend on the IController and SimModel
interfaces. It should work in repast's gui, batch and distributed batch
contexts. It will be a proxy for LocalRecorder (gui and batch local
recording) and DistributedBatchRecorder and conform to a Recorder
interface. 

I get lots of questions of the kind "what class should I use to ...",
and I know that having a Recorder Interface with various implementors
for different contexts will not eliminate the question w/r to recording
data. In fact, having to pick among them would make matters worse from a
typical user point of view. Users often ask me what sort of java
collections to use and having a nice List Interface etc., doesn't help
them decide among Vector, ArrayList, LinkedList and so on. The fact that
they can be treated all as Lists is no help.

In short, I'd like to provide default canonical way of doing things
while allowing the kind of freedom you want. I think refactoring to
provide a clearer more coherent API will help to do this, but it won't
get us there entirely. This all is an expression of the tension between
repast as a kind of quasi-application and as a framework.

anyway thanks for the comments,

Nick

On Thu, 2003-01-02 at 13:31, Mark R. Diggory wrote:
> IMHO (or my $0.02),
> 
> I think your risking a sort of situation where, by not working towards 
> an organized API with well defined Interfaces, you risk creating too 
> many dependencies in the codebase. You risk actually confusing your 
> users by providing too many methods/constructors for a particular class 
> (Schedule as an example of this), this draws up a situation where your 
> users/model developers actually can't get an acurate mental model of the 
> API or the capabilites of a class within the API because the classes 
> either "do too much" or "do too little". I've spent much time leafing 
> through code trying to develop an acurate mental model of the packages. 
> I think its this confusion which stop the users from understanding what 
> they can really do in the Repast Simulation Framework. You, in turn to 
> compensate for this, attempt to make "more" options available to the 
> user in the base classes of Repast, which doesn't really solve the 
> problem of the confusion the user is experiencing. I believe, that a 
> well organized API is the only way to solve such problems, its the only 
> sound strategy that will lead developers keeping control over thier 
> development and as a tool to expose the capabilites of the 
> package/framework to the users. Ideally, if you want "pluggable style" 
> components in your framework (like your heading towards with Evolver) 
> then you need to consider the organization of your API.
> 
> I remember a comment you made earlier about trying to retain backward 
> compatability so that old models written against earlier versions of the 
> API could still run against new versions of the API. This is another 
> areana where one has to be very alert too code bloating. Having to 
> "retain" an old method because it was possibly called by an older model, 
> but which you wouldn't consider a valuble part of the API to be used by 
> newer models can get problematic if it happens alot. Eventually you 
> would have to consider using deprication to remove such methods and get 
> them out of your api so that you can move forward in its development an 
> let go of  the older design. I really don't think its the case that you 
> will really loose users if you have a sound and well defined goal for 
> the development that occurs over many releases and provides many 
> opportunities to alert the user to deprications and removals that are 
> coming. Giving the users opportunities for input into the overall design 
> will definitly keep their interest in future releases of Repast. It is 
> always the case that a user could install an older version of repast for 
> which their model was designed in, but with well documented and timed 
> changes in the API, making the minor modifications required to adopt 
> their model to the new API are easy tasks that will actually excite and 
> inspire the user when they reallize the added benifits.
> 
> I agree that I am looking at the package with a great deal of 
> "developer" experience and as an API that I want to utilize in a 
> programming environment. From my experience with Java and picking up 
> packages and using/learning them (across many releases of the package), 
> I do see this as the ultimate path to go on. I think a "well designed" 
> API is really the foundation for a Framework that is simple to use. A 
> framework without a well defined API has the danger of  following a path 
> of development where the ability to track dependencies becomes too 
> complicated (think of Netscape before Mozilla). The code can become too 
> confusing to maintain. While the Repast codebase has a ways to go before 
> it reaches this extreme, you have an opportunity to avoid going down 
> this path by refactoring the API and stablizing the Implementation 
> behind solidly defined Interfaces.
> 
> Ok, maybe that was $0.03,
> Mark
> 
> Nick Collier wrote:
> 
> >Hi,
> >
> >I agree that a Recorder interface might be useful, but its important to
> >think of repast as more than a framework of pieces for simulations. The
> >idea is that, although we are trying to make repast as "open" as
> >possible, we want to provide support for three kinds of simulations:
> >gui, batch, and distributed batch. In order to allow users to do this
> >easily and not shoot themselves in the foot, somethings are more tightly
> >bound to each other than they otherwise would be if we were just
> >providing a framework. In this case, the idea is that a call to 
> >
> >new DataRecorder(...)
> >
> >will create a data recorder appropriate for gui, batch and distributed
> >batch simulations depending on the running context. The point being that
> >we want this to be as easy for users as possible. We want to allow you
> >to create other kinds of recorders, but DataRecorder is written to
> >support our gui, batch and soon distributed batch capabilities. That
> >said, the various pieces that make up a data recorder, the data sources
> >etc. are still open to you. Its just the writing and the actual
> >extraction of data from the sources that one would need to code.
> >
> >What I'm trying to say is that we need to strike a balance between
> >letting experienced programmers use repast as something close to a
> >component framework for developing simulations, and allowing
> >inexperienced users to develop _repast_ gui, batch, or distributed batch
> >simulations. Hope this makes sense.
> >
> >Nick
> >
> >On Thu, 2003-01-02 at 11:46, Mark R. Diggory wrote:
> >  
> >
> >>I was actually working one the idea of having a "DataRecorder" available 
> >>across Simulation Threads. The idea is that since I've moved my batch 
> >>processing up and out of the Repast Controller API, I'm now handing an 
> >>already existing instance of a my Recording Class into the 
> >>Controller/Model pair I'm runinng. I havn't encountered an issue where 
> >>threading would be a problem, but where I'm heading could invlove 
> >>multiple simulations running at the same time on different threads, 
> >>thread saftey could be benificial. Sadly, I ended up just writing a 
> >>class BatchRecorder that wraps a FileWriter, not that its a 
> >>"DataRecorder". While I understand the concepts behind "DataRecorder" I 
> >>wanted a little more control over the header and record layout than I 
> >>could get in the DataRecorder, so I ended up rolling my own.
> >>
> >>Thomas R. Howe wrote:
> >>
> >>    
> >>
> >>>Funny you should ask, because I'm facing the same issue as I am writing
> >>>the DistributedDataRecorder.  The classes are not thread safe.  I need
> >>>to warn you, As I'm writing the distributed stuff, I will probably turn
> >>>DataRecorder into a Proxy for either a distributed or a local
> >>>DataRecorder.  This won't affect most people, but perhaps it will for
> >>>what you are doing.
> >>> 
> >>>
> >>>      
> >>>
> >>Not to sound like an "Interface junkie" but would it be good to place 
> >>the DataRecorder behind a "Recorder" interface. Instead of thinking of 
> >> it as a proxy, produce separate DistributedDataRecorder and 
> >>DataRecorder implementations of the Recorder Interface? Then The 
> >>DataRecorder can stay in its current state and New Implementations (like 
> >>DistributedDataRecorder) can be created by developers. 
> >>
> >>I guess in the case where a Model might have a "Recorders" collection 
> >>that any recorder can be added into, then data collection just becomes 
> >>an issue of calling Recorder.record()/Recorder.writeToFile() on the 
> >>objects in the collection.
> >>
> >>I.E.
> >>
> >>List recorders = new ArrayList();
> >>
> >>recorders.add(new DataRecorder(...));
> >>recorders.add(new DistributedDataRecorder(...));
> >>
> >>ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
> >>group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> >>, "record");
> >>group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> >>, "writeToFile");
> >>
> >>schedule.scheduleActionBeginning(0.0,group);
> >>
> >>-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
> >>    
> >>
> 
> 
> 
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] DataRecorder and thread saftey

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

Thank you, I value your saying that. I enjoy having the opportunity to 
provide input on the packages I work with, whatever your decision about 
the path of development. Besides, if I need something a certain way, and 
your development isn't heading that way, then I just build it myself. ;-)

We all have different viewpoints and opinions, that what makes this all 
so interesting!

-Mark

Nick Collier wrote:

>Hi,
>
>Just in case the tone of my last email may have indicated otherwise, I
>and Tom as well really appreciate your comments. The work I did this
>morning is the direct result of the IController refactoring so we are
>trying to strike an appropriate balance.
>
>Nick
>
>On Thu, 2003-01-02 at 11:46, Mark R. Diggory wrote:
>  
>
>>I was actually working one the idea of having a "DataRecorder" available 
>>across Simulation Threads. The idea is that since I've moved my batch 
>>processing up and out of the Repast Controller API, I'm now handing an 
>>already existing instance of a my Recording Class into the 
>>Controller/Model pair I'm runinng. I havn't encountered an issue where 
>>threading would be a problem, but where I'm heading could invlove 
>>multiple simulations running at the same time on different threads, 
>>thread saftey could be benificial. Sadly, I ended up just writing a 
>>class BatchRecorder that wraps a FileWriter, not that its a 
>>"DataRecorder". While I understand the concepts behind "DataRecorder" I 
>>wanted a little more control over the header and record layout than I 
>>could get in the DataRecorder, so I ended up rolling my own.
>>
>>Thomas R. Howe wrote:
>>
>>    
>>
>>>Funny you should ask, because I'm facing the same issue as I am writing
>>>the DistributedDataRecorder.  The classes are not thread safe.  I need
>>>to warn you, As I'm writing the distributed stuff, I will probably turn
>>>DataRecorder into a Proxy for either a distributed or a local
>>>DataRecorder.  This won't affect most people, but perhaps it will for
>>>what you are doing.
>>> 
>>>
>>>      
>>>
>>Not to sound like an "Interface junkie" but would it be good to place 
>>the DataRecorder behind a "Recorder" interface. Instead of thinking of 
>> it as a proxy, produce separate DistributedDataRecorder and 
>>DataRecorder implementations of the Recorder Interface? Then The 
>>DataRecorder can stay in its current state and New Implementations (like 
>>DistributedDataRecorder) can be created by developers. 
>>
>>I guess in the case where a Model might have a "Recorders" collection 
>>that any recorder can be added into, then data collection just becomes 
>>an issue of calling Recorder.record()/Recorder.writeToFile() on the 
>>objects in the collection.
>>
>>I.E.
>>
>>List recorders = new ArrayList();
>>
>>recorders.add(new DataRecorder(...));
>>recorders.add(new DistributedDataRecorder(...));
>>
>>ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
>>group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
>>, "record");
>>group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
>>, "writeToFile");
>>
>>schedule.scheduleActionBeginning(0.0,group);
>>
>>-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
>>    
>>

Re: [Repast-developer] DataRecorder and thread saftey

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

IMHO (or my $0.02),

I think your risking a sort of situation where, by not working towards 
an organized API with well defined Interfaces, you risk creating too 
many dependencies in the codebase. You risk actually confusing your 
users by providing too many methods/constructors for a particular class 
(Schedule as an example of this), this draws up a situation where your 
users/model developers actually can't get an acurate mental model of the 
API or the capabilites of a class within the API because the classes 
either "do too much" or "do too little". I've spent much time leafing 
through code trying to develop an acurate mental model of the packages. 
I think its this confusion which stop the users from understanding what 
they can really do in the Repast Simulation Framework. You, in turn to 
compensate for this, attempt to make "more" options available to the 
user in the base classes of Repast, which doesn't really solve the 
problem of the confusion the user is experiencing. I believe, that a 
well organized API is the only way to solve such problems, its the only 
sound strategy that will lead developers keeping control over thier 
development and as a tool to expose the capabilites of the 
package/framework to the users. Ideally, if you want "pluggable style" 
components in your framework (like your heading towards with Evolver) 
then you need to consider the organization of your API.

I remember a comment you made earlier about trying to retain backward 
compatability so that old models written against earlier versions of the 
API could still run against new versions of the API. This is another 
areana where one has to be very alert too code bloating. Having to 
"retain" an old method because it was possibly called by an older model, 
but which you wouldn't consider a valuble part of the API to be used by 
newer models can get problematic if it happens alot. Eventually you 
would have to consider using deprication to remove such methods and get 
them out of your api so that you can move forward in its development an 
let go of  the older design. I really don't think its the case that you 
will really loose users if you have a sound and well defined goal for 
the development that occurs over many releases and provides many 
opportunities to alert the user to deprications and removals that are 
coming. Giving the users opportunities for input into the overall design 
will definitly keep their interest in future releases of Repast. It is 
always the case that a user could install an older version of repast for 
which their model was designed in, but with well documented and timed 
changes in the API, making the minor modifications required to adopt 
their model to the new API are easy tasks that will actually excite and 
inspire the user when they reallize the added benifits.

I agree that I am looking at the package with a great deal of 
"developer" experience and as an API that I want to utilize in a 
programming environment. From my experience with Java and picking up 
packages and using/learning them (across many releases of the package), 
I do see this as the ultimate path to go on. I think a "well designed" 
API is really the foundation for a Framework that is simple to use. A 
framework without a well defined API has the danger of  following a path 
of development where the ability to track dependencies becomes too 
complicated (think of Netscape before Mozilla). The code can become too 
confusing to maintain. While the Repast codebase has a ways to go before 
it reaches this extreme, you have an opportunity to avoid going down 
this path by refactoring the API and stablizing the Implementation 
behind solidly defined Interfaces.

Ok, maybe that was $0.03,
Mark

Nick Collier wrote:

>Hi,
>
>I agree that a Recorder interface might be useful, but its important to
>think of repast as more than a framework of pieces for simulations. The
>idea is that, although we are trying to make repast as "open" as
>possible, we want to provide support for three kinds of simulations:
>gui, batch, and distributed batch. In order to allow users to do this
>easily and not shoot themselves in the foot, somethings are more tightly
>bound to each other than they otherwise would be if we were just
>providing a framework. In this case, the idea is that a call to 
>
>new DataRecorder(...)
>
>will create a data recorder appropriate for gui, batch and distributed
>batch simulations depending on the running context. The point being that
>we want this to be as easy for users as possible. We want to allow you
>to create other kinds of recorders, but DataRecorder is written to
>support our gui, batch and soon distributed batch capabilities. That
>said, the various pieces that make up a data recorder, the data sources
>etc. are still open to you. Its just the writing and the actual
>extraction of data from the sources that one would need to code.
>
>What I'm trying to say is that we need to strike a balance between
>letting experienced programmers use repast as something close to a
>component framework for developing simulations, and allowing
>inexperienced users to develop _repast_ gui, batch, or distributed batch
>simulations. Hope this makes sense.
>
>Nick
>
>On Thu, 2003-01-02 at 11:46, Mark R. Diggory wrote:
>  
>
>>I was actually working one the idea of having a "DataRecorder" available 
>>across Simulation Threads. The idea is that since I've moved my batch 
>>processing up and out of the Repast Controller API, I'm now handing an 
>>already existing instance of a my Recording Class into the 
>>Controller/Model pair I'm runinng. I havn't encountered an issue where 
>>threading would be a problem, but where I'm heading could invlove 
>>multiple simulations running at the same time on different threads, 
>>thread saftey could be benificial. Sadly, I ended up just writing a 
>>class BatchRecorder that wraps a FileWriter, not that its a 
>>"DataRecorder". While I understand the concepts behind "DataRecorder" I 
>>wanted a little more control over the header and record layout than I 
>>could get in the DataRecorder, so I ended up rolling my own.
>>
>>Thomas R. Howe wrote:
>>
>>    
>>
>>>Funny you should ask, because I'm facing the same issue as I am writing
>>>the DistributedDataRecorder.  The classes are not thread safe.  I need
>>>to warn you, As I'm writing the distributed stuff, I will probably turn
>>>DataRecorder into a Proxy for either a distributed or a local
>>>DataRecorder.  This won't affect most people, but perhaps it will for
>>>what you are doing.
>>> 
>>>
>>>      
>>>
>>Not to sound like an "Interface junkie" but would it be good to place 
>>the DataRecorder behind a "Recorder" interface. Instead of thinking of 
>> it as a proxy, produce separate DistributedDataRecorder and 
>>DataRecorder implementations of the Recorder Interface? Then The 
>>DataRecorder can stay in its current state and New Implementations (like 
>>DistributedDataRecorder) can be created by developers. 
>>
>>I guess in the case where a Model might have a "Recorders" collection 
>>that any recorder can be added into, then data collection just becomes 
>>an issue of calling Recorder.record()/Recorder.writeToFile() on the 
>>objects in the collection.
>>
>>I.E.
>>
>>List recorders = new ArrayList();
>>
>>recorders.add(new DataRecorder(...));
>>recorders.add(new DistributedDataRecorder(...));
>>
>>ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
>>group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
>>, "record");
>>group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
>>, "writeToFile");
>>
>>schedule.scheduleActionBeginning(0.0,group);
>>
>>-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
>>    
>>

Re: [Repast-developer] DataRecorder and thread saftey

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

Hi,

Just in case the tone of my last email may have indicated otherwise, I
and Tom as well really appreciate your comments. The work I did this
morning is the direct result of the IController refactoring so we are
trying to strike an appropriate balance.

Nick

On Thu, 2003-01-02 at 11:46, Mark R. Diggory wrote:
> I was actually working one the idea of having a "DataRecorder" available 
> across Simulation Threads. The idea is that since I've moved my batch 
> processing up and out of the Repast Controller API, I'm now handing an 
> already existing instance of a my Recording Class into the 
> Controller/Model pair I'm runinng. I havn't encountered an issue where 
> threading would be a problem, but where I'm heading could invlove 
> multiple simulations running at the same time on different threads, 
> thread saftey could be benificial. Sadly, I ended up just writing a 
> class BatchRecorder that wraps a FileWriter, not that its a 
> "DataRecorder". While I understand the concepts behind "DataRecorder" I 
> wanted a little more control over the header and record layout than I 
> could get in the DataRecorder, so I ended up rolling my own.
> 
> Thomas R. Howe wrote:
> 
> >Funny you should ask, because I'm facing the same issue as I am writing
> >the DistributedDataRecorder.  The classes are not thread safe.  I need
> >to warn you, As I'm writing the distributed stuff, I will probably turn
> >DataRecorder into a Proxy for either a distributed or a local
> >DataRecorder.  This won't affect most people, but perhaps it will for
> >what you are doing.
> >  
> >
> Not to sound like an "Interface junkie" but would it be good to place 
> the DataRecorder behind a "Recorder" interface. Instead of thinking of 
>  it as a proxy, produce separate DistributedDataRecorder and 
> DataRecorder implementations of the Recorder Interface? Then The 
> DataRecorder can stay in its current state and New Implementations (like 
> DistributedDataRecorder) can be created by developers. 
> 
> I guess in the case where a Model might have a "Recorders" collection 
> that any recorder can be added into, then data collection just becomes 
> an issue of calling Recorder.record()/Recorder.writeToFile() on the 
> objects in the collection.
> 
> I.E.
> 
> List recorders = new ArrayList();
> 
> recorders.add(new DataRecorder(...));
> recorders.add(new DistributedDataRecorder(...));
> 
> ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
> group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> , "record");
> group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> , "writeToFile");
> 
> schedule.scheduleActionBeginning(0.0,group);
> 
> -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
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] DataRecorder and thread saftey

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

Hi,

I agree that a Recorder interface might be useful, but its important to
think of repast as more than a framework of pieces for simulations. The
idea is that, although we are trying to make repast as "open" as
possible, we want to provide support for three kinds of simulations:
gui, batch, and distributed batch. In order to allow users to do this
easily and not shoot themselves in the foot, somethings are more tightly
bound to each other than they otherwise would be if we were just
providing a framework. In this case, the idea is that a call to 

new DataRecorder(...)

will create a data recorder appropriate for gui, batch and distributed
batch simulations depending on the running context. The point being that
we want this to be as easy for users as possible. We want to allow you
to create other kinds of recorders, but DataRecorder is written to
support our gui, batch and soon distributed batch capabilities. That
said, the various pieces that make up a data recorder, the data sources
etc. are still open to you. Its just the writing and the actual
extraction of data from the sources that one would need to code.

What I'm trying to say is that we need to strike a balance between
letting experienced programmers use repast as something close to a
component framework for developing simulations, and allowing
inexperienced users to develop _repast_ gui, batch, or distributed batch
simulations. Hope this makes sense.

Nick

On Thu, 2003-01-02 at 11:46, Mark R. Diggory wrote:
> I was actually working one the idea of having a "DataRecorder" available 
> across Simulation Threads. The idea is that since I've moved my batch 
> processing up and out of the Repast Controller API, I'm now handing an 
> already existing instance of a my Recording Class into the 
> Controller/Model pair I'm runinng. I havn't encountered an issue where 
> threading would be a problem, but where I'm heading could invlove 
> multiple simulations running at the same time on different threads, 
> thread saftey could be benificial. Sadly, I ended up just writing a 
> class BatchRecorder that wraps a FileWriter, not that its a 
> "DataRecorder". While I understand the concepts behind "DataRecorder" I 
> wanted a little more control over the header and record layout than I 
> could get in the DataRecorder, so I ended up rolling my own.
> 
> Thomas R. Howe wrote:
> 
> >Funny you should ask, because I'm facing the same issue as I am writing
> >the DistributedDataRecorder.  The classes are not thread safe.  I need
> >to warn you, As I'm writing the distributed stuff, I will probably turn
> >DataRecorder into a Proxy for either a distributed or a local
> >DataRecorder.  This won't affect most people, but perhaps it will for
> >what you are doing.
> >  
> >
> Not to sound like an "Interface junkie" but would it be good to place 
> the DataRecorder behind a "Recorder" interface. Instead of thinking of 
>  it as a proxy, produce separate DistributedDataRecorder and 
> DataRecorder implementations of the Recorder Interface? Then The 
> DataRecorder can stay in its current state and New Implementations (like 
> DistributedDataRecorder) can be created by developers. 
> 
> I guess in the case where a Model might have a "Recorders" collection 
> that any recorder can be added into, then data collection just becomes 
> an issue of calling Recorder.record()/Recorder.writeToFile() on the 
> objects in the collection.
> 
> I.E.
> 
> List recorders = new ArrayList();
> 
> recorders.add(new DataRecorder(...));
> recorders.add(new DistributedDataRecorder(...));
> 
> ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
> group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> , "record");
> group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> , "writeToFile");
> 
> schedule.scheduleActionBeginning(0.0,group);
> 
> -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
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] DataRecorder and thread saftey

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

I was actually working one the idea of having a "DataRecorder" available 
across Simulation Threads. The idea is that since I've moved my batch 
processing up and out of the Repast Controller API, I'm now handing an 
already existing instance of a my Recording Class into the 
Controller/Model pair I'm runinng. I havn't encountered an issue where 
threading would be a problem, but where I'm heading could invlove 
multiple simulations running at the same time on different threads, 
thread saftey could be benificial. Sadly, I ended up just writing a 
class BatchRecorder that wraps a FileWriter, not that its a 
"DataRecorder". While I understand the concepts behind "DataRecorder" I 
wanted a little more control over the header and record layout than I 
could get in the DataRecorder, so I ended up rolling my own.

Thomas R. Howe wrote:

>Funny you should ask, because I'm facing the same issue as I am writing
>the DistributedDataRecorder.  The classes are not thread safe.  I need
>to warn you, As I'm writing the distributed stuff, I will probably turn
>DataRecorder into a Proxy for either a distributed or a local
>DataRecorder.  This won't affect most people, but perhaps it will for
>what you are doing.
>  
>
Not to sound like an "Interface junkie" but would it be good to place 
the DataRecorder behind a "Recorder" interface. Instead of thinking of 
 it as a proxy, produce separate DistributedDataRecorder and 
DataRecorder implementations of the Recorder Interface? Then The 
DataRecorder can stay in its current state and New Implementations (like 
DistributedDataRecorder) can be created by developers. 

I guess in the case where a Model might have a "Recorders" collection 
that any recorder can be added into, then data collection just becomes 
an issue of calling Recorder.record()/Recorder.writeToFile() on the 
objects in the collection.

I.E.

List recorders = new ArrayList();

recorders.add(new DataRecorder(...));
recorders.add(new DistributedDataRecorder(...));

ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
, "record");
group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
, "writeToFile");

schedule.scheduleActionBeginning(0.0,group);

-Mark

Re: [Repast-developer] DataRecorder and thread saftey

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

Funny you should ask, because I'm facing the same issue as I am writing
the DistributedDataRecorder.  The classes are not thread safe.  I need
to warn you, As I'm writing the distributed stuff, I will probably turn
DataRecorder into a Proxy for either a distributed or a local
DataRecorder.  This won't affect most people, but perhaps it will for
what you are doing.

-Tom

On Thu, 2003-01-02 at 09:08, Mark R. Diggory wrote:
> Is DataRecorder or any of its underlying classes actually thread safe? 
> Has it ever been tested with two threads trying to write to the same file?
> 
> -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
-- 
Tom Howe
Social Science Research Computing
University of Chicago

[Repast-developer] Re: DataRecorder and thread saftey

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

No, it isn't nor was it ever intended to be. Two threads writing to the
same file would no doubt cause problems. However, I've never heard of
this happening under "normal" repast usage. 

That said, Tom and I are currently thinking about data recorder
interaction with IController as well as distributed data recorders and
this is one of the issues.

Nick

On Thu, 2003-01-02 at 10:08, Mark R. Diggory wrote:
> Is DataRecorder or any of its underlying classes actually thread safe? 
> Has it ever been tested with two threads trying to write to the same file?
> 
> -Mark
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] DataRecorder and thread saftey

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

Is DataRecorder or any of its underlying classes actually thread safe? 
Has it ever been tested with two threads trying to write to the same file?

-Mark

Re: [Repast-developer] Splitting DisplaySurface3D

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

This seems good to me.  Keep all of the rendering stuff (simpleUniverse,
etc) in the "Display" class.  Then you can still have a DisplaySurface
that is the Frame, event handler, and deals with all of the probing. 
Basically this will look very similar to what we talked about yesterday,
except that the SimpleUniverse will reside in the display instead of the
displaySurface.  This would allow the user to add multiple displays to
one displaySurface if, God forbid, they wanted to.  This sounds very
good to me.  I need to think about what DisplaySurface3D would need to
look like.  But I bet it looks a lot like DisplaySurface.  Maybe I can
refactor DisplaySurface so that it would work with 3D spaces as well.

-Tom


On Mon, 2002-12-30 at 13:39, Phil Feldman wrote:
> Tom,
> 
> I've been looking through my DisplaySurface3D code and I'm thinking that 
> the canvas3D/SimpleUniverse split will make things uglier. The reason is 
> that PickUtilities requires both the canvas3D and the root of the scene 
> graph in which the picking will take place. That means that the display 
> and surface classes would have to have enough knowledge of each other 
> that splitting them doesn't' make sense to me. Additionally, 
> SimpleUniverse actually supports only *one* Canvase3D, even thought 
> there is a getCanvas that can retrieve by index.
> 
> Rather than that, what might work easier is to have the particular scene 
> graph generated or imported by the user load into a
> UserSceneGraph class that would correspond (somewhat) to Display. You 
> could have classes for CustomSceneGraph, XMLSceneGraph, etc that would 
> handle the particulars of the scene graph setup and feed them to the 
> DisplaySurface3D.
> 
> Thoughts?
> 
> Phil
> 
> 
> 
> 
> -------------------------------------------------------
> 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] More thoughts on Controllers

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

Yes, in relation to jelly as an example the following becomes apparent 
when dealing with Controllers and the initSim() method idea.

Here is an example of a jelly script to start a simple GUI based 
Controller Simulation.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="jelly:org.mrd.jelly.repast.RepastTagLibrary">

       <controller
            var="cntrl_x"
            class="uchicago.src.sim.engine.Controller"
        />

        <model
            var="model_x"
            class="your.project.Model"
            controller="${cntrl_x}">

            <setProperties object="${model_x}"
                 someModelParameter1="x.x"
                 someModelParameter2="y.y"
                 someModelParameterN="z.z"
             />

         </model>

         ${cntrl_x.display()}

</project>

The real point of interest is in ${cntrl_x.display()}. If this were an 
example using BatchController, I'd have to call ${cntrl_x.begin()}.
This is an example of using "Jexl" script for picking up an object in 
the JellyContext and calling a method on it (or also passing an instance 
of it onto another object.). While I like Jexl script for doing things, 
I'm trying to minimize my use of it for tasks like this and rely on the 
tag library to support it in the Java Implementation of the Repast 
<project>, <controller> and <model> tags. This is to keep the file as 
much like a Configuration/Properties file as possible and less like a 
program script.

Right now, I could write code into the </project> end tag such that the 
appropriate method (begin or display) was called to startup the 
simulation. However, this would not be very flexible in relation to the 
fact that any Implementation of "IController" could be placed into the 
controller tag (even custom implementations). The extensibility gets 
lost as soon as one starts conditionally casting or instantiating 
directly into the extended classes to get at methods only available in 
those classes.

So having a common "initSim" method for "starting up" all Controllers 
would make the code behind this </project> tag simpler and much cleaner 
in the long run. Plus it would fit well with the extensible 
functionality employed in the <controller> tag.

For SimInit, it could make the code a little simpler. It could even be 
the case that instead of a boolean option to pickup and use either the 
Controller or the BatchController one could provide an IController based 
class name and that class could be instantiated via reflection. Thus 
providing the same extensibility mechanisms into SimInit as I'm making 
available in my Repast JellyTagLibrary.

It could even then be the case that I could actually use such a modified 
SimInit behind the project tag to startup the simulation thread instead 
of my own custom code. Then the Tag Libraries I'm writing would really 
just be wrappers around already existing Repast functionality. If some 
other really cool environment other than Jelly came down the pipeline, 
then that same functionality could be made available in that environment 
as well.

Also, if this modified SimInit existed I could easily replicate all the 
demos to startup and be parameterized via Jelly scripts to show as 
examples of the Jelly strategy. Once I'm ready to present this to the 
group I can post the entire project to the list to experiment with and 
get opinions of.

For DataRecorder, it would make the class a little less dependent on the 
implementation of the BatchController and more dependent on the 
isBatch() method for determining behavior. I think the cast to 
BatchController here is not really required now that IController 
supports the addSimEventListener(this) and isBatch() methods.


     if (isBatch) {
       BatchController control = (BatchController)model.getController();
       control.addSimEventListener(this);
       dynParams = dfHeader.getDynParamMethod();

       Enumeration e = dynParams.keys();
       while (e.hasMoreElements()) {
         String key = (String)e.nextElement();
         //System.out.println(key);
         DataSource s = new ObjectDataSource(key, model,
					    (Method)dynParams.get(key));
         sources.add(s);
         data.addToHeader(key);
       }


While, I don't think your development of the IController interface 
probably should be solely determined by my suggestions here, I am glad 
to have a good "layer" of criticism to factor out any of the poorer 
suggestions I may make. Thanks for entertaining my ideas. I also think 
it would be good to go back and look over the refactoring ideas we threw 
around before the 2.0 release an make sure we are interested in those still.

-Mark


Nick Collier wrote:
> Hi,
> 
> I agree with you on both the issue of adding isGui() and initSim() to
> IController. In fact, my original IController had an isGui() in it. I
> forget now why I dropped it.
> 
> However, I can see how something like isGui() or isBatch() can be used
> polymorphically in DataRecorder. It receives an IController from the
> SimModel.getController() and then behaves appropriately depending on the
> result of isBatch(). What's less clear to me is how the polymorphic
> initialization and running of a simulation would work. As it stands now,
> SimInit creates either a BatchController or a Controller. It could
> certainly treat these uniformly as an instance of an IController, but
> considering that it needs to create either one depending on a command
> line switch, there is little (although certainly something) to be gained
> here. All this is not a criticism of adding something like initSim() but
> rather a request for information on the benefits / the context of
> polymorphic initialization. Maybe you've described this before in the
> context of Jelly, but I don't recall.
> 
> Nick
> 
> On Mon, 2002-12-30 at 14:01, Mark R. Diggory wrote:
> 
>>I took ThinController and used it as an example, I also added the 
>>begin() method from BatchController to it (name actually called 
>>initSim()). This is because the begin method provides a transition point 
>>wherer the creation of the new thread occurs, making ThinController do 
>>alittle bit of thread startup management as well.
>>
>>
>>I'm concerned about the multiple methods used to "initialize" the 
>>Controller under different IController implementations.
>>
>>1.) display() is used in the GUI Controller
>>2.) begin() is used in the BatchController
>>3.) nothing is really available in the ThinController
>>
>>Would it be good to also have an "initialize()" style method that could 
>>be used to consolidate these different methods in IController?
>>
>>
>>public void initSim(){
>>	
>>	1.) in Controller this calls "display()"
>>
>>	2.) in BatchController this calls "begin()"
>>
>>	3.) a simple example in ThinController is attached.
>>
>>}
>>
>>
>>I guess its a question of whether or not the setup should be done in a 
>>"Caller/Wrapper" or be done inside the IController. In this example it 
>>makes life easier in the caller. Given that BaseController is completely 
>>implemented in an asynchronous fashion, it is my opinion that 
>>Implementations that extend it should have at least some simple startup 
>>init like in display() (Controller) and begin() (BatchController).
>>
>>Maybe if non-asynchronous control of the sim were wanted (simulation 
>>runs in the same thread as the controller). Then thread management 
>>issues would be managed in the Caller of the Controller, in which case, 
>>the controller would be very simplified. Maybe one would have 
>>AsynchronousBaseController and NonAsynchronousBaseController 
>>implementations with
>>
>>Controller extends AsynchronousBaseController
>>BatchController extends AsynchronousBaseController
>>ThinController extends AsynchronousBaseController
>>
>>and
>>
>>SimpleController extends NonAsynchronousBaseController
>>
>>this example would move threading issues completely out into the Caller.
>>
>>These are just ideas, I'm sure of my opinion an this stuff, I'm not sure 
>>  how valuable something like SimpleController would really be. It might 
>>be usefull in situations where Parallel Processing is managed externally 
>>to the Repast Sim, like in massively parallel supercomputer systems.
>>
>>Primarily, I think it would at least be wise to have something like 
>>initSim() in the IController.
>>
>>-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] Splitting DisplaySurface3D

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

Tom,

I've been looking through my DisplaySurface3D code and I'm thinking that 
the canvas3D/SimpleUniverse split will make things uglier. The reason is 
that PickUtilities requires both the canvas3D and the root of the scene 
graph in which the picking will take place. That means that the display 
and surface classes would have to have enough knowledge of each other 
that splitting them doesn't' make sense to me. Additionally, 
SimpleUniverse actually supports only *one* Canvase3D, even thought 
there is a getCanvas that can retrieve by index.

Rather than that, what might work easier is to have the particular scene 
graph generated or imported by the user load into a
UserSceneGraph class that would correspond (somewhat) to Display. You 
could have classes for CustomSceneGraph, XMLSceneGraph, etc that would 
handle the particulars of the scene graph setup and feed them to the 
DisplaySurface3D.

Thoughts?

Phil

Re: [Repast-developer] More thoughts on Controllers

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

Hi,

I agree with you on both the issue of adding isGui() and initSim() to
IController. In fact, my original IController had an isGui() in it. I
forget now why I dropped it.

However, I can see how something like isGui() or isBatch() can be used
polymorphically in DataRecorder. It receives an IController from the
SimModel.getController() and then behaves appropriately depending on the
result of isBatch(). What's less clear to me is how the polymorphic
initialization and running of a simulation would work. As it stands now,
SimInit creates either a BatchController or a Controller. It could
certainly treat these uniformly as an instance of an IController, but
considering that it needs to create either one depending on a command
line switch, there is little (although certainly something) to be gained
here. All this is not a criticism of adding something like initSim() but
rather a request for information on the benefits / the context of
polymorphic initialization. Maybe you've described this before in the
context of Jelly, but I don't recall.

Nick

On Mon, 2002-12-30 at 14:01, Mark R. Diggory wrote:
> I took ThinController and used it as an example, I also added the 
> begin() method from BatchController to it (name actually called 
> initSim()). This is because the begin method provides a transition point 
> wherer the creation of the new thread occurs, making ThinController do 
> alittle bit of thread startup management as well.
> 
> 
> I'm concerned about the multiple methods used to "initialize" the 
> Controller under different IController implementations.
> 
> 1.) display() is used in the GUI Controller
> 2.) begin() is used in the BatchController
> 3.) nothing is really available in the ThinController
> 
> Would it be good to also have an "initialize()" style method that could 
> be used to consolidate these different methods in IController?
> 
> 
> public void initSim(){
> 	
> 	1.) in Controller this calls "display()"
> 
> 	2.) in BatchController this calls "begin()"
> 
> 	3.) a simple example in ThinController is attached.
> 
> }
> 
> 
> I guess its a question of whether or not the setup should be done in a 
> "Caller/Wrapper" or be done inside the IController. In this example it 
> makes life easier in the caller. Given that BaseController is completely 
> implemented in an asynchronous fashion, it is my opinion that 
> Implementations that extend it should have at least some simple startup 
> init like in display() (Controller) and begin() (BatchController).
> 
> Maybe if non-asynchronous control of the sim were wanted (simulation 
> runs in the same thread as the controller). Then thread management 
> issues would be managed in the Caller of the Controller, in which case, 
> the controller would be very simplified. Maybe one would have 
> AsynchronousBaseController and NonAsynchronousBaseController 
> implementations with
> 
> Controller extends AsynchronousBaseController
> BatchController extends AsynchronousBaseController
> ThinController extends AsynchronousBaseController
> 
> and
> 
> SimpleController extends NonAsynchronousBaseController
> 
> this example would move threading issues completely out into the Caller.
> 
> These are just ideas, I'm sure of my opinion an this stuff, I'm not sure 
>   how valuable something like SimpleController would really be. It might 
> be usefull in situations where Parallel Processing is managed externally 
> to the Repast Sim, like in massively parallel supercomputer systems.
> 
> Primarily, I think it would at least be wise to have something like 
> initSim() in the IController.
> 
> -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
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] Re: More thoughts on Controllers

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

Forgot the attachment, sorry.

Mark R. Diggory wrote:
> I took ThinController and used it as an example, I also added the 
> begin() method from BatchController to it (name actually called 
> initSim()). This is because the begin method provides a transition point 
> wherer the creation of the new thread occurs, making ThinController do 
> alittle bit of thread startup management as well.
> 
> 
> I'm concerned about the multiple methods used to "initialize" the 
> Controller under different IController implementations.
> 
> 1.) display() is used in the GUI Controller
> 2.) begin() is used in the BatchController
> 3.) nothing is really available in the ThinController
> 
> Would it be good to also have an "initialize()" style method that could 
> be used to consolidate these different methods in IController?
> 
> 
> public void initSim(){
>     
>     1.) in Controller this calls "display()"
> 
>     2.) in BatchController this calls "begin()"
> 
>     3.) a simple example in ThinController is attached.
> 
> }
> 
> 
> I guess its a question of whether or not the setup should be done in a 
> "Caller/Wrapper" or be done inside the IController. In this example it 
> makes life easier in the caller. Given that BaseController is completely 
> implemented in an asynchronous fashion, it is my opinion that 
> Implementations that extend it should have at least some simple startup 
> init like in display() (Controller) and begin() (BatchController).
> 
> Maybe if non-asynchronous control of the sim were wanted (simulation 
> runs in the same thread as the controller). Then thread management 
> issues would be managed in the Caller of the Controller, in which case, 
> the controller would be very simplified. Maybe one would have 
> AsynchronousBaseController and NonAsynchronousBaseController 
> implementations with
> 
> Controller extends AsynchronousBaseController
> BatchController extends AsynchronousBaseController
> ThinController extends AsynchronousBaseController
> 
> and
> 
> SimpleController extends NonAsynchronousBaseController
> 
> this example would move threading issues completely out into the Caller.
> 
> These are just ideas, I'm sure of my opinion an this stuff, I'm not sure 
>  how valuable something like SimpleController would really be. It might 
> be usefull in situations where Parallel Processing is managed externally 
> to the Repast Sim, like in massively parallel supercomputer systems.
> 
> Primarily, I think it would at least be wise to have something like 
> initSim() in the IController.
> 
> -Mark
> 
> 
> 
> 
> 

[Repast-developer] More thoughts on Controllers

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

I took ThinController and used it as an example, I also added the 
begin() method from BatchController to it (name actually called 
initSim()). This is because the begin method provides a transition point 
wherer the creation of the new thread occurs, making ThinController do 
alittle bit of thread startup management as well.


I'm concerned about the multiple methods used to "initialize" the 
Controller under different IController implementations.

1.) display() is used in the GUI Controller
2.) begin() is used in the BatchController
3.) nothing is really available in the ThinController

Would it be good to also have an "initialize()" style method that could 
be used to consolidate these different methods in IController?


public void initSim(){
	
	1.) in Controller this calls "display()"

	2.) in BatchController this calls "begin()"

	3.) a simple example in ThinController is attached.

}


I guess its a question of whether or not the setup should be done in a 
"Caller/Wrapper" or be done inside the IController. In this example it 
makes life easier in the caller. Given that BaseController is completely 
implemented in an asynchronous fashion, it is my opinion that 
Implementations that extend it should have at least some simple startup 
init like in display() (Controller) and begin() (BatchController).

Maybe if non-asynchronous control of the sim were wanted (simulation 
runs in the same thread as the controller). Then thread management 
issues would be managed in the Caller of the Controller, in which case, 
the controller would be very simplified. Maybe one would have 
AsynchronousBaseController and NonAsynchronousBaseController 
implementations with

Controller extends AsynchronousBaseController
BatchController extends AsynchronousBaseController
ThinController extends AsynchronousBaseController

and

SimpleController extends NonAsynchronousBaseController

this example would move threading issues completely out into the Caller.

These are just ideas, I'm sure of my opinion an this stuff, I'm not sure 
  how valuable something like SimpleController would really be. It might 
be usefull in situations where Parallel Processing is managed externally 
to the Repast Sim, like in massively parallel supercomputer systems.

Primarily, I think it would at least be wise to have something like 
initSim() in the IController.

-Mark

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

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

Forgot the jpg. Here is is.



On Mon, 2002-12-23 at 21:19, Andy Cleary wrote:
> 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.
> ============================================
> 
> 
> 
> -------------------------------------------------------
> 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
-- 
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)

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

Hi,

The basic idea is that a SimModel is created. A controller is then
created (either a Controller or a BatchController) and the model is
passed in the constructor. (An AbstractGUIController also has the
capability to load a model dynamically.) A SimModel contains a Schedule.
A Schedule is conceptually a priority queue containing BasicActions
queued according to the tick at they execute. Each call to
Schedule.execute() pops the next set of BasicActions off the queue and
executes them. By set of BasicActions, I mean all the BasicActions that
are scheduled for the same execution tick. When you run a model, a new
thread is created by the controller. The run() method of this Thread is
a loop that repeatedly calls execute on the Schedule associated with
that controller's model.

I've attached a jpg of a sequence diagram that illustrates the basic
sequence of calls. Any other questions please let me know.

ick





On Mon, 2002-12-23 at 21:19, Andy Cleary wrote:
> 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.
> ============================================
> 
> 
> 
> -------------------------------------------------------
> 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
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net