Re: [Repast-developer] RePast and extensibity

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

Jason, I'm going to forward this back onto the list without the 
attachments, this is good stuff.

Jason Woodard wrote:

> Mark,
> 
> Please excuse this private response to your recent repast-developer
> post.  I should probably post back to the list, but wanted to run
> these ideas by you first to see if you think I'm crazy.  I've also
> copied Gulya; he and I talked briefly about some of this stuff in
> Santa Fe last month.
> 

No this is great, I was unsure who around the Harvard Community was 
using RePast. We should really plan to get together once your back on 
the 25th.

> I totally agree that RePast is reaching a limit in terms of
> integrating third-party functionality.  There is also an increasing
> demand in the modeling community for models that are themselves built
> from modular components.  For example, Gulya has the beginnings of a
> GA library that lots of people could benefit from if it were packaged
> appropriately.  I'm working on a library for network formation models
> that I'd like to make available for others to reuse and extend.  In
> fact, if we're really going to make cumulative scientific progress
> using ABM, it should probably become the norm that most models are
> designed this way, not just code intended to be used as a library.
> (This is orthogonal to the idea of "docking" to replicate results,
> which I also believe is important.)
> 
> Maybe these are really two distinct problems--layers architecturally
> "above" vs. "below" RePast--requiring distinct solutions.  I don't
> have any experience with Geotools or Java3D, so I'm not sure I can be
> very helpful with the particular API / data structure mapping scheme
> you proposed.  (That said, I am looking for ways to link Mathematica
> and CPLEX to RePast models, so I would certainly be a consumer of such
> a pluggability layer.) 

I was looking into Mathematica online, they have a substantial "JNI" 
based API for Mathematica call J/Link.

http://www.wolfram.com/solutions/mathlink/jlink/

I think I'll be looking into this a little deeper. I've been working on 
a math/stat api at apache as well:

http://jakarta.apache.org/commons/sandbox/math

I think that there are some interesting features of this library that I 
can take to that project too. Specifically the "Eval" Class.


> But if you think it's worth thinking about the
> modular-model issue within the same scope, I would be very interested
> in collaborating.
> 
> I've attached some code I cobbled together to explore the idea of a
> "harness" for RePast models, where a model can register modules it
> requires, whose build and step methods are then automatically called
> at the appropriate time.  The goal is to allow modules to be designed
> and used independently of a particular model.  I've used the new Java
> Preferences API to allow module (and model) parameters to be read
> from a single configuration file, and the new Logging API to allow
> modules to handle output in a flexible but consistent way.  I can see
> how your Jelly tag library could be used to tie everything together
> for scripting and batch mode execution.
> 

This is interesting, it reminds me of the nesting capabilities of Swarm. 
It is also an interesting "twist" on the work I've been doind with Jelly 
and BCEL. I might recommend that you look into the work that Nick has 
done with "trove" to handle some of oyu "reflection" based stuff going 
on in SimHarness. Trove and BCEL are both "bytecode" engineering 
libraries that can be used to generate "class wrappers" which call the 
method directly in the class instead of having to use reflection to look 
it up (this can be expensive in a simulation).

I have some BCEL wrappers in my Jelly Project which basically provide 
dynamic "extension" wrappers on top of a a SimModel Implementation. This 
is how I can execute jelly script when a setup or begin method is called 
in the model. What this really provides is a "harness" that extends a 
user written model.

> Speaking of which, another "itch" I've had for a while is the build
> and distribution process, both for RePast itself and for individual
> models. I know Gulya is wary of making things too complicated for
> non-technical users, but I think there's a real void here.  We are
> getting to the point where it's not unreasonable to expect people to
> have or install JDK 1.4 and Ant, and with those as a foundation many
> things are possible that would make it much easier for novices and
> experts alike, from simply getting the classpath right, to installing
> optional libraries, to deploying models as web applications.
> 
 > regards,
 > 	-j
 > Jason Woodard
 > jwo...@hb...
 > ja...@ee...

Theres a long standing argument about the amount of java technical 
experience a RePast model developer should have. Its a tough call, I 
think there should be "basic" and "advanced" tutorials and a "continuum" 
of usability. One of the big delema's I tend to see when 
researchers/developers are putting together these extensions to RePast 
that are supposed to "simplify" it for the user (like SimpleModel, your 
harenss, SimBuilder or my Jelly packages). The caution is that by 
"layering" these support classes ontop of RePast we risk breaking the 
continuum of usability so that the intermediate user has to learn new 
interfaces and API's to gain greater control over the model in thier code.

Being able to call RePast from within an application such a Mathematica 
presents us with a really interesing situation because the rift between 
the two environments is a language one that would need to be spanned 
with something like JNI. There are alot of questions that arise - Would 
we to be able to provide all the functionality of a RePast SimModel, 
Controller and Schedule from within Mathematica? Would we want to 
provide bridges such that "Mathematica evaluations" coulds be executed 
from within the RePast model? Or would we want to provide more 
simplified access to one of these "hareness/wrappers" that we have develop?

There are all kinds of discussions this can generate.

-Mark
> 
> -----Original Message-----
> From: rep...@li...
> [mailto:rep...@li...] On Behalf Of Mark
> R. Diggory
> Sent: Tuesday, August 12, 2003 9:29 AM
> To: repast-developer
> Subject: [Repast-developer] RePast and extensibity
> 
> 
> I'm curious what others think about RePast in relation providing support
> 
> for features such as Java3D and Geotools. I think we start to really 
> reach an unrealistic limit in terms of packaging all this functionality 
> directly into RePast as one monlithic project. It also becomes 
> questionable as to whether RePast gets added to GeoTools (or any other 
> Platform) or the other way around during this extension process.
> 
> Maybe it would be wise to begin a goal of defining a "plugability" layer
> 
> for RePast such that the "core" features of RePast can be isolated from 
> the "extensions".  This way one can either use the "bare-bones" of 
> RePast in thier project without having to drag along all the features 
> they may not actually be interested in, or they can provide an extension
> 
> to RePast itself if it is acting as the framework.
> 
> Mostly, these extensions tend to be isolated in the area of rendering. 
> But they do also involve mapping between various datastructures in both 
> RePAst and the Framework of question. It would be logical to consider in
> 
> the future that plugging RePAst into "X" platform will involve providing
> 
> "Graphical" and "Nongraphical" bindings to and from that framework.
> 
> 
>       RePast                             Platform X
> 
> 
> 1.) Implementatation of RePast space, graph or topology interfaces in 
> external API's for execution from within RePast.
> 
> RePast Interfaces <-- Platform X Data Structures
> 
> 2.) Mapping model data structures to an external rendering engine.
> 
> RePast Model Data Structures --> Platform X Rendering Engine
> 
> 3.) Exposing model controls and properties to external platform.
> 
> RePast Model Properties/Controls <-- Platform X
> 
> As we are starting to do to more of this "extension" these days. It 
> would be wise to begin such discussions while the interest is there. 
> This can happen at a couple of levels both internally to RePast with its
> 
> own displays/controls and external to RePast in relation to GeoTools and
> 
> other platforms that we are interested in "interfacing" with RePast.
> 
> -Mark
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
> /01
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer