Feedback from users is very valuable to us in designing and improving NetLogo. We'd like to hear from you. Please send comments, suggestions, and questions to feedback@ccl.northwestern.edu, and bug reports to bugs@ccl.northwestern.edu.
The "Logo" part is because NetLogo is a dialect of the Logo language.
"Net" is meant to evoke the decentralized, interconnected nature of the phenomena you can model with NetLogo. It also refers to HubNet, the networked participatory simulation environment included in NetLogo.
NetLogo is written entirely in Java (version 1.4.1).
NetLogo itself: Wilensky, U. 1999. NetLogo. http://ccl.northwestern.edu/netlogo/. Center for Connected Learning and Computer-Based Modeling, Northwestern University. Evanston, IL.
HubNet: Wilensky, U. & Stroup, W., 1999. HubNet. http://ccl.northwestern.edu/netlogo/hubnet.html. Center for Connected Learning and Computer-Based Modeling, Northwestern University. Evanston, IL.
Wilensky, U. (year). Name of Model. URL of model. Center for Connected Learning and Computer-Based Modeling, Northwestern University. Evanston, IL.
To determine the URL for a model, visit our web-based version of the Models Library and click on the name of the model. An example model URL is: http://ccl.northwestern.edu/netlogo/models/PepperedMoths.
To determine the year, open the model from the NetLogo application and look in the copyright information at the bottom of the Procedures tab.
The license is given in the "Copyright" section of the NetLogo User Manual, as well as in the application's about box and the README file accompanying the download.
A quick summary of the license is that use is unrestricted, including commercial use, but there are some restrictions on redistribution and/or modification (unless you contact Uri Wilensky to arrange different terms).
We are in the process of reevaluating the language of the license in response to user feedback. In the future, we intend to send out a revised license.
At present, no. We are evaluating how best to distribute NetLogo when it is in a more mature state. Making the source available is one possibility.
We do understand, however, that it is important that NetLogo not be a closed and non-extensible platform. That is not our intention for the product. For example, NetLogo includes APIs so that NetLogo can be controlled from external Java code and users can write new commands and reporters in Java. (See "Controlling" and "Extensions" in the User Manual.)
We offer workshops from time to time. If a workshop has been scheduled, we will announce it on the NetLogo home page and on the netlogo-users group. If interested in this type of opportunity, please contact us at feedback@ccl.northwestern.edu.
The original StarLogo was developed at the MIT Media Lab in 1989-1990 and ran on a massively parallel supercomputer called the Connection Machine. A few years later (1994), a simulated parallel version was developed for the Macintosh computer. That version eventually became MacStarLogo. StarLogoT (1997), developed at the Center for Connected Learning and Computer-Based Modeling (CCL), is essentially an extended version of MacStarLogo with many additional features and capabilities.
Since then two multi-platform Java-based multi-agent Logos have been developed: NetLogo (from the CCL) and a Java-based version of StarLogo (from MIT).
The NetLogo language and environment differ in many respects from MIT StarLogo's. Both languages were inspired by the original StarLogo, but were redesigned in different ways. NetLogo's design was driven by the need to revise and expand the language so it is easier to use and more powerful, and by the need to support the HubNet architecture. NetLogo also incorporates almost all of the extended functionality of our earlier StarLogoT.
You can use the chart below to help familiarize yourself with the new features NetLogo has to offer.
| StarLogoT | NetLogo | Features |
|---|---|---|
| X | X | Fully programmable |
| X | X | Language is Logo dialect extended to support agents and concurrency |
| X | X | Interface builder w/ buttons, sliders, switches, choosers, monitors, and text boxes |
| X | X | Info area for annotating your model |
| X | X | Powerful and flexible plotting system |
| X | X | Agent Monitors for inspecting agents |
| X | X | Export and import model function (save and restore state of model) |
| X | Cross-platform: runs on MacOS, Windows, Linux, et al | |
| X | Models can be saved as applets to be embedded in a web page | |
| X | Unlimited numbers of agents and variables | |
| X | Double precision arithmetic | |
| X | Simplified language structure | |
| X | "Agentsets" make many programming tasks easier | |
| X | Syntax-highlighting code editor | |
| X | Rotatable and scalable vector shapes for turtles | |
| X | Exact on-screen turtle positioning | |
| X | Redesigned user interface | |
| X | Text labels for turtles and patches | |
| X | Many new primitives | |
| X | BehaviorSpace: a tool used to collect data from multiple runs of a model | |
| X | HubNet: participatory simulations using networked devices | |
| X | Java API for user extensions | |
| X | Java API for controlling NetLogo from outside | |
| X | "Headless" operation from the command line |
The best place to ask this question is on the NetLogo Users Group.
You should also check the Community Models section of our Models Library web page.
Yes. NetLogo's agent scheduling algorithms are deterministic, and NetLogo always uses Java's "strict math" library, which gives bit-for-bit identical results regardless of platform. But keep the following cautions in mind:
We at the CCL have hoped to write several NetLogo textbooks for quite some time. These could be aimed at different audiences, such as: middle school, high school, undergraduate course in modeling or complexity, practical guide for interested adults.
Unfortunately, we have not yet been able to find the time to make these happen. If people from the user community would like to collaborate on such a venture, please let us know. We would welcome it.
At present, NetLogo is available only in English.
We plan to eventually make it possible for users to produce their own foreign-language "packs" for NetLogo and share them with each other. In order to do this, we need to separate all of the English text from the rest of the source code, so that is separately editable. We're not sure when this will happen.
Short answer: interpreted, but we are working on a compiler.
Long answer: NetLogo does include a compiler, but the compiler does not produce native code, or even Java byte code. It produces a custom intermediate representation that can be interpreted more efficiently than the original code. However, we are working on a new compiler that will generate Java byte code. Once that is done, NetLogo will qualify as compiled, not interpreted. Since Java virtual machines have "just-in-time" compilers that in turn compile Java byte code all the way to native code, the new compiler should substantially improve the speed of NetLogo. We are not sure when the new compiler will be done.
Please write us at bugs@ccl.northwestern.edu and we'll either fix the problem with the form, or provide you with an alternate method of downloading the software.
At present, no. If this is a problem for you, contact us at feedback@ccl.northwestern.edu.
So far, users reporting this problem all used the "without VM" download option for Windows. Uninstall NetLogo and try the "with VM" download instead.
Even if the "with VM" download fixes it for you, please contact us at bugs@ccl.northwestern.edu so we can find out more details about your setup. We'd like to fix this in a future version, but to troubleshoot it we need help from users.
Yes. When you install NetLogo, the folder that is created contains has the version number in its name, so multiple versions can coexist.
On a Window system, whichever version you installed last will be the version that opens when you double click a model file in Windows Explorer. On a Mac, you can control what version opens via "Get Info" in the Finder.
Some of the files in the tarball have very long pathnames, too long for the standard tar format. You must use the GNU version of tar instead (or another program which understands the GNU tar extensions). On some systems, the GNU version of tar is available under the name "gnutar". You can find out if you are already using the GNU version by typing tar --version and seeing if the output says "tar (GNU tar)".
Current versions of NetLogo require that your web browser support Java 1.4.1 or higher. Here's how to get the right Java:
If you think you have the right browser and plugin, but it still doesn't work, check your browser's preferences to make sure that Java is enabled.
No. In order for the applet to operate, the model file must be accessible also.
When you use "Save as applet" on the File menu, the HTML page generated contains a link where the user can download the model file. If you want, you can remove that link. Doing so will make it harder for the user to access the model file, but not impossible.
Yes, but only to read files that are stored in the same directory on your web server as the HTML and model files. Applets cannot read files on the user's computer, only the web server.
A quick method is to use the three sets of black arrows in the upper left corner of the graphics window.
Another method is as follows. Select the Graphics Window by dragging a rectangle around it with the mouse. Click the "Edit" button in the Toolbar. A dialog will appear in which you may enter new values for "Screen Edge X" and "Screen Edge Y". (You can also right-click [Windows] or control-click [Mac] on the Graphics Window to edit it, or select it then double-click.)
NetLogo does not have a built-in set of painting tools for painting in the graphics window. But with only a few lines of code, you can add painting capability to your model. To see how it's done, look at Mouse Example, in the Code Examples section of the Models Library. The same techniques can be used to let the user interact with your model using the mouse in other ways, too.
Another possibility is to use a special drawing model such as the Drawing Tool model by James Steiner which is available from http://ccl.northwestern.edu/netlogo/models/community/.
A third possibility is to create an image in another program and import it. See the answer to Can I import a graphic into NetLogo?.
We have tested NetLogo with models that use hundreds of megabytes of RAM and they work fine. We haven't tested models that use gigabytes of RAM, though. Theoretically it should work, but you might hit some limits that are inherent in the underlying Java VM and/or operating system (either designed-in limits, or bugs).
The NetLogo engine has no fixed limits on size. On Macintosh and Windows operating systems, though, by default NetLogo ships with a 512 megabyte ceiling on how much total RAM it can use. (On other operating systems the ceiling is determined by your Java VM.)
Here's how to raise the limit if you need to:
# LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX # ------------------------------------- # allow the heap to get huge lax.nl.java.option.java.heap.size.max=536870912
<key>VMOptions</key> <string>-XX:+PrintJavaStackAtFatalState -Xms16M -Xmx512M</string>Note that (at least as of Mac OS X 10.3), the maximum possible heap size for any Java program is two gigabytes.
java -Xmx512M -jar NetLogo.jar
Yes. See Image Import Example, in the Code Examples section of the Models Library. This example contains NetLogo code that reads in image files stored in PGM (Portable GrayMap) format.
In a future version, we plan to make this a built-in capability of the language and support other input formats besides PGM.
We do not have built-in support for reading common GIS formats. However, a number of our users are working with GIS data succesfully using NetLogo code that reads GIS data using our file I/O primitives such as file-open. Image Import Example (in the Code Examples section of the Models Library) demonstrates this technique; it handles only the simple PGM (Portable GrayMap) image format, but the same techniques could be used to handle more complex data formats including GIS formats.
It is also possible to use external software to convert GIS data into a format that is easier to read from NetLogo than the original format. This has been discussed on the NetLogo Users Group several times. We encourage users interested in using NetLogo for GIS applications to share their questions and experiences with the group.
Here's some ways to make it run faster without changing the code:
to go no-display ... ... display end
In many cases, though, if you want your model to run faster, you may need to make some changes to the code. Usually the most obvious opportunity for speedup is that you're doing too many computations that involve all the turtles or all the patches. Often this can be reduced by reworking the model so that it does less computation per time step. If you need help with this, if you contact us at feedback@ccl.northwestern.edu we may be able to help if you can send us your model or give us some idea of how it works. The members of the NetLogo Users Group may be able to help as well.
Yes. There are two types of HubNet available. With Computer HubNet, participants run the HubNet Client application on computers connected by a regular computer network. In Calculator HubNet, created in conjunction with Texas Instruments, participants use TI-83+ graphing calculators and the TI-Navigator Classroom Learning System.
Note that Calculator HubNet works with a prototype version of the TI-Navigator system, and is not yet compatible with the commercially available TI-Navigator. We are actively working in partnership with Texas Instruments on integrating the new TI-Navigator with Calculator HubNet, which we expect to release in the near future.
For more information on HubNet, see the HubNet Guide.
Yes, this is supported via a Java API. Some light Java programming is required. See the "Controlling" section of the User Manual for details.
One instance of NetLogo can only have one model open at a time. (We plan to change this in a future version.)
You can have multiple models open by opening multiple instances of NetLogo, though. On Windows and Linux, simply start the application again. On Macs, you'll need to duplicate the application in the Finder, then open the copy. (This will use only a very small amount of additional disk space, since most of NetLogo is actually in the NetLogo.jar file, which is stored outside the application "bundle.")
Yes, using "Export Graphics" on the File menu, or by right-clicking (on Mac, control-clicking) the graphics window, or using the export-graphics command.
You can also use "Export Interface" or the export-interface command to save an image of the entire interface tab.
Yes. See the Movie section of the Programming Guide. Also see "Movie Example", in the Code Examples section of the Models Library.
Not for a single model run, no. The NetLogo engine is single threaded and we expect it to remain so.
You can take advantage of multiple processors to do multiple model runs concurrently, though, in either of two ways:
In a future version of NetLogo, we hope to improve the support for multiple processors as follows:
At present, no. In a future version of NetLogo, we plan to support this.
At present, no. In a future version of NetLogo, we plan to support this.
At present, no. In a future version of NetLogo, we plan to support this.
We don't have a document that specifically summarizes the differences between these two programs. If you have built models in StarLogoT before, then we suggest reading the Programming Guide section of this manual to learn about NetLogo, particularly the sections on "Ask" and "Agentsets". Looking at some of the sample models and code examples in the Models Library may help as well.
NetLogo 1.3.1 includes a StarLogoT model converter; you just open the model from the File menu and NetLogo will attempt to convert it. The converter doesn't do all that great a job though, so the result will very likely require additional changes before it will work. Note also that the model converter is no longer included in current versions of NetLogo, so if you have models you want to use it on, you will have to use NetLogo 1.3.1 to do the converting, then open the model in a current version.
If you need any help converting your StarLogo or StarLogoT model to NetLogo, please feel free to get in touch with us at feedback@ccl.northwestern.edu. The NetLogo Users Group is also a good resource for getting help from other users.
There is no standard definition of Logo; it is a loose family of languages. We believe that NetLogo shares enough syntax, vocabulary, and features with other Logos to earn the Logo name.
Still, NetLogo differs in some respects from most other Logos. The most important differences are as follows.
Surface differences:
The last three differences are illustrated in the following procedure definitions:
| most Logos | NetLogo |
|---|---|
to square :x output :x * :x end |
to-report square [x] report x * x end |
Deeper differences:
Of course, the NetLogo language also contains many additional features not found in most other Logos, most importantly agents and agentsets.
Torus is the only topology directly supported by NetLogo, but you can often simulate a different topology without too much extra effort.
If you want the world to be a bounded rectangle, you may need to add some code to your model to enforce this. Often a helpful technique is to turn the edge patches a different color, so turtles can easily detect when they "hit" the edge. Also, there are "no-wrap" versions of primitives such as "distance" and "towards"; these should help.
If you want your turtles to move over an infinite plane, you can simulate this by having the turtles keep track of their position on the infinite plane, then hide the turtle when it goes "out of bounds". The Random Walk 360 model in the Models Library shows you how to code this.
Simulating a spherical or other topology might be difficult; we haven't seen a model that does this. (If you have one, please send it in!)
Like this:
(- x)
The parentheses are required.
Moving forward 1 is only guaranteed to take a turtle to a new patch if the turtle's heading is a multiple of 90 (that is, exactly north, south, east, or west).
It's because the turtle might not be standing in the center of a patch. It can stand near the edge, or near the corner. So for example, suppose your turtle is close to the southwest corner of a patch and is facing northeast. The length of the patch diagonal is 1.414... (the square root of two), so "fd 1" will leave the turtle near the northeast corner of the same patch.
If you don't want to have to think about these issues, one possibility is to write your model in such a way that your turtles always come to rest on patch centers.
See previous answer. It's the same issue.
This might not be the meaning of "ahead" you were expecting. With patch-ahead, you must specify the distance ahead that you want to look. If you want to know the next patch a turtle would cross into if it moved forward continuously, that is possible to find out. See "Next Patch Example", in the Code Examples section of the Models Library.
The patch-ahead primitive is useful for letting a turtle see what is directly in front of it. If you want the turtle to look in another direction besides straight ahead, try patch-left-and-ahead and patch-right-and-ahead.
Those primitives let the turtle "look" at specific points. If you want the turtle to have a full "cone" of vision, see "Vision Cone Example", in the Code Examples section of the Models Library.
You can also find out the next patch a turtle would cross into if it moved forward continuously. See "Next Patch Example", in the Code Examples section of the Models Library.
We don't have such a command, although we plan to add one -- or perhaps several! In the meantime, though, you can use the without-interruption primitive to arrange exclusive interaction between agents. For example:
turtles-own [mate]
to setup
ask turtles [ set mate nobody ]
end
to find-mate ;; turtle procedure
without-interruption
[ if mate = nobody
[ let candidate random-one-of other-turtles-here
with [mate = nobody]
if candidate != nobody
[ set mate candidate
set mate-of candidate self ] ] ]
end
Using without-interruption ensures that while a turtle is choosing a mate, all other agents are "frozen". This makes it impossible for two turtles to choose the same mate.
This syntax was supported by StarLogoT and some beta versions of NetLogo, but was removed from NetLogo 1.0. Instead, for a patch variable write e.g. pcolor-of patch-at -1 0, and for a turtle variable write e.g. color-of one-of turtles-at -1 0.
See the "Math" section of the Programming Guide in the User Manual for a discussion of this issue.
See "One Turtle Per Patch Example", in the Code Examples section of the Models Library.
When a turtle dies, it becomes equal to "nobody". So for example:
if turtle 0 != nobody [ ... ]
You could also use is-turtle?:
if is-turtle? turtle 0 [ ... ]
NetLogo does not automatically keep track of this. If you want to keep track of the passage of time, add a global variable to your model with a name like "clock" or "steps". In your setup procedure, set the variable to 0. In your go procedure, increment the variable. Many of the models in the Models Library use this technique.
The reason NetLogo doesn't automatically keep track of this is that NetLogo is very flexible about letting you make buttons that do anything that you want them to. NetLogo has no one way of knowing which of your buttons should advance the clock and which shouldn't.
What NetLogo calls "lists" are actually implemented internally as arrays, so they have some of the performance characteristics of arrays. For example, random access (using the item reporter) takes constant time. However, they're immutable arrays (they cannot be altered except by making a copy and altering the copy), so replace-item is linear time, not constant-time (because the whole array is copied).
For most purposes, the performance differences between lists and arrays doesn't matter; it only matters if you're dealing with very long lists.
In a future version of NetLogo we plan to change our lists to be ordinary singly linked lists as in other Logo (and Lisp) implementations. At the same time, we will also provide real, mutable arrays as a separate data type.
No, but you can use lists to accomplish the same thing. See:
The in-radius primitives lets you access circular neighborhoods of any radius.
The neighbors primitive gives you a Moore neighborhood of radius 1, and the neighbors4 primitive gives you a Von Neumann neighborhood of radius 1.
If you want a Moore or Von Neumann neighborhood of a different radius, or a different kind of neighborhood altogether, you can define it yourself, using the at-points primitive and/or other techniques. If the neighborhoods do not change over time, then the most efficient way to use them is to compute the neighborhoods only once, ahead of time, and store them in agentsets. See this URL for a discussion and example code: http://groups.yahoo.com/group/netlogo-users/message/377.
Yes. See "Network Example", in the Code Examples section of the Models Library.
We plan to support this more directly in a future version of NetLogo.
Here's how to convert an agentset to a list of agents:
values-from <agentset> [self]
And here's how to convert a list of agents to an agentset:
turtles/patches with [member? self <list>]
For a discussion of the whole issue of agentsets versus lists of agents, see:
This is possible, but the code for it is a bit awkward:
foreach shuffle values-from <agentset> [self]
[ ask ?
[ ... ] ]
First, values-from converts the agentset into a list of agents. Then, shuffle randomizes the order of that list. Finally, foreach is used to walk through the list, asking each agent in term. The question mark is used with foreach to refer to the current item in the list.
We plan to support this more directly in a future version of NetLogo.
If you ask turtles, or ask a whole breed, the turtles are scheduled for execution in ascending order by ID number. If you ask patches, the patches are scheduled for execution by row: left to right within each row, and starting with the top row.
If you ask a different agentset besides the set of all turtles or patches or a breed, then the execution order will vary according to how the agentset was constructed. The execution order is chosen deterministically and reproducibly, though, and will remain the same if you ask the same agentset multiple times.
In a future version of NetLogo, we plan to add an option for randomized scheduling.
Once scheduled, an agent's "turn" ends only once it performs an action that affects the state of the world, such as moving, or creating a turtle, or changing the value of a global, turtle, or patch variable. (Setting a local variable doesn't count.)
To prolong an agent's "turn", use the without-interruption command. (The command blocks inside some commands, such as cct and hatch, have an implied without-interruption around them.)
NetLogo's scheduling mechanism is completely deterministic. Given the same code and the same initial conditions, the same thing will always happen, if you are using the same version of NetLogo.
In general, we suggest you write your NetLogo code so that it does not depend on a particular scheduling mechanism. We make no guarantees that the scheduling algorithm will remain the same in future versions.