Pamela Toman

How do you let the user specify the location of files in Repast?

To expose any variables to the user in Repast, the variables need to be specified as model parameters (not as, say, command line arguments).  When the model is set up that way, after the Repast modeling environment is launched but before the model itself begins to run, the user can change the paths to the data files for that particular run within the Parameters tab.

In practice, this means you first define a new set of attributes in the model.score file (one for each file).  Set SType as STRING.  Set the default path.  Then, to retrieve the user-provided values during a model run, you use the parameter access syntax (as used without previous explanation in the Repast Predator-Prey tutorial code):

This approach to letting the user select data input files is not nearly as robust as it should/could be.  It would be nice to launch a file chooser, for instance.  Additionally, although Repast lists “File” on the drop-down for SType, I haven’t been able to run anything with that type selected.  The internet has been massively unhelpful in explaining what Repast expects when you set SType to File, and now that the basic functionality needed is in the model and the to-do list has continued to grow, I just don’t feel up to reading the source code or bothering the Repast listserv on this particular issue…. But I am curious about the purpose of File as an SType.

Notes on Standalone Repast Runtime Models

This topic comes up because I recently built a runtime version of the Repast model I’m working on, according to the Build Installer instructions. As I quickly found out, the directory structure gets shuffled around during the build. As a result, as soon as the model is run from that new standalone installation, any hard-coded paths to files generate a NullPointerException. (And if those paths are fixed to work in the runtime environment, then the new paths will not continue to work in the development environment.) The easiest development-period fix was to allow the user to specify the location of all files — including GIS files so fundamental to the way the model operates that I hadn’t previously thought about exposing them.

Two more notes related to running the model as a standalone runtime version:

• In the parameter setting screen, the current directory . is INSTALLNAME/yourModelName.  If you intend to keep the input data files there, congratulations!  If not, you’ll need to update the path accordingly.
• Data files in the project’s root directory were ignored during Build Installer for me.  When I moved the data files to a /data folder parallel to /src, they were included as part of the installer.  The data files originally stored in /data installed into the INSTALLNAME/yourModelName/bin/data directory.

My current client is extremely interested in how “us vs. them” dynamics manifest in language. Most manifestations are subtle, but I’ve spent so much time in that headspace that I’m now getting insight flashes from Critical Discourse Analysis everywhere I look. I gotta say, actually seeing these power dynamics is like having my eyes opened to something I expect I’d have been happier not seeing. (It all reminds me of the Matrix. Or maybe Amazing Grace would be a better analogy. Something between the two, anyway.)

Here’s an example that I can’t stop thinking about. I visited the “Written in Bone” exhibit at the Smithsonian Museum of Natural History. One of the exhibits was a set of 3 skulls – a Native American skull (left), a European skull (center), and an African skull (right). I think the message they were aiming for was “everyone’s background is written in their skull” – a fitting message for an exhibit about skeletal analysis, forensics, and what bones can teach us about history.

The display text is:

• Left: Individuals with Native American ancestry have proportionately wider faces and shorter, broader cranial vaults.
• Center: Individuals with European ancestry tend to have straight facial profiles and narrower faces with projecting, sharply angled nasal bones.
• Right: Individuals with sub-Saharan African ancestry generally show greater facial projection in the area of the mouth, wider distance between the eyes, and a wider nasal cavity.

Interesting facts! But the language choices stopped me cold. The text gives the Native Americans and sub-Saharan Africans a series of comparative “-er” adjectives. Every time a “distinctive feature” is mentioned, it is as a comparative (to something else that goes unnamed). But the European language is different. Three of the four adjectives are pure, non-comparative words. To boot, the visual design also echoes “European-as-normative” in its use of the (literally whiter!) European skull as the centerpiece.

Likely the visual design was deliberate – museum designers certainly are well-versed in visual metaphors – but I would be surprised if the author really intended to say, “I am white, and I am designing this exhibit for white people”. It might be true, but that message is so blatantly racial that it’s hard to believe anyone intends to give it in 2010.

It’s hard to unsee the constant unintended us-vs.-them signalling baked into human communication once you start seeing it.

IARPA, the whackier younger sibling of the government’s wild idea incubator DARPA, wanted to understand the hidden intentions of decision makers. To that end, we delivered a computational model of decision making in Java. By building a model, we enabled users to: (1) perturb the system to estimate the robustness of an outcome, (2) experiment with levers of influence. The model integrated with a complex set of other related systems built by other contractors.

I learned a lot of decision theory as part of implementing this model. My main takeaways are:

• Individuals’ decisions can be represented as “decision matrices” (interests by available choices, with weights in each cell). We often want the interests to be ranked. Weighting choices ordinally with ties allowed within each interest is often easiest.
• You can influence an outcome by influencing the decision-making environment. For instance, adding more interests can change outcomes. Changing who is consulted can also change the outcome.
• Decision matrices can be turned into decisions through multiple techniques, including: (1) maximizing expected utility, (2) eliminating the worst options on the most important dimension (“elimination by aspects”), (3) choosing the best option on the most important dimension (“lexicographic decision heuristic”), (4) and maximin (maximizing the worst-case payoff).
• The maximin heuristic is very risk averse. People tend to use it when the decision is especially difficult.
• Social influence and power relationships can weaken/strengthen/change people’s interests and decision matrix weights.
• The group’s style of decision making (a la the Vroom-Yetton model) informs how individual choices are aggregated.

Using Java professionally (and for the strange bedfellow of modeling) meant a lot of learning for me too. (Once burned by a boxed variable, never again.)

My boss Elisa Bienenstock and I wrote a white paper on how Social Network Analysis can help forecast and detect rare events. It appears in Anticipating Rare Events: Can Acts of Terror, Use of Weapons of Mass Destruction or Other High Profile Acts Be Anticipated? A Scientific Perspective on Problems, Pitfalls and Prospective Solutions (N. Chesser, Ed.), which is an interdisciplinary review for operators in terrorism prevention within DoD/DHS/USG agencies.

In our paper, we focus on two insights from the field of social network analysis (SNA). First, innovation tends to happen at the periphery of social networks, rather than in a network’s core. New behaviors, insights, and events are more likely to occur when people with different backgrounds mix. Second, when a novel event involving new participants is being planned, we can observe signs of that activity in the network. New regions of the network will become active and new substructures will emerge. We conclude that an SNA-based approach for anticipating terrorism and other rare events would watch for two changes in structure: (1) new ties at the edges of networks, and (2) the new involvement of individuals with particular talents and resources with each other.