Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
(summary of development activity as of April 2013; other wiki pages may have more current information)
This new version will replace the NetLogo applet, which was our old way of running simulations in the browser. Our applet ran on the JVM (Java Virtual Machine). But JVM applets don't work on mobile devices and are a dying technology even on the desktop, due to security problems, slow load times, and other issues. They are no longer suitable for use in schools.
Our top priorities for this work are:
- backwards compatibility with the existing NetLogo language and existing NetLogo models
- embeddability, including integration with Concord Consortium's Lab environment
Uri Wilensky is overseeing the Northwestern team and directing the design. Seth Tisue is the technical lead and is doing the main work on the new compiler and agent engine code, with some open-source participation from Josh Cough. Jason Bertsche and Bryan Head are building the server-side web app, the browser front end (the latter based on an initial prototype by Philip Woods), and the Canvas-based renderer. Nicolas Payette is responsible for the event-sourcing code in server-side NetLogo. Our main technical liaison at Concord Consortium is Stephen Bannasch.
The first phase of work involved evaluating and selecting technologies.
Like NetLogo (since 2011), our new work is open source software, under the same license, the GNU GPL (GNU General Public License). Source code, plans, and design documents are in public repositories hosted on GitHub. Development work is discussed in the open on a public mailing list, netlogo-devel, hosted on Google Groups.
Our web framework of choice for server-based applications is Play 2. We're using WebSockets for client/server communication; not every browser in the field currently supports them but we expect that will change soon. Using WebSockets has somewhat restricted our choice of virtual server hosting; we tried Heroku and dotCloud but they don't currently offer WebSockets and the workarounds they offer are cumbersome. Currently we are hosting our web apps on Linode.
For 2D rendering in-browser we are using Canvas. We have conducted some performance experiments with SVG+D3 instead, but with disappointing results; still, this is a decision we may revisit in the future.
We are targeting modern browsers only, on the assumption that in just a couple years today's cutting edge browsers will be in widespread use.
We have built several prototype systems to evaluate technology choices and explore possible designs and architectures.
The first prototype of what would eventually become Teletortoise (see below) was Wolf. It used the Play framework and WebSockets to run a headless NetLogo instance on the server, accept commands from a browser-based command center, and display the results by rendering PNG images on the server. No actual code from Wolf survived into later versions, but the project helped cement our confidence in Play and WebSockets.
Bryan Head re-implemented some well-known NetLogo models directly in CoffeeScript, in a prototype project he called WebLogo. This was our first experience with CoffeeScript and we found that we liked the language and that the performance was surprisingly good.
Although we didn't build it ourselves, we've been closely monitoring Redfish Group's AgentScript project, which (like WebLogo) involves writing NetLogo-like models in CoffeeScript. We expect to learn a lot from their experiences and possibly share code in the future.
To pilot integration of NetLogo with Data Games (a data graphing and analysis environment), we built a JSON data exporter for BehaviorSpace that output NetLogo parameter-sweeping experiment results in a format that was readable by Data Games to visualize and explore the data in both graph and table form. This worked well and will serve as a basis for future, closer integration between NetLogo and Data Games.
Although we aim to jettison applets in the long run, for prototyping we continue to support the applet version of NetLogo, which with our assistance was integrated by Concord Consortium into their Lab environment. In this applet-based prototype, data from a running NetLogo simulation is displayed live in both graph and table form in Data Games.
Tortoise and Teletortoise
We are simultaneously pursuing two approaches for running NetLogo simulations in the browser. Our code names for these two approaches while they are still under development are “Tortoise” and “Teletortoise”.
Teletortoise is a hybrid client/server system where the simulation runs on the server using the JVM version of NetLogo, using the browser only to render the results (including live animation of simulation progress).
Both Tortoise and Teletortoise are important to NetLogo's future. Teletortoise isn't just a prototype of the eventual Tortoise system, but will continue to exist on its own. There are pros and cons to both approaches:
- Tortoise requires little or no server-based support and is not limited by bandwidth.
- On the other hand, Teletortoise supports the full feature set of JVM-based NetLogo now, features that will take years to duplicate in Tortoise. It also supports existing JVM-based extensions.
- Teletortoise will serve as the basis for our next-generation HubNet technology for participatory simulations.
Tortoise is a single-user system, since the simulation is running in the user's own browser, but Teletortoise is a multi-user system, where any number of participants can observe and control the same model run together and discuss it in the integrated chat room.
This is possible because both Tortoise and the JVM-based NetLogo have an “event-sourced” architecture, where running a simulation generates a stream of state-change events, which can then be received and rendered separately. In Tortoise, the events are both generated and handled by the browser. In Teletortoise, the events come from the server.
Since server-side NetLogo and Tortoise both generate the same events, the same browser front end can be used for display and interaction with either back end. Regardless of where the events are coming from, they can be handled uniformly.
Events can also be recorded and replayed later, so this architecture can be used to play back previously recorded model runs. Event types include agent state changes, drawing events (pen marks and stamps), and plotting events. (This year, we substantially rewrote NetLogo's plotting and drawing subsystems so they generate these new events.)
This event-sourced architecture was originally developed for model runs recording and replay for our ModelSim project, but we had in mind all along that we would also use it for Tortoise, Teletortoise, and HubNet.
The Tortoise compiler is written in Scala 2.11 and reuses the early phases of the existing NetLogo compiler. This year we substantially reworked several major components of the compiler in order to make them usable by Tortoise, most significantly, a full rewrite of the first phase of the NetLogo parser. The various phases of compilation were refactored and divided into a “front end” and “back end”, with the front end consisting of only the phases used by Tortoise.
The Tortoise compiler currently supports the following subset of the language:
- complete NetLogo syntax (since the real parser is used)
- literals (numbers, strings, booleans, and lists)
- procedure definitions (
- arithmetic operators:
+ – * / = != < > <= >=
Not all of these features are implemented in their full generality, but basic uses are supported.
Other Tortoise components
Besides the compiler and the user interface, the other remaining major components of Tortoise are the event coalescer, the engine, and the renderer.
The update coalescer receives a stream of events from the engine (the Tortoise engine in the browser, or the Teletortoise engine running on the server) and merges them as they come in, resulting in a representation of the current state of the system as input to the renderer.
The renderer draws the current state of the turtles and patches in an HTML5 Canvas.
All of these components are written in CoffeeScript.
Bringing it all together
Our first major goal was to build a complete, working system as soon as possible, end to end, with a rough minimal version of every component in place, and a basic suite of automated tests passing. We successfully achieved this goal, with the first version of Tortoise going online in February, and initial integration of Teletortoise with the Lab environment achieved shortly thereafter.
The models we have working so far in Tortoise are Life and Termites. (We plan to tackle Climate Change and Wolf-Sheep Predation next, but to implement these, we'll need to support turtle breeds. Turtle breeds are just one of many NetLogo language features that the compiler doesn't support yet.)
Even without any significant performance tuning work having been done, Tortoise is already only about 10x-15x slower than the JVM NetLogo. We expect to close much of that gap in the future. (Note this figure is engine performance only; we haven't benchmarked graphics rendering performance yet.)
This first version of Tortoise works on both desktop browsers and iOS-based mobile devices (iPhones and iPads). It doesn't currently work on Android devices, but we plan to address that.
Run them yourself online
- Teletortoise embedded in Lab: