Table Of Contents

Previous topic

Scripted SIJR model

Next topic

Simulation

This Page

API reference

The NepidemiX package provides a configurable Simulations class, and a hierarchy of Process classes. The most common way of using NepidemiX would be through scripts, however in some special cases, such as when the process configuration language is not powerful enough, python programming may be the best solution.

This reference documents the most common NepidemiX classes and utilities.

Simulations

This module contains the main Simulation class.

A simulation object is responsible for creating network and process and to execute the main loop, running the process on the network. It also handles I/O and logging. Saving data after each run.

Simulation() Captures the functionality of a simulation in a class.

Processes

A process operates on a network/graph and has the ability to change node and edge states as well as network topology.

All NepidemiX processes should be subclasses of the interface Process.

Methods need to be specified for updating the network and for loading settings.

Process([runNodeUpdate, runEdgeUpdate, ...]) Base class/interface for a NepidemiX process.
AttributeStateProcess(nodeAttributeDict, ...) This class is a specialization of Process where node and edge states are
ExplicitStateProcess(nodeStates, edgeStates) This class is a specialization of Process that assumes that all
ScriptedProcess(**kwargs) A scripted process reads its node and edge rules, as well as states from a file.

Utilities: nepidemix.utilities

Aside from the main classes, nepidemix has a many support functions and classes. The ones directly related to the configuring and running simulations are outlined below.

NepidemiX configuration parser

Python configuration parser compatible with some additional functionality such as guaranteed ordering of items and type casting.

NepidemiXConfigParser() NepidemiX ini-file reader.

Network creation wrapper classes

As the parameter values read from configuration file (currently) is type independent we need a way to map to types accepted by the graph generation functions. The current best solution is to create wrappers that maps to the right type.

An alternative approach would be to require explicit type casting in the configuration file.

A wrapper is simply an instance of the NetworkGenerator class providing a function for creating the network and a dictionary of (name, type) pairs.

This module could be made obsolete if using a configuration system with explicit types.

Examples

Creating a wrapper object is done by creating a specific instance of the NetworkGenerator class and providing a reference to its create method. So, for instance to create a wrapper for the networkx function barabasi_albert_graph, that accepts the two parameters n and m, both of type int one would do:

BA_networkx = NetworkGenerator(networkx.barabasi_albert_graph, {"n":int, "m":int}).create

The name BA_networkx could then be used in configuration.

NetworkGenerator(creationFunction, typeMap) Network generation wrapper object.

NetworkX utilities

A small set of utilities extending and operating on NetworkX graphs.

neighbors_data_iter(graph, n) As networkX does not provide any good support o
attributeCount(iterator, attr) Count frequencies of a given set of possible values for some node or edge attribute.
attributeValueDeal(iterator, ...[, dealExact]) Deal values to a specific attribute of all nodes or edges in a graph.
loadNetwork(file) Utility function: Go through a number of file load methods and try to read

NetworkX graph generators

albert_barabasi_physrevlett_quick(N, m[, ...]) Implementation of the Albert and Barabasi preferential attachment
albert_barabasi_physrevlett_rigid(N, m[, ...]) Implementation of the Albert and Barabasi preferential attachment
powerlaw_degree_sequence(n, a) Create a graph without self-loops or parallel edges; having power law degree distribution with an exponent ‘around’ a.