Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[geotrellis-dev] using GeoTrellis for agent-based modeling

Several weeks ago, Terrance started an interesting conversation about the application of GeoTrellis for agent-based modeling, but I think the conversation was buried in a discussion on unresolved dependencies.  I'm copying the thread below with a new subject line in the hope that there will be additional comments.

----------------------
I'm curious - have you guys ever looked into adding an "agency" layer to Geotrellis ? I have a strong interest in computational economics and situated agents in a GIS context and I suspect I'm not alone..

/Terry

----------------------

Terrance,

I really like your idea of applying GeoTrellis for agent-based modeling.  Other than a toy function for Conway's Game of Life cellular automata (http://geotrellis.github.io/scaladocs/0.9/index.html#geotrellis.raster.op.focal.Conway), as far as I know, we do not have anyone working on agent-based modeling, but the ability to distribute computation related to geospatially situated agents seems like a good potential application for GeoTrellis, and we'd welcome contributions or discussion of how to potentially support this use case.

Best,

Robert


--------------------
Thank you Robert for your considered and forthright response.

My previous query was largely notional as I'll certainly defer to you and your teams in-depth framework knowledge as to proceeding in these regards. In addition, I definitely make no claims of originality in terms of GIS Agent based Modelling although I have been impressed with the caliber of the GeoTrellis work and the two seem like a natural fit.

Yet, allow me to start by suggesting a few lines of discussion, from which we might open a new thread if you like:

Personally, my interests lay in engineering an accessible, comprehensive and modern agent based modelling & simulation environment / service. Specifically, this relates here to a) the study of population wide health economics and b) development of predictive analytics tools (predictive-terrain-modelling ?) vis-a-vis product / service complexity indices. While these areas may seem to some as highly specialized and complex, which they certainly can be -- the recent book "Agent Zero" by Joshua Epstein at The John Hopkins University provides an entertaining yet insightful perspective on the current published state-of-the-art in wide ranging situated agent-based models.

I'll also note that Epstein's software implementations rely heavily upon Netlogo. Equally, Epstein goes onto suggest there is a clear and pressing need / emphasis to efficiently model large scale problem domains (e.g. consider the criticality of population health within increasingly integrated local, regional, national and global economic flows). Needless to say, these modelling domains can be on the order of tens to millions of activeagents.. Consequently, scale is everything and robust cloud based computing (potentially using commercial or private clusters vis-a-vis Spark/Akka) is the order of the day. All of which certainly resonates with your observation of GeoTrellis' ability to effectively distribute computation.

That said the following two aspects I believe are key: 1) having a de facto standardized high level Domain Specific Language (DSL) and tooling for agent modelling and 2) benchmarked low level concurrency implementation details (given the increasing emergence of small low cost, potentially very energy efficient dense multi-core computers like Adapteva that can form the elements within private clusters). Indeed, both of these aspects - it could be argued - straddle the boundaries of GeoTrellis' framework functionally, so it is not clear to me at the moment whether you see these aspects as exterior or interior to GeoTrellis' core development path going forward ?

In lieu of your response, allow me to make a few other observations:

NetLogo
(pro)
- Increasingly written in Scala alongside legacy Java for large installed base offering potential good fit withGeoTrellis, Spark / Akka, etc.
- 15+ years in development with effective high level tools (BehaviourSpace, Shape editor, SystemDynamics)
- support for linkage / extensions to external tools (e.g. Mathematica, R, MATLAB, GIS, 3D, etc)
- well documented and understood semantics - ongoing development of external agent model monitoring and headless configs
(con)
- using Netlogo off-the-shelf with GeoTrellis implies loose coupling hence inefficient concurrency along with implementation overlap
- user runtime interaction with individual agents does not scale and is obsolete UI/UX
- need for better agent FSM modelling & testing to support Behaviour-Driven-Development
- Netlogo scheduling remains "discrete tick" and lacks Reactive FP capabilities
(possibility)
- fork new implementation of Netlogo as DSL directly on top of GeoTrellis (aka TrellisLogo ?) effecting consistently tighter concurrency & eliminating overlap
- programmatically continues to execute existing models at high performance utilizing Spark / Akka message-based asynchronous Concurrency, Redundancy, Persistence, Fail-over
- tight integration of "TrellisLogo" into GeoTrellis implies direct support for "map algebra" semantics avoiding generic GIS extension "bolt-on"
 
Adapteva / Parallella Cluster
(pro)
- Gen1 available now as 16x 1GHz 32bit superscalar floating-point RISC processor cores on internal 1Gbps 2D mesh interconnect front-ended with dual ARM9 cores coupled to FPGA for flexible wide selection of IO (e.g. HDMI, PCIe, etc)
- Gen2 emerging as 64x processor cores with upper theoretic limit of 4096 processors
- memory architecture based on flat map where each node has small local memory as unique addressable slice of the total 32-bit address space. 
- processor can access its own local memory and other processors memory through regular load/store instructions. Local memory system comprised of 4 separate banks, allowing for simultaneous memory access.
(con)
- FPGA runs quite hot, IO variants on future Gen need to be finalized and pushed to ASIC
- available memory footprints limited - may impact Spark RDD utility
- Linux running with co-thread support but still needs JVM port

Regards,
/T 

--------------------

Thanks Terrance.

I'd like to get a chance to respond to your comments on agent-based modelling, though I want to take some time and mull over your points before responding. Thanks for such a thoughtful post!

Cheers,
Rob

--------------------

Oh certainly... indeed it is an involved subject with a number of competing approaches and aspects to consider.

Yet I think there is nothing particularly etched in stone here, so please I would value your (and anyone else) consider opinions on the subject.

I should mention that I've had conversations about these thoughts both with academic and commercial IT interests. Usually, the former generally stress semantic consistency when computing and reasoning with these kind of "bots" as model (behaviour) validation remains a considerable effort. While the latter are quite concerned about execution efficiency and how best to utilize emerging dense multi-core devices. (BTW I find it curious that there now appears to be widening acceptance for asynchronous concurrency over more established shared-state synchronous techniques - odd that its taken this long)

Needless to say, I look forward to your response.

All the Best,
/T


------------------
Robert Cheetham

Azavea  |  340 N 12th St, Ste 402, Philadelphia, PA
cheetham@xxxxxxxxxx  | T 215.701.7713  | F 215.925.2663
Web azavea.com  |  Blog azavea.com/blogs  |  Twitter @rcheetham  and @azavea

Azavea is a B Corporation - we apply geospatial technology for civic and social impact
while advancing the state-of-the-art through research. Join us.


Back to the top