Accelerator Installation

[Last updated 2021-10-12]

This HOWTO shows how to install and test the Accelerator.

TL;DR

# install
pip install accelerator
# setup new project
mkdir myproject
cd myproject
ax init
# check/modify the "accelerator.conf" file according to your needs
ax server &
ax run tests
# inspect the results in a browser:
ax board-server
# point browser to http://localhost:8520

Install Using pip

Using pip, the Accelerator is installed just like any other package. Installation can be global, local, or in a virtual environment. Here we show how to set up using a virtual environment.

We create a virtual environment using Python’s venv package

python3 -m venv accvenv

and activate it like this

source accvenv/bin/activate

Then we install the Accelerator

pip install accelerator

This command will download, compile, and install the Accelerator to the active virtual environment, accvenv.

Set up a Simple Project

Now that the Accelerator is installed, let’s create a simple project. Each project should have its own directory, so we use mkdir to create a new directory, and then we cd into it

mkdir myproject
cd myproject

and run the Accelerator’s init command

ax init

The init command will set up everything needed to work on the new project. At this point we are done, but please read on to learn more about the project setup, how to tweak the configuration file, and how to run the built-in tests.

What’s in the Project Directory

If we do a ls -F in the myproject directory, we’ll find the following files and directories that are of key importance

accelerator.conf         # The project's configuration file
dev/                     # The project's source code goes here
workdirs/                # All jobs and corresponding output is written here

and these that are optional

results/                 # Optional central place for computed results
urd.db/                  # Optional urd database directory

The file accelerator.conf contains the project’s configuration. Accelerator commands look for this file in the current directory or directories directly above the current work directory, so it is required to have the current working directory inside the project directory when running any command.

The Configuration File

The configuration file comes with pretty detailed inline documentation that we’ve chosen to not show here for brevity reasons. Instead, we’ll walk through the file and comment the things that are important at this stage.

slices

First, the file specifies the number of slices. This number stipulates how many processes the Accelerator will run in parallel. The variable is initiated to the number of available CPU cores (including threads):

slices: 8

workdirs

workdirs:
        dev ./workdirs/dev

A workdir is where jobs and their output is stored. Workdirs can be located anywhere in the file system, and they can be shared between users.

Any number of workdirs can be specified in the configuration file. In this case a singe workdir dev is defined. Note that it is possible to use shell environment variables, such as ${HOME}, in the definitions.

target workdir

target workdir: dev

The target workdir specifies in which workdir jobs are stored by default. It is not mandatory, but it is good practice to use it.

method packages

method packages:
        dev auto-discover
        accelerator.standard_methods
        accelerator.test_methods

This is a declaration of which packages that should be accessible in the project:

Three packages are defined here, first the dev package (which corresponds to our recently created myproject/dev directory), and then two packages from the Accelerator installation: standard_methods and test_methods.

result and input directories

result directory: ./results
input directory: # /some/path where you want import methods to look.

This specifies the results and source directories.

Starting the Server Process

When we are satisfied with the configuration file, it is time to start the Accelerator server process. The Accelerator is based on a “client-server” architecture, meaning that there is a server process that is constantly running, and we issue commands to it in order to execute programs.

Make sure the virtual environment is active, and do

ax server

to start the server. It is highly recommended to keep the server running in a separate terminal, so when issuing commands to it, we do that from a new terminal.

Running the Built-in Tests

If you have not done so already, please launch a new terminal (gnu screen or tmux is suggested), initiate the virtual environment and cd to the project’s directory:

source accvenv/bin/activate
cd myproject

and run the built-in tests like this

ax run tests

The built-in tests reside in the accelerator.test_methods package. The tests script will perform a large number of tests. Among them, a number of tests relate to character encodings, since the Accelerator is designed to handle in practice any character encoding scheme. The tests may print a warning message if there is insufficient support of locales installed on the system. If this is important for the application, please read the message for information on how to fix this and make sure all character encoding tests are run successfully.

Inspect Results in a Browser, the Accelerator Board

Start the board server

ax board-server

and point a browser to http://localhost:8520. The board server will visualise everything connected to the results linked in the result directory in the browser. All jobs, datasets, source code, parameters, and input data is visualised using the board server, making all processing completely transparent.

Running Arbitrary programs: The dev package

New project code is put in the dev/ directory. The init command has already put a minimal example there that can be examined and executed directly. Here is the contents of the dev/ directory as created by the init command

dev/
    __init__.py
    a_example.py
    build.py
    methods.conf

The dev/ directory is actually a Python package, that and thus it contains an __init__.py file.

The directory contains one example method a_example.py and one example build script build.py.

In order to run the example, type

ax run

Install from GitHub

It is also possible to install directly from the git repository.

Clone the repository

git clone https://github.com/exaxorg/accelerator

and install

cd accelerator
./setup.py build
./setup.py install

Additional Resources

The Accelerator’s Homepage (exax.org)
The Accelerator on Github/exaxorg
The Accelerator on PyPI
Reference Manual