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.
The proper citation is shown in the CREDITS AND REFERENCES section of each model's Info 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. So, 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 incorporates almost all of the extended functionality of our earlier StarLogoT, as well as a great many newer features.
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 ready.
No. The split is temporary. Eventually a single unified version of NetLogo 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 Preview 1 may require some small changes in order to run in the eventual unified version.
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 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 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.
Yes. NetLogo runs fine on a read-only file system.
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.lax file, found in the NetLogo directory (under Program Files on your hard drive, unless you installed NetLogo in a different location). Edit this line:
lax.nl.java.option.additional=-Djava.ext.dirs= -server -Dsun.java2d.noddraw=trueand add -Dsun.java2d.ddoffscreen=false at the end of the last line.
You can see the details of the Java bug and vote for Sun to fix it here.
A quick method is to use the three sets of black arrows in the upper left corner of the 2D view.
Another method is as follows. Select the 2D view 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 2D view to edit it, or select it then double-click.)
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 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
Note: this might not help on some Windows 98 or Windows ME systems.
<key>VMOptions</key> <string>-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 -server -Dsun.java2d.noddraw=true -Xms16M -Xmx512M -jar NetLogo.jar
Yes, a number of users have constructed models using raster GIS data. (We don't know of users who have used vector GIS data, other than by converting it to raster data first.)
One simple way is to use import-pcolors, but that only works for importing maps that are images, not maps in other formats.
We do not have built-in support for reading common GIS formats. However, a number of our users are working with GIS data successfully using NetLogo code that reads GIS data using our file I/O primitives such as file-open.
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 endIf you use this technique, you should turn off the "Force view update" checkbox, since the display command already forces a view update.
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. The easiest way is to set up your model run 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.
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 in the Finder, then open the copy. (The copy takes up only a very small amount of additional disk space.)
Not for a single model run, no. 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 computers.
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:
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.
Numerous users are already using NetLogo on clusters. You can seek them out on the NetLogo Users Group.
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.
Click the word "Pens" in the upper right corner of the plot. The legend will include any pens that have the "Show in Legend" option checked when editing the plot. Clicking "Pens" again will hide the legend.
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.
Use repeat in your experiment's go commands, e.g.:
repeat 100 [ go ]
to measure the run after every 100 model steps. Essentially you are making one experiment step equal 100 model steps.
It's probably because your setup commands or setup procedure are using ca or clear-all, causing the values set by BehaviorSpace to be cleared. Try using the more specific clearing commands to clear only what you want cleared.
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 seek help on the NetLogo Users Group. You may also ask us for help at feedback@ccl.northwestern.edu.
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.
Here are short discussions of the issues that are likeliest to arise, with links to further information:
If you are seeing pieces of turtle shapes wrapping around the view edges, it's because NetLogo 3.0 allowed you to turn off such wrapping in the view without affecting the behavior of the model. In NetLogo 3.1, if you don't want the view to wrap you must make it so the world doesn't wrap, using 3.1's new topology feature. Making this change may require other changes to your model, though. See the Topology section of the Programming Guide for a thorough discussion of how to convert your model to take advantage of this new feature.
If your model is behaving strangely or incorrectly, perhaps it's because in NetLogo 3.1, agentsets are now always in random order. In prior versions of NetLogo, agentsets were always in a fixed order. If your code depended on that fixed order, then it won't work anymore in 3.1. How to fix your model to work with randomized agentsets depends on the details of what your code is doing. In some situations, it is helpful to use the sort or sort-by primitives to convert an agentset (random order) into a list of agents (fixed order). See "Lists of agents" in the Lists section of the Programming Guide.
Many models made in NetLogo 3.0 or earlier use this code to scatter turtles randomly, using either random or random-float. It only works if world wrapping is on.
(Why? Because when wrapping is on, you can set coordinates of turtles to numbers beyond the edge of the world and NetLogo will wrap the turtle to the other side. But in worlds that don't wrap setting the x or y coordinates of a turtle to a point outside the bounds of the world causes a runtime error. The world wrap settings are new in NetLogo 3.1. See the Topology section of the Programming Guide for more information.)
To fix your model so that it works regardless of the wrapping settings, use one of these two commands instead:
setxy random-xcor random-ycor setxy random-pxcor random-pycor
The two commands are a bit different. The first command puts the turtle on a random point in the world. The second command puts the turtle on the center of a random patch.
The random-xcor, random-ycor, random-pxcor, and random-pycor primitives are new in NetLogo 3.1.
Any of these ways:
(- x) -1 * x 0 - x
With the first way, 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 might be near a corner. 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.
A turtle is on a patch center when its xcor and ycor are multiples of 1.0.
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, 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.
We don't have such a command. 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 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.
It really doesn't matter. Even if 1.0 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.0.
Nonetheless, if you feel it really must be possible to get 1.0, you can use precision to round your answer to a certain number of decimal places. For example:
print precision (random-float 1.0) 10 0.2745173723
(If you use this method, note that 0.0 and 1.0 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 places. Results between 0.0 and 0.5 get rounded to 0.0, but results between 0.5 and 1.5 get rounded to 1.0; the latter range is twice as large. So if you want 0.0, 0.1, 0.2, ..., 0.9, and 1.0 to all be equally likely, you must write random 11 / 10.)
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 [ ... ]
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, though less efficiently. 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.
For Moore or Von Neumann neighborhoods of a larger radius, see Moore & Von Neumann Example in the Code Examples section of the Models Library.
Yes. See the Links section of the Programming Guide.
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.
If you want the list in a random order, here's how:
values-from <agentset> [self]
Because all operations on agentsets are in random order, the resulting list is in random order.
And here's how to convert a list of agents to an agentset:
turtles/patches with [member? self <list>]
Note however that this method is not efficient and may slow down your model. We hope to address this issue in a future version of NetLogo.
If you ask turtles, or ask a whole breed, the turtles are scheduled for execution in random order, because all operations on agentsets happen in random order.
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 and begin your model run with the same random seed.
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.
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.)
The most straightforward way is:
n-of 0 turtlesor
n-of 0 patches
(Every agentset, even an empty one, is either a turtle set or a patch set.)