Feedback from users is very valuable to us in designing and improving NetLogo. We'd like to hear from you. (See Contacting Us.)
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, including network phenomena. It also refers to HubNet, the multiuser participatory simulation environment included in NetLogo.
If you use or refer to NetLogo, HubNet or a model from the NetLogo models library, we ask that you cite it as follows:
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.
The correct citation is included in the "Credits and References" section of each model's Info tab.
NetLogo was first created in 1999 by Uri Wilensky at the Center for Connected Learning and Computer-Based Modeling, then at Tufts University in the Boston area. NetLogo grew out of StarLogoT, which was authored by Wilensky in 1997. In 2000, the CCL moved to Northwestern University, in the Chicago area. NetLogo 1.0 came out in 2002, 2.0 in 2003, 3.0 in 2005, 4.0 in 2007, 4.1 in 2009, and 5.0 in 2012.
NetLogo is written mostly in Scala, with some parts in Java. (Scala code compiles to Java byte code and is fully interoperable with Java and other JVM languages.)
The original StarLogo began at the MIT Media Lab in 1989 and ran on the Connection Machine. Later versions were developed for Macintosh computers: MacStarLogo (1994, MIT) and StarLogoT (1997, Tufts).
Today there are two StarLogo descendents under active development: NetLogo (from the CCL at Northwestern University) and StarLogo TNG (from MIT). NetLogo is the most widely used agent-based modeling environment in both education and research. StarLogo TNG is distinguished by its programming interface based on colored blocks.
NetLogo is free, open source software under the GPL (GNU General Public License), version 2, or (at your option) any later version.
Commercial licenses are also available. To inquire about commercial licenses, please contact Uri Wilensky at email@example.com.
The source code is on GitHub, here. Development discussion is on the netlogo-devel group.
The User Manual is published under a Creative Commons Attribution-ShareAlike license (CC BY-SA 3.0).
Source code for all of the extensions bundled with NetLogo is on GitHub, here. Most of the extensions are in the public domain (CC0 notice). Other extensions are released under open source licenses. See each extension's README for details.
The Code Examples in the Models Library are in the public domain (CC0 notice).
The rest of the models in the Models Library are provided under a variety of licenses. Some are public domain and some are open source, but most are under the Creative Commons Attribution-ShareAlike license (CC BY-NC-SA), which is not an open source license, though the models are free for noncommercial distribution and use.
See each model's Info tab to check its particular license.
The models are in a public Git repository here.
We offer workshops from time to time. If a workshop has been scheduled, we will announce it on the NetLogo Users Group.
The CCL has published a textbook (written by the author of NetLogo) that gives an introduction to agent-based modeling methods using NetLogo. It goes step by step with coding examples how to design, build, revise, and analyze models. And it presents some advanced techniques.
See www.intro-to-abm.com for more information on that textbook.
See the Textbooks section of our Resources page.
We at the CCL have hoped to write several more NetLogo textbooks. 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 anyone from the user community would like to collaborate on such a venture, please let us know. We would welcome it.
Volunteers have translated the user manual into Chinese and Czech. The translated versions are available from the NetLogo web site.
So far, the NetLogo user interface has been localized in English, Spanish, Chinese, and Russian. All four languages are included in the standard download.
We are seeking volunteers to complete and improve these localizations and to translate the NetLogo software and manual into as many other languages as possible. If you're able to help in this endeavor, please contact us.
Short answer: some of both.
Long answer: NetLogo does include a compiler that generates Java byte code. However, this compiler does not yet support the entire language, so some parts of user code remain interpreted. Note that our compiler generates Java byte code, and Java virtual machines have "just-in-time" compilers that in turn compile Java byte code all the way to native code, so much user code is ultimately translated to native code.
Try looking at the NetLogo Models Library, the NetLogo Modeling Commons, our Community Models page, and our list of references to NetLogo in outside works.
You might also ask the question on the NetLogo Users Group and/or search past messages on the group.
Yes. NetLogo's pseudorandom number generator and 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:
For now, yes. NetLogo 3D is included with NetLogo, but it is still a separate application.
Ideally a single unified application would support both 2D and 3D modeling. We would design the 3D world support so it doesn't get in the way when you are building 2D models. Models built in NetLogo 3D might require changes in order to run in the hypothetical unified application.
No. Neither iOS, nor Android, nor Windows RT supports running Java applications such as NetLogo.
For technical details on this new project, go here.
Yes. When you install NetLogo, the folder that is created contains has the version number in its name, so multiple versions can coexist.
On Windows systems, whichever version you installed last will be the version that opens when you double click a model file in Windows Explorer. On Macs, you can control what version opens via "Get Info" in the Finder.
Some of the files in the tarball have 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)".
It depends on which platform you are using.
Linux: Untar NetLogo into the appropriate place.
Mac: Copy the NetLogo directory from the disk image into the Applications folder.
Run the installer from the command line using the -q option:
The without-Java installer automatically searches for appropriate Java installations on your machine. If you wish to direct NetLogo to a particular installation you may do so by setting the environment variable NETLOGO_JAVA to the full path of the installation.
No. We don't recommend it. Details here.
In Java 7 Update 51, released in 2014, Oracle changed applet security requirements such that NetLogo applets no longer work for most people. Details here.
Yes. NetLogo runs fine from any file system, including read-only file systems.
Your computer is switching to power saving mode when unplugged. It's normal for this to reduce speed a little, but unfortunately there is a bug in Java that drastically slows down Swing applications, including NetLogo.
One workaround is to change the power settings on your computer so it doesn't go into power saving mode when you unplug it. (If you do this, your battery won't last as long.)
Another workaround is to run NetLogo with an option recommended by Oracle, by editing the NetLogo 5.2.vmoptions file, found in the NetLogo directory (under Program Files on your hard drive, unless you installed NetLogo in a different location). Add on a new line:
You can see the details of the Java bug and vote for Oracle to fix it here.
For backwards compatibility, the 5.x line of NetLogo will continue to require that Java 6 from Apple be installed. While this is not optimal for users who wish to keep up to date with their software, the effort to move away from Java 6 in NetLogo 5.x was deemed too great.
Future versions of NetLogo will run on newer versions of Java, requiring at least Java 7.
We recommend Oracle's Java runtime when using NetLogo on Linux.
In theory, any Java 6 or later runtime will run NetLogo. In practice, some Java implementations aren't high enough quality. Recent versions of OpenJDK should work; older ones may not. GNU libgcj does not work.
Ubuntu users should consult http://help.ubuntu.com/community/Java.
A nearly certain fix is to use a text editor to edit the NetLogo 5.2.vmoptions file (found in the NetLogo directory, by default in C:\Program Files):
Try changing the 1024m a smaller number like 512m. This should permit NetLogo to start, although the lower heap size limit may affect your ability to run models with many agents. (See How big can my model be?.)
If running with the lower heap size limit is unacceptable, read on.
Some Windows systems have trouble allocating large amounts of contiguous virtual memory. Upgrading to a newer version of Windows may help.
Running Windows in 64-bit mode instead of 32-bit mode may also help. Double check that Windows is actually running in 64-bit mode; see Microsoft's FAQ page on 64-bit Windows.
Yes. The easiest way is to set up your model run or runs as a BehaviorSpace experiment. No additional programming is required. See the BehaviorSpace Guide for details.
Another option is to use our Controlling API. Some light Java programming is required. See the Controlling API Guide for details and sample code.
Only when using BehaviorSpace. BehaviorSpace does parallel runs, one per processor.
For a single model run, only one processor is used.
We are seeking funding to make it possible to split a single model run across multiple processors or multiple computers.
Many of the same comments in the previous answer apply. It is not possible to split a single model run across multiple computers, but you can have each machine in a cluster doing one or more separate, independent model runs, using either BehaviorSpace or our Controlling API. We don't have automated support for splitting the runs across clusters, so you'll need to arrange that yourself.
Various users are already using NetLogo on clusters, with a variety of hardware and software. You can seek them out on the NetLogo Users Group.
Yes. NetLogo auto-saves files as you are working on them. The auto-save files can be found in your OS-specific temporary directory. On most Unix-like systems (including MacOS) that is /tmp. On Windows XP, logs can be found in C:\Documents and Settings\<user>\Local Settings\Temp, where <user> is the logged in user and on Windows Vista the logs can be found in C:\Users\<user>\AppData\Local\Temp. The files are named according to the following format: autosave_yyyy-MM-dd.HH_mm_ss.nlogo where the time and date are the time and date the model was opened.
The only way NetLogo can make your model run faster is by updating the view less frequently. As you move the speed slider to the right, view updates become less and less frequent. Since view updates take time, that means more speed.
However, fewer updates also means that the updates come farther apart. When several seconds pass between updates, it may seem like your model has stopped. It hasn't. It's running at full speed. Watch the tick counter! (If your model uses it. If it doesn't, watch something else, like a plot.)
To get a feel for what's going on, try moving the slider to the right gradually rather than suddenly. If you find the updates too infrequent at the rightmost position, just don't push the slider that far.
NetLogo does not have a built-in set of painting tools for painting in the view. 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 create an image in another program and import it using the import items on the File menu or the import-* primitives.
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. By default, though, NetLogo ships with a one-gigabyte ceiling (or 512 MB on some Windows systems) on how much total RAM it can use. If your model exceeds that limit, you'll get an OutOfMemoryError dialog.
If you are using BehaviorSpace, note that doing runs in parallel will multiply your RAM usage accordingly.
Here's how to raise the limit if you need to:
<key>VMOptions</key> <string>-XX:MaxPermSize=128m -Xmx1024m</string>
-Xmxnumber to the desired value.
On all platforms, the JVM may not be able to use all of the RAM on your system to run NetLogo unless you are running a 64-bit OS on a 64-bit JVM. On recent Macs running recent Mac OS X versions, the JVM is always 64-bit and you don't need to do anything special. On Windows and Linux, you may need to make configuration changes in order to switch from 32-bit to 64-bit mode. The members of the NetLogo Users Group may be able to help with this.
Yes, many users are using GIS data with NetLogo. The most complete way to do that is with the GIS extension. See the GIS Extension Guide.
A simpler way is to use import-pcolors, but that only works for importing maps that are images, not maps in other formats.
It is also possible to write NetLogo code that reads GIS data using our file I/O primitives such as file-open. For example, see the Grand Canyon model in the Earth Science section of Sample Models.
Here's some ways to make it run faster without changing the structure of the code:
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. The members of the NetLogo Users Group may be able to help with this.
The profiler extension is useful for identifying which parts of your code are taking the most time.
Unless you are running the exact same strings over and over, using run and runresult are much slower than running code directly; you should avoid using these primitives on fresh strings in performance-critical code.
One instance of NetLogo can only have one model open at a time. (Unfortunately, it is unlikely that this will change in a future version, due to the engineering difficulties involved.)
You can have multiple models open by opening multiple instances of NetLogo, though. On Windows and Linux, simply start the application again. On a Mac, you'll need to duplicate the application (not the whole folder, just the application itself) in the Finder, then open the copy. (The copy takes up only a very small amount of additional disk space.)
On an experimental basis, this is available using the __includes keyword.
This is answered in detail at the end of the Programming Guide.
See the Transition Guide for help.
Any of these ways:
(- x) -1 * x 0 - x
With the first way, the parentheses are required.
If you have disabled wrapping at the world edges in your model, then the turtle might be at a world edge and unable to move any further. You can test for this using can-move?.
Assuming the turtle isn't hitting a world edge, 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 might be near the corner of a patch. 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 next question.
A turtle is on a patch center when its xcor and ycor are integers.
You can move a turtle to the center of its current patch with either of these two equivalent commands:
move-to patch-here setxy pxcor pycor
But you'll never need to do that if you never allow turtles off of patch centers in the first place.
The sprout command creates turtles on patch centers. For example:
ask n-of 50 patches [ sprout 1 [ face one-of neighbors4 ] ]
Another way for a turtle to start on a patch center is with a command such as this line of turtle code, which moves it to the center of a random patch:
move-to one-of patches
Once a turtle is on a patch center, as long as its heading always stays an exact multiple of 90 (that is to say, due north, east, south, or west), and as it long as it moves forward or back by integer amounts, it will always land on patch centers.
See Random Grid Walk Example, in the Code Examples section of the Models Library, to see these code snippets in use.
See the answer two answers up. 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, it is possible to find that out. See Next Patch Example, in the Code Examples section of the Models Library.
You can use in-radius to let a turtle see a circular area around it.
Several primitives let the turtle "look" at specific points. 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.
If you want the turtle to have a full "cone" of vision, use the in-cone primitive.
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.
No. If you want to make marks that agents can sense, use patch colors.
See the "Math" section of the Programming Guide for a discussion of this issue.
It really doesn't matter. Even if 1 were a possible result, it would only come up approximately 1 in 2^64 tries, which means you'd be waiting hundreds of years before it ever came up exactly 1.
Nonetheless, if you are convinced that it really must be possible to get 1, you can use precision to round your answer to a certain number of decimal places. For example:
print precision (random-float 1) 10 0.2745173723
(If you use this method, note that 0 and 1 are only half as likely to come up as other answers. To see why this is so, consider the case where you only keep one digit after the decimal point. Results between 0 and 0.5 get rounded to 0, but results between 0.5 and 1.5 get rounded to 1; the latter range is twice as large. If you want 0, 0.1, 0.2, ..., 0.9, and 1 to all be equally likely, an alternative is to write random 11 / 10; this gives all 11 answers with equal probability.)
See One Turtle Per Patch Example, in the Code Examples section of the Models Library.
When a turtle dies, it turns into nobody. nobody is a special value used in NetLogo used to indicate the absence of a turtle or patch. So for example:
if turtle 0 != nobody [ ... ]
You could also use is-turtle?:
if is-turtle? turtle 0 [ ... ]
Nearly all models should just use lists for this.
The usual motivation for using arrays in other programming languages is that they provide fast random access (item) and mutation (replace-item). But NetLogo's lists, even though they are immutable, now provide near constant time performance on these operations.
Lists in earlier versions of NetLogo (4.1 and 4.0) were simple singly-linked lists and therefore these operations took linear time. The data structure underlying NetLogo's lists now is the immutable Vector class from the Scala collections library. It uses 32-wide hash array mapped tries, as implemented by Tiark Rompf, based in part on work by Phil Bagwell and Rich Hickey.
If you are certain you want to use raw, mutable JVM arrays in your model, they are provided by the array extension. See the Arrays & Tables section of the User Manual.
Yes, using the table extension. See the Arrays & Tables section of the User Manual.
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.
For Moore or Von Neumann neighborhoods of a larger radius, see Moore & Von Neumann Example in the Code Examples section of the Models Library.
If you want the list in a particular order, use the sort or sort-by primitives. The Lists section of the Programming Guide explains how to do this. See also Ask Ordering Example, in the Code Examples section of the Models Library.
If you want the list in a random order, here's how:
[self] of <agentset>
Because all operations on agentsets are in random order, the resulting list is in random order.
To convert a list of agents to an agentset, use the turtle-set, patch-set, or link-set primitives.
To stop a foreach from executing you need to define a separate procedure that contains only the foreach, for example:
to test foreach [1 2 3] [ if ? = 2 [ stop ] print ? ] end
This code will only print the number 1. The stop returns from the current procedure so nothing after the foreach will be executed either. (If the procedure is a reporter procedure, use report instead of stop.)
If a list contains only constants, you can write it down just by putting square brackets around it, like [1 2 3].
If you want your list to contain items that may vary at runtime, the list cannot be written down directly. Instead, you build it using the list primitive.
This is normal when doing multiple runs in parallel. For a discussion of the issue, see the section on parallel runs in the BehaviorSpace Guide section of the User Manual.
Use repeat in your experiment's go commands, e.g.:
repeat 10 [ go ]
to measure the run after every 10 ticks. Essentially you are making one experiment step equal 10 ticks.
It's probably because your setup commands or setup procedure are using clear-all, causing the values set by BehaviorSpace to be cleared.
One possible workaround is to change your experiment's setup commands to preserve the value of the variable, e.g.:
let old-var1 var1 setup set var1 old-var1
This works because even clear-all doesn't clear the values of local variables made with let
Another possible workaround is to change your model's setup procedure to use more specific clearing commands to clear only what you want cleared.
In some versions of Excel, spreadsheets can't have more than 256 columns. (See a Microsoft support article on the subject.)
Possible workarounds include:
NetLogo supports fullscreen exclusive mode. If that is all your device needs then, possibly yes. However, it can be tricky to get it working. We don't have any such devices so it is difficult for us to make the process easier. If your device needs something else, for example, quadbuffers enabled, the answer is probably no.
You need to add NetLogo.jar to your classpath when compiling. NetLogo.jar is included with NetLogo.