Implementing and Testing an Agent-Based Model

• Read Chapters 5 & 6 from Railsback & Grimm before Monday

• Be able to translate a model from its written description in ODD format into NetLogo code.
• Be able to define global, turtle, and patch variables.
• Become familiar with NetLogo's most important primitives, such as ask, set, let, create-turtles, ifelse, and one-of.
• Start learning good programming practices, such as making very small changes and constantly checking them, and writing comments in your code.
• Produce your own software for the Butterfly model described in chapter 3.

• Program the overall structure of a model first, before starting any of the details.
• Before adding each new element, conduct some basic tests of the existing code and save the file.
• For the love of all things made of chocolate, indentation and organization is your friend!

Discuss: When you click the new setup button, why does NetLogo seem to color the patches in spots all over the View, instead of simply starting at the top and working down?

Answer: NetLogo always, by default, goes through turtles and patches in random order. This is an attempt to remove a possible confounding process - agent ordering. This is an example of asynchronous updating.

This is the programmers “Do as I say and not as I do!” Think of commenting as taking notes in your learning.

“Comments are needed to make code easier for others to understand, but they are also very useful to ourselves: after a few days or weeks go by, you might not remember why you wrote some part of your program as you did instead of in some other way.”

• Briefly describe each procedure (section) or nontrivial piece of code (paragraphs).
• Explain meaning of variables (Pull from ODD if possible)
• Document context of each procedure (specific to ABMs - turtle, patch?)
• Label ending of procedures and sometimes if or ifelse statements (i.e. after closing using ] character)
• Use ;----------- to separate procedures in long programs.
• Comment pieces of code that are used for unit testing or temporary output.
  show (word elev1 " " elev2 " " elevation)

The point is to make your code readable and understandable, so some caveats:

• There is such a thing as too much commenting - try and make your code unobfuscated (e.g. if there are multiple ways to accomplish something, choose the readable over the elegant and short)
• Use tabs and blank lines to show code organization.