Self-Organized Criticality Simulation (SocSim)

https://www.fuw.edu.pl/tl_files/downloads/logo_18/FUW_znak-poziomy-EN.pngFaculty of Physics. University of Warsaw

https://readthedocs.org/projects/socsim/badge/?version=latestDocumentation Status https://travis-ci.com/SocSIM/SocSIM.svg?branch=masterBuild Status https://codecov.io/gh/SocSIM/SocSIM/branch/master/graph/badge.svgcodecov

Project is created as part of subject: Team student projects Faculty of Physics

Programs in Python that simulate dynamical systems that have a critical point as an attractor. So called self-organized criticality(SOC)

1. Theoretical problem description

Self-organized criticality wiki:

In physics, self-organized criticality (SOC) is a property of dynamical systems that have a critical point as an attractor. Their macroscopic behavior thus displays the spatial or temporal scale-invariance characteristic of the critical point of a phase transition, but without the need to tune control parameters to a precise value, because the system, effectively, tunes itself as it evolves towards criticality.
The concept was put forward by Per Bak, Chao Tang and Kurt Wiesenfeld (“BTW”) in a paper published in 1987 in Physical Review Letters, and is considered to be one of the mechanisms by which complexity arises in nature. Its concepts have been enthusiastically applied across fields as diverse as geophysics, physical cosmology, evolutionary biology and ecology, bio-inspired computing and optimization (mathematics), economics, quantum gravity, sociology, solar physics, plasma physics, neurobiology and others.
SOC is typically observed in slowly driven non-equilibrium systems with a large number of degrees of freedom and strongly nonlinear dynamics. Many individual examples have been identified since BTW’s original paper, but to date there is no known set of general characteristics that guarantee a system will display SOC.

2. Program structure, installation and use cases

2.1 Project folder structure

Project folder structure is inspired by these sources: sources1 source2 and Kwant project.

socsim:

  • docsrc - holds Sphinx scripts used for documentation generation.
  • docs - GitHub configuration folder, which holds web-page of project.
  • resource - Non executable files.
  • results - folder used for holding results of simulation, Jupiter notebooks and different use cases.
  • SOC - main project folder, which holds all source code.
    • models - contains different SOC models, like: Abelian sandpile model, forest-fire model, etc..
    • common - common code between all models
    • tests - unit tests of code

2.2 Installation and dependencies

Dependencies

Mostly numerical libraries, visualsation, web page generation etc. For whole list take a look at requirements.txt

2.3 Use cases

Running program

Program is designed in next way:

  • Framework part - placed under SOC folder.
  • Research part - consists of jupyter notebooks(which can be easily deployed to web-page) and is placed under research folder

Developing the program

use python setup.py develop to install a basic set of dependencies and link the package to be importable in your current Python environment.

Running test cases

To make folder SOC an import package, run only once:

python setup.py develop

After that, simply use pytest SOC to automatically find and execute all existing test cases.

Web-page generation

Web page is generated using Sphinx library.

Under terminal enter into docsrc folder and type:

make html

Web-page will be generated into ./docsrc/build/html folder. If you want to update web-page, copy generated web-page into /docs folder.

Results

Click the model’s name for more examples:

BTW

results/power_law_btw.pngpower-law

OFC

results/ofc_exmpl2.pngofcexample

Summary of intial goals:

  • Make wide coverage of all self-organized criticality models.
  • Figuring out the best algorithms.
    • Easy scaling on many processors machine(multithreading, GPGPU, CUDA, numba).
  • Using some best practice of programming:
    • Coding conventions
    • Unit Tests.
    • Creation of common modules.
    • Automatic documentation generation.
    • Readability of code and easy of use(between clarity and speed, we should choose clarity).

0.2 Commitments

Here are described code formatting style and other conventions, to make code more uniform. Also this section is for newcomers and contributors.

Unit Tests

SocSim uses the lovely PyTest for its unit testing needs. Tests are run automatically on every commit using TravisCI.

Documentation

Most popular documentation generator for Python - Sphinx. Good tutorial about using Sphinx here. Here is example of good Google style docstring standardized by PEP-484.

pip install -U sphinx
pip install sphinx_rtd_theme
pip install nbsphinx

pandoc

Dependencies of sphinx: recommonmark.

What’s next?

  • How we can apply Keras? Predictions, finding hidden parameters, etc.
  • More tests for the batch processes running (Dask)
  • Convenient selection of different boundary conditions of a system (lattice)
  • Parametrization of the earthquake model for the coverage of wider selection of submodels (by including eg.: drive with random loading, toppling to the neighbours in a specific state (crack model), delay of the fracture initiation, threshold for the fracture propagation) like in Lomnitz-Adler (1993)
  • Database of the simulations