QAnsel

A quantum computer simulator which supports hardware acceleration (GPUs) as well as hardware random number generators.

Compilation

Please click the tree link at the top and navigate to the bin folder and download the following file to get the source code for the simulator.

    qansel-source-base.zip

To compile it, navigate to the folder it installed within and run the following commands within that folder.

    mkdir qansel
    mv *qansel-source-base.zip qansel
    cd qansel
    unzip *qansel-source-base.zip
    make

If you are compiling for a device which cannot support hardware acceleration, then you can use make simple which will build the program with those features stripped out.

Examples

Many example programs that can be executed inside of QAnsel can be found by clicking the tree link at the top fo the page and then navigating to the examples folder. Simply click on one of the examples in order to see the source code.

Usage

The QAnsel simulator expects programs to be written in a language similar to OpenQASM 2.0. These programs must be piped into QAnsel as standard input and the simulation results will be displayed as standard output. Below is an example using a here document.

    $ ./QAnsel << EOF
    > qreg q[2];
    > creg c[2];
    > h q[0];
    > cx q[0], q[1];
    > measure q[0] -> c[0];
    > measure q[1] -> c[1];
    > sample c;
    > EOF
    00: 50.7%
    01: 0.0%
    10: 0.0%
    11: 49.3%

Please use the -? flag to see a help document.

Special Hardware

To enable a hardware random number generator, the -r flag must be used. This flag will select the hardware random number generator based on an order of precedence. The order is as follows.

1. Quantis-PCIe-40M
2. TrueRNG V3
3. Secure Key Technology

To enable GPU acceleration, the -oX flag has to be set replacing X with an optimization level equal to 4 or greater.

It is recommended that you run a simple program with the -v flag which will produce output stating which hardware devices were actually found and enabled.

QAnsel can handle up to 16 qubits, however, qubit counts greater than 14 will not fit into most consumer-end GPUs. The amount of qubits that can fit is limited by the amount of VRAM. The GPU must have at least 8 GB for 14 qubits, 16 GB for 15 qubits, and 48 GB for 16 qubits.

API and Web Interface

There is a drag-and-drop interface that runs in the browser that can be found by clicking the tree button and navigating to the bin folder and downloading the following file.

    qansel-source-web.zip

This web front end expects to connect to an API. The API service is handled through FoleoAPI. Please see the FoleoAPI project in order to set up this service.

Once FoleoAPI is running, a ServiceInfo record will need to be added to the APIService schema. Below is an example of how this entry may look.

    MariaDB [APIService]> select * from ServiceInfo;
    +----+---------+---------------------------------+-------------+
    | id | service | path                            | parameters  |
    +----+---------+---------------------------------+-------------+
    |  1 | qansel  | /fakepath/QAnsel                | -q14 -o5 -r |
    +----+---------+---------------------------------+-------------+

The -qX parameter is useful here as it allows one to cap the maximum qubit count allowed for the process in case the hardware running the simulator is not sufficient to handle large qubit counts. In this case, it is capped at 14 to make sure that programs that exceed the limitations of the GPU are rejected.

The web interface expects an API key. The API key is formed in three parts A:B:C where A is the APIService.AuthInfo.username, B is the APIService.AuthInfo.authkey, and C is the URL which it needs to ping. It is important that the address does not contain http:// or https://. For example, if the address is http://example.com/api, then C should simply be written as example.com/api.

Once A:B:C is filled out, the entire thing needs to be converted to a base64 string. This can be done in JavaScript in the developer console in the web browser using the btoa() function. This final encoded string functions as the API key for the web interface. Any equal signs at the end of the API key should be removed.

The web interface allows for appending the URL with ?apikey= followed by an API key to auto fill the API key. This can be useful if the service is linked from another source (such as another website or an email) and will prevent the user from having to input the APIkey themselves.

Android

The Android app version of this project merely is enclose a web view containing the web interface. This means it requires pinging a server running the API for it to work. It must be compiled using Android Studio.