Software overview

This document should give you an idea of the structure of the repo: What files are more important and what are boilerplate.

LibMark2

LibMark is the client side package used to talk to the WebMark server. LibMark will hopefully be included in Tequila at some point, so all users would have easy access to it. Currently the code is in the project folder's quantmark-subfolder.

The purpose of the software is to collect information on experiments run on different quantum computers. Both the results and setups are of interest, so both need to be collected. The data structures used by Tequila and SciPy, for example, are complex and probably depend on the version of the package. Therefore the information needs to be dissected at the client side where the libraries are available. This makes LibMark2 quite lengthy and complex looking.

There are three calls the client needs to make:

1. Create a new instance and initialize it with data known at this point
2. Add a new sets of data to the structure by calling add_run (maybe inside a loop)
3. Push the structure to the server by calling push

WebMark2

Most of the files were created by Django Rest Framework. Only the files containing significant changes are described here.

WebMark 2

settings.py

Django's core settings file. Plenty of interesting settings pertaining to deployment.

urls.py

The URL dispatcher. Very simple, but important file.

QLeader

initializers.py

Initialization functions for the data structures. They can't be class functions because they reference each other causing circular referrals.

context_processors.py

Context processors which supply the info on supported authentication methods and current path_prefix to all views. See Known Issues in CI & staging for info on path_prefix.

fci/ and hf/

Baseline information for comparisons. Only H₂ is supported at the moment. These should be moved into the database in the future.

models/

Contains the data structures stored in the database. A single experiment consists of one Result object, which has a one-to-many relationship to Runs. Runs is an abstract class, which is inherited to subclasses per VQE optimizer. The optimizers hold very different data.

Django requires that the models have to be imported to the init file.

tests/

Simple tests for regression testing. Testing Django routines would require mocking major parts of Django and/or the database.

views/

Standard Django view functions.

templates/

Django HTML templates. restframework/base.html is the common ancestor for all HTML views.