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, including network phenomena. It also refers to HubNet, the multiuser participatory simulation environment included in NetLogo.
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 every model's Information 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, and 4.1 in 2009.
NetLogo is written mostly in Java.
Some parts, such as BehaviorSpace and the compiler, are written in Scala. Scala code compiles to Java byte code and is fully interoperable with Java and other JVM languages.
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 single threaded 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 incorporates almost all of the extended functionality of our earlier StarLogoT, as well as many newer features.
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).
At present, the source code for most of NetLogo is not publicly available. We are working on eventually releasing the source under an open source license.
BehaviorSpace, however, is free and open source software under the GNU LGPL license. Also, all of the extensions currently bundled with NetLogo are free and open source. You will find the source code for BehaviorSpace and the bundled extensions included in the NetLogo distribution.
NetLogo is not a closed platform. We provide APIs for controlling NetLogo from external code and extending the language with new commands and reporters. (See "Controlling" and "Extensions" in the User Manual.) We encourage users to write NetLogo extensions and share them with the NetLogo user community.
We offer workshops from time to time. If a workshop has been scheduled, we will announce it on the netlogo-users group.
See the Textbooks section of our Resources page.
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 anyone 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.
The user manual has been translated into Chinese and Czech. The translated versions are available from the NetLogo web site.
Short answer: partially compiled; we are working towards a full compiler.
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 are interpreted. We are working on expanding the compiler to support the entire language. 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, 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 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:
Although NetLogo 3D is now included in the NetLogo download, it is still a separate application.
However, the split is temporary. Eventually a single unified application will support both 2D and 3D modeling. We will be sure to design the 3D world support in such a way that it doesn't get in the way when you are building 2D models.
Models built in NetLogo 3D may require changes in order to run in the eventual unified application.
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.
Windows:
Run the installer from the command line using the -q option:
NetLogo4.1.3Installer.exe -q
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.
Current versions of NetLogo require that your web browser support Java 5 or later. For more details about Java requirements see the Applet guide.
Some NetLogo applets may require more memory than the browser normally makes available. See the memory section of the Applet guide for details on how to change the memory allocation.
The Java Plug-In is not allocating sufficient space to run the model. Details on how big a model can be in NetLogo can be found here. You will need to increase the amount of memory available to the Java Plug-In. See the instructions here.
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 the source code and a link where the user can download the model file. If you want, you can remove the source code and the link. Removing the link 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. Unsigned Java applets cannot read files on the user's computer, only the web server.
If your web server returns custom error messages in response to requests for non-existent pages it must also return a status code of 404 Not Found, otherwise, NetLogo thinks the following data is what it requested and tries to read it as such. This happens even if all the files required to run the applet are present.
If you don't have control over the error messages on your web server you can use the following as a workaround:
org.apache.commons.logging.impl.LogFactoryImpl
Note that all the directory and file names are case sensitive.
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 Sun, by editing the NetLogo 4.1.3.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:
-Dsun.java2d.ddoffscreen=false
You can see the details of the Java bug and vote for Sun to fix it here.
We recommend Sun's Java runtime when using NetLogo on Linux.
In theory, any Java 5 or later runtime will run NetLogo. In practice, some Java implementations aren't high enough quality. OpenJDK doesn't work, nor does GNU libgcj.
Ubuntu users should consult http://help.ubuntu.com/community/Java.
A nearly certain fix is to use a text editor to edit the NetLogo 4.1.3.vmoptions file (found in the NetLogo directory, by default in C:\Program Files):
-Xmx1024M
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 very large numbers of 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 section of the User Manual for details.
Another option is to use our Controlling API. Some light Java programming is required. See the "Controlling" section of the User Manual 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. The NetLogo engine is single threaded and we expect it to remain that way. We don't have any plans 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, such as a plot.)
To get a feel for what's going on, it may help to gradually move the slider to the right, rather than moving it all the way to the right all at once. 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 512K 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:
-Xmx1024M
<key>VMOptions</key> <string>-XX:MaxPermSize=128m -Xmx1024M</string>Ordinarily, you can go as high as two gigabytes (2048M) by this method. But if your Mac has a 64-bit Intel processor and you are running Mac OS X 10.6, you may be able to go even higher. Select the NetLogo application in the Finder, choose Get Info on the File menu, and then uncheck the "Open in 32-bit mode" checkbox, to enable 64-bit operation, which should allow higher -Xmx numbers. (We have not heavily tested 64-bit mode, but it seems to work.)
-Xmx number to the desired value.
Yes, using the GIS extension. See the GIS section of the User Manual.
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.
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. (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 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.)
At present, no. In a future version of NetLogo, we plan to support this.
Yes, this is available on an experimental basis using the __includes keyword.
We don't have a document that specifically summarizes the differences between these programs. If you have built models in StarLogo or 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. The NetLogo Users Group is a useful resource.
This is answered in detail at the end of the Programming Guide in the User Manual.
See the Transition Guide section of the User Manual for help.
NetLogo only works in "en" locales. A locale is a setting which tells NetLogo which language you are using, as well as how to display dates and numbers. You may need to switch to to an English locale before launching NetLogo. This is usually done in the "Regional Settings" or "Internationalization" panel of the operating system.
In a future version of NetLogo we plan to support different languages and locales.
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 in the User Manual 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 [ ... ]
In the current version of NetLogo, lists are immutable singly linked lists, rather than having an array-based underlying implementation as in earlier NetLogo versions.
True arrays are available by using 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.)
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:
You need to add NetLogo.jar to your classpath when compiling. NetLogo.jar is included with NetLogo.