dqcsim 0.0.13

Python bindings for DQCsim

# DQCsim

[](https://crates.io/crates/dqcsim/) [](https://pypi.org/project/dqcsim/)

[](https://github.com/mbrobbel/dqcsim/actions?query=workflow%3ARust) [](https://github.com/mbrobbel/dqcsim/actions?query=workflow%3APython) [](https://github.com/mbrobbel/dqcsim/actions?query=workflow%3AC++) [](https://github.com/mbrobbel/dqcsim/actions?query=workflow%3ADocumentation) [](https://github.com/mbrobbel/dqcsim/actions?query=workflow%3ACoverage) [](https://codecov.io/gh/mbrobbel/dqcsim)

DQCsim, short for Delft Quantum & Classical simulator, is a framework that can be used to tie components of quantum computer simulators together in a standardized yet flexible, developer-friendly, and reproducible way. Click [here](https://mbrobbel.github.io/dqcsim/) for more information!

## Installation

If you’re a user or a plugin developer (Python, C, or C++), the recommended way to install DQCsim is through Python’s package manager:

sudo pip3 install dqcsim

This will install just the DQCsim core files and so-called “null” plugins for testing. So you’ll also want to install plugins in addition. This is currently TODO, because there are no supported plugins yet. However, the current idea is that these will also be distributed through pip, with a dependency on dqcsim. For instance, you should be able to install dqcsim-qx through pip to get the QX simulator with appropriate DQCsim bindings.

You can find more information [here](https://mbrobbel.github.io/dqcsim/install/).

## Getting started

Read the [documentation](https://mbrobbel.github.io/dqcsim/)!

## Reporting bugs

We use github’s issue tracker. Click [here](https://github.com/mbrobbel/dqcsim/issues/new) to open a new issue.

## Contributing to DQCsim

TODO: until we (jvanstraten and mbrobbel) get a first release going, contributing is probably more trouble than it’s worth.

### What to contribute?

Check github’s [issue tracker](https://github.com/mbrobbel/dqcsim/issues) to see what we’re working on and what needs to be done.

### Code style

For Rust code this is simple: always apply cargo format and cargo clippy -Dwarnings before committing. The CI will fail if your code does not comply. For C, C++, and Python, there isn’t really a specific code style defined right now; please just try to mimic the existing code.

Any tab character that isn’t required by the language (looking at you, Make) will be shot on sight. Trailing whitespace is also frowned upon.

### Building

Within the root directory of the repository resides a Cargo workspace, a Python setup.py (using setuptools), and a CMake buildsystem. Since we’re using pip for distribution, setup.py is the master: running python3 setup.py build will chain to Cargo to build the Rust modules before building the Python-specific things. The C/C++ API is currently header-only, so it doesn’t need to do anything with CMake. Note that the headers are generated by Rust’s build.rs script, though. Running python3 setup.py bdist_wheel after the build will produce a wheel file in target/python/dist, which you can then install into a Python venv using pip; just replace dqcsim in the install notes above with the wheel file.

The documentation is built seperately using the doc folder. It relies on mdbook for the main tutorial-style documentation, cargo for the Rust reference, doxygen for the C++ reference, and pdoc3 for the Python reference. If you have all those, you can just run make in the doc folder, and the documentation will appear in target/book. You can also run make open, which will try to open the index in a browser when the build completes.

If you’re stuck on something build-related, it might be useful to check out how the CI pipelines handle the build. You can find this in the .github folder, as we currently use Github actions. The yaml files should be pretty self-explanatory when it comes to the build command lines.

### Testing

Testing is done by the buildsystem associated with the language.

#### Rust

To run the core test suite for DQCsim and its command-line interface:

cargo test

#### Python

To run the Python API test suite:

python3 setup.py test

This will automatically chain to Cargo if needed.

#### C/C++

To run the C/C++ API test suite:

mkdir -p build cd build cmake .. -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=debug make -j CTEST_OUTPUT_ON_FAILURE=1 make test

This will automatically chain to Cargo if needed.

### Cleaning

The Rust, Python, and documentation build systems are configured to output all build artifacts in the target directory. The C/C++ tests output to wherever you ran CMake from. Thus, if you need to clean everything due to a broken buildsystem state (this can happen for instance when you switch branches) all you should have to do is delete those directories.