CulSim is an agent-based computer simulation software that allows for further exploration of influential and recent models of emergence of cultural groups based on Axelrod (1997) by including parameters grounded in sociological theories. CulSim provides a collection of tools to analyze resilience of cultural diversity when single drastic events …
Java Shell
Switch branches/tags
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.settings
executables
experiments
src/simulator
workspace/configurations
.classpath
.gitignore
.project
LICENSE.md
README.md
javadoc2.1.zip
simulation.parameters

README.md

cultural-simulations

  1. Summary
  2. How to use it?
  3. Installation
  4. About this implementation

Summary

This repository contains a set of java simulations for artificial societies. The simulations are related to the emergence of different cultures (groups of agents with the same features), and how to estabilize them in the presence of noise, and destruction.

The code implements several extensions to the seminal work of Axelrod 1997. It includes mutation, a source of perturbation to the cultural traits as proposed by Klemm et. al 2003, multilateral social influence, initial suggested by Parisi et. al 2003 and Centola et. al 2007, and finally adapted by Flache & Macy 2011 who also introduce another source of noise: selection error. Finally, it also includes institutions as we proposed in Ulloa et. al., including institutional process such as propaganda and democracy.

Apart from that, now it includes catastrophic (or no so catastrophic) events that affects the simulation in execution times. These events simulates catastrophic events such as wars, pests, invasions, attacks to institutions content and structure, and loss of faith in institutions (apostasy), but also not necessarily catastrophic events such as change of noise, democracy or institutional influence rates.

How to use it?

The wiki (user manual) is now available, and a GUI; the [Quick Start] (https://github.com/robertour/cultural-simulations/wiki/A.-Quick-Start) will introduce you very fast.

There is also a Batch Mode and a Command Line Interface to run experimental designs. Statistical analysis of the resutls is possible through the Output Files.

Installation

Install Java 1.7 or 1.8. It also need to be tested with IcedTea because it was not working a few months ago; if it doesnt, Oracle will have to be.

For windows users:
  • If you don't know how to use the terminal/command line, try:
  1. Download the culsim.jar file from here
  2. Right click in the culsim.jar file
  3. Open With...
  4. Select "Java runtime environment" (if the option doesn't appear, please install Java 7 first)
  5. After that double click should be enough.
  • Alternatively, you can double click the culsim.bat

  • If not the open the Windows CMD:

  1. Go to the directory that contains the culsim.jar
  2. Write java -jar culsim.jar
  3. Hit Enter
For Linux/Unix users:
  1. Press Ctrol+t
  2. Go to the directory that contains the culsim.jar and culsim.sh
  3. Write ./culsim.sh or java -jar culsim.jar
  4. Hit Enter
For Mac users:

It should be the same as for Linux/Unix users, but I have no relation with macs, so please let me know.

About this implementation

This code was created with the goal of running fast, most of them apply to the Batch Mode or Command Line Interfacce:

  1. All is kept in memory and I/O access is kept at the minimum.

  2. Each simulation is run in a different core. There will be as many threads as your computer have running at the same time. If you have 4 cores, you will have 4 threads (simulations) running simultaneously, and the rest waiting for them to finish.

  3. The use of objects in the simulation is avoided in the classes that correspond to the core implementation of the simulation. Instead, direct Java Matrices is used. You will see a lot of confusing indexes, fun times!! I did my best to keep decent names for them without being extremely verbose, and it is very well documented.

  4. Modularization in the simulation core method is avoided in order to reduce the number of method calls.

  5. As a consequence of the previous, the code is repetitive. Each class (that inherits from simulation) re-implement the wheel. You will find that most of the code in run_experiment is very repetitive, i.e. I didn't factorize intentionally.

  6. Buffered writers are used, so I/O is reduced and the output to files is not immediate.