Convert each function in qBraid/tests/transpiler/test_transpiler.py into a unit-test using pytest. Break down existing test functions according to a testing scheme that isolates and tests each component of the transpiler separately, and in its own file. The number of total tests and breadth of individual tests should be optimized towards maximal coverage with minimal redundancy.

Change readthedocs page to match the qBraid theme colors and fonts

Change dependabot interval from 'daily' -> 'weekly' in dependabot.yml to de-clutter PRs

We want to add a Code Snippets section to the Lab User Guide portion of our docs page. On this page, we want to give an overview of how to use the code snippets extension and show off all of its cool features. Relevant topics include:

• What are code snippets / what are they for
• How to copy and use code snippets in my notebooks
• How to create and edit code snippets
• How to browse code snippets and search for specific ones
• Previewing / favoriting / tagging code snippets etc.

See the README for how to develop / build the docs.

The code-snippets-docs branch already includes a file docs/lab/codesnippets.rst that you can work from. So after cloning the repo, run

git switch code-snippets-docs

to make sure you are developing on the correct branch.

If you're unfamiliar with writing using sphinx / RST, there are lots of good resources online including reStructuredText Primer. You can also just copy and modify code from other files in the repo to add links, pictures, style, etc.

If i incorrectly enter my IBM credentials. i do not see an option to reset it.

qBraid/qbraid/transpiler/clbit.py line 22 uses property index of qiskit.circuit.classicalregister.Clbit. However, back-references to/from Bit instances to their containing registers have since been deprecated. Instead, one must inspect Registers to find their contained bits. Therefore, we must either add a qiskit Register argument to our Clbit class, or store the index of a qiskit Clbit as an integer, as we do for cirq and braket. Either way, any and all Clbit objects created throughout the transpiler must reflect this change.

Go through the qbraid/_archive directory. Any files we no longer intend to use can be deleted. Revisit any code we do intend to use, test it out, and update it as needed. Once this is finished, we will integrate it back into the SDK.

Determine the smallest subset of qiskit's opflow class needed to run the VQE. Add to qbraid/operators/ folder but maintaining same file structure as opflow. Replace VQE code to reference these files

Get / update jobs from MongoDB similar to get_devices function. Return in HTML table.

1. Run each of the unittest files contained in qbraid/operators/tests and make sure they still work. If not, go into qbraid/operators/conversions and fix any issues.
2. Move all of the working tests out of qbraid/operators and into tests/operators . Delete the empty test_operator.py placeholder file. Modify the imports as needed so the tests still work in this new location.
3. Inside of qbraid/operators/conversions are two jupyter notebook files that appear to be Fermionic operator-related tutorials/walkthroughs. If they’re still useful, we’ll need to test to see if they run, fix any errors, clean them up, add comments, and move them to the tutorials folder.
4. Same thing for qbraid/operators/demo_funcs.py. Make sure it works, clean it up, comment it, move it to tutorials.
5. Update/write docstrings for each of the documentation-worthy functions (your judgement) in each .py file of qbraid/operators/conversions
6. (Bonus) convert each of the tests/operators files from using unittest to pytest to match the other files that will be in the tests folder.

What if an instruction, gate, moment in one package must be separated into several instructions, gates, moments in another package? We will probably need to handle (at each stage) adding a list of instructions to a circuit, for instance.

(Created in response to #9).

• pytket shared_15 to cirq not working, make revisions to fix.
• Add other tests (as commented) iswap gate, roundtrip, and circuits with non-contiguous qubit indexing
• Make sure passing pytket circuit through as argument to device_wrapper.run successfully executes circuit for ibm and amazon braket devices.

Instead of the qbraid.interface.draw it might be more elegant to add an abstract draw method to the QuantumProgramWrapper class. This way, all circuits/programs passed to the circuit_wrapper can be drawn in a unified format, including OpenQASM strings (#77). Can take advantage of buit-in functions/methods for each program type and/or add additional integrations with latex or other 3rd party quantum circuit drawers where it is convenient

For transpiler unit-testing (#14) , we need to able to get the matrix representation of circuits across each of our supported packages to verify the equivalence of circuits before and after using the transpiler. For cirq we use this straight-forward unitary protocol. For qiskit we convert a circuit to an operator and retrieve its data attribute. For braket, we initially thought we could use the to_matrix method of this quantum operator class, but looking at the source code, this class is not yet implemented. So, we need to find another way to retrieve the matrix representation of braket circuits. Look through the amazon-braket open-source for another instance of a built-in function that calculates the unitary of a circuit, and demonstrate its functionality using the braket circuit defined at the bottom of test_circuits.ipynb. Using np.allclose, compare this matrix representation to that of cirq and qiskit for equivalent circuits. If the representations are not equivalent, experiment with qubit indexing, order of operations, and matrix transpositions/inversions as necessary so that the representations are aligned, and document in the notebook which circuit modifications were needed to find consistency transpiling across each package. If no built-in function exists, we may need to make our own version of a braket matrix representation function.

The SDK has a number of dependencies, each of which are very heavy imports. As a result, it often takes over a minute to run the command import qbraid. We'll want to think of a way to lazy load imports, or strip to core dependencies with the additional package add-ons.

We need to update the Lab User Guide to reflect the latest changes/updates to lab. In addition to #123 #124 a tentative list of items includes:

1. Environments:
   • All lab screen-shots are out-of-date
2. Install environment:
   • Mention the install status bar and include a picture of it in step 3.
3. Create environment:
   • This feature is no longer a pop-out and is now integrated into the sidebar.
   • For steps 2 & 3, it does not take a filepath to a requirements.txt anymore. Instead, the user types in the packages as code to a code cell in requirements.txt type format. So we will want to describe that and update the picture.
   • Add everything after the first image in step 3 to a new section called Manage environment.
4. Manage environment: add new section (from last bullet above), which shows the More pop-out, explains how to search through the package list, and shows how to add / install a new package in the environment (this is a new feature). Here we can also mention the button to uninstall an environment, and how you can edit the environment description of your own custom environments .
5. When the CLI is updated with new quantum jobs commands (probably after adding IBM jobs), we will also want to update the corresponding CLI Reference.

API tests are failing for github actions because tokens aren't properly being stored / loaded in test-top-level.py module

List includes but not limited to:

• General getting started
• Code snippets
• Git sidebar extension
• Filesystem
• Omnisearch

Just thought it would be nice... azure has one.

Eventually, all classes and functions that qbraid-SDK users are able to interact with will need to be fully documented. For now, we can start with just the classes declared inside of the qbraid/circuits folder (and sub-folders). We will use Google Style Docstrings inside of the code and ultimately generate our doc files using Sphinx. This exercise will hopefully help familiarize you with the codebase and the class hierarchy that makes it up and will come in very useful during the testing phase (coming up next) and for whenever we add new functionality. Following the "road (code) map" of how the transpiler executes through each call will help you fill in the summary of each class's functionality and description of its attributes. In many cases, a sentence or two may already be written, which may be sufficient. If not, do your best to describe what you think the class does, or ask me or Erik. The Cirq repo is a great example of how to use the Google docstrings format. If you finish before I've assigned another task, you can start creating docstrings for functions visible to users in qbraid/circuits, and/or you can follow the Sphinx tutorial linked above to build and populate the actual documentation page from the docstrings you already made. Remember to create a new feature branch and push your changes there instead of to master. Then after you're done, we can merge more easily.

Add ability to pass OpenQASM string to circuit_wrapper method.

This will involve making an qbraid/transpiler/wrappers/qasm_circuit.py module that holds a QasmProgramWrapper that takes str as an accepted input Program type. Can likely integrate with cirq to_qasm to implement attributes self._num_qubits and self._depth etc.

Currently, transpiling a qiskit RXX, RYY, or RZZ gate to cirq or braket defaults to the corresponding unitary because cirq and braket don't have explicit support for these gates. However, cirq and braket each have some flavor of XX, YY, ZZ gates, which can be used to construct equivalent rotations. Carefully paying attention to the matrix representations across gates in each package, find decompositions of the above qiskit gates using built-in gates from cirq and braket, and add RXX/RYY/RZZ support to cirq/utils.py and braket/utils.py. Once complete, update the transpiler documentation with your solution.

Bonus: Build support going the other direction as well. In other words, when transpiling a cirq or braket XX/YY/ZZ gate, how can built-in qiskit rotation gates be used to create an equivalent representation?

In your notebook compare_gate(braket).ipynb you noted 22 Braket gates that raise an exception when passed through the transpiler.

Right now, we aren't as concerned about the Pulse gates or noisey gates. So for braket.circuits.gates.PulseGate, we want to output a custom error message when the CircuitConversionError exception is raised that says that we don't support pulse gates yet. For any of the gates in the braket.circuits.noises module, we want give a similar error message that says we don't support noisey gates yet. Each of these should have an associated test case in test_from_braket.py that makes sure the correct error message is given when one of these gates is passed.

Finally we want to add support for the remaining two gates, braket.circuits.angled_gate.AngledGate and braket.circuits.angled_gate.DoubleAngledGate in convert_from_braket.py and add test cases for each in test_from_braket.py.

Background

This isn't related to the transpiler, but will greatly help us with the quantum devices extension that we are building for qBraid Lab, see image below. The idea of the extension (which will be available in the right sidebar of Lab) is to give users an idea of what quantum devices are online and available at any given time, along with relevant information about the device (e.g. numQubits, topology, id / arn, etc.) We are basically recreating the IBMQ and AWS devices pages, but combining them as one single Lab extension.

Looking at the left side of the lab extension screenshot, we can tell that 5 of the AWS devices are not online. However, we currently don't provide the user any information beyond this. In the actual Amazon Braket console, they provide a live "count-down" to when each of these offline devices will next be online based on their availability zones.

TODO

In this issue, we want to implement a function that returns the hours, minutes, seconds until a given AwsDevice will next be available. This can be implemented in a stand-alone file in the qbraid/devices/aws module. It should take in an AWS Device ARN (string) as argument (e.g. arn:aws:braket:eu-west-2::device/qpu/oqc/Lucy), and return a tuple containing the (hours, minutes, seconds) until that device is next available. If the device is currently available, it should return a similar tuple, but instead give the (hours, minutes, seconds) until the device will no longer be available.

Most of the relevant code needed to implement the function can be taken directly from the braket.aws.AwsDevice.is_available method. You will just have to tweak the function to return the time until next available instead of a boolean indicating if it is currently available.

It may be hard to write formal unit tests for this function. I encourage writing tests for any helper functions where they seem logical, but full coverage is not required or expected here. As long as we can be sure that it works, that's good enough.

https://github.com/dependabot

Currently, the circuit_sampler takes CircuitStateFn objects or StateVector objects and creates the circuit to be run on a quantum computer using the to_circuit method.

Our job is to make this compatible on any device which will involve converting the to_circuit() method to handle transpiling out of qiskit and into other device compatible circuits. With this and the QuantumInstance working to handle different devices we should have a VQE that will be compatible with different backends.

In __init__ method of qbraid.transpiler.cirq.CirqMomentWrapper:

self._instructions = [CirqInstructionWrapper(i) for i in moment.instructions]

However,

class CirqInstructionWrapper(InstructionWrapper):
    """Wrapper class for Cirq ``Operation`` objects."""

    def __init__(self, instruction: CirqInstruction, qubits):
        ...

So, must extract qubits from Cirq.Moment object in order to create instruction wrapper.

NOTE: If we don't move forward with moment wrapper classes, this issue is null.

The same issue exists in BraketMomentWrapper.

In the init_job method there is some discrepancy in information which is available once the document is created. Most importantly, it seems like circuit_depth is not calculated for Amazon braket circuits (documentation).
While these changes are small, it would help with analysis a good amount.

Thanks!

IBM

Amazon

Updates to the AWS and IBMQ device lists often cause errors on when calling get_devices(refresh=True). If a particular backend is no longer supported and we haven't updated our MongoDB to reflect that yet, we want to catch the error on the front end, and just not load that device into the list, or simply list it as unavailable.

The VQE will require methods to decompose gates into other gates that are comprehensible by a quantum device. Qiskit begins this process using their equivalence library class. The class is a collection of dictionaries that provide the decomposition for each gate.

We believe that we could use our circuit layer to implement a similar decomposition that will be used for Cirq and AWS (we don't want to mess up the procedure for the Qiskit circuits since the VQE is already written in Qiskit).

The circuit layer will require the ability to transpile which has yet to be implemented.
This issue will need to be further fleshed out since the optimization is run in qiskit.

We want to add a Quantum Jobs section to the Lab User Guide portion of our docs page. On this page, we want to give an end-to-end walkthrough of qBraid quantum jobs. A rough list of the topics to cover include:

• What are qBraid credits and how to get them
• Enabling/disabling quantum jobs with qBraid CLI
• Walkthrough of submitting a quantum job
• How to check jobs list & credits with CLI
• How to use the quantum jobs lab extension to view/manage jobs

See the README for how to develop / build the docs.

The quantum-jobs-docs branch already includes a file docs/lab/quantumjobs.rst that you can work from. So after cloning the repo, make sure run

git switch quantum-jobs-docs

to make sure you are developing on the correct branch.

If you're unfamiliar with writing using sphinx / RST, there are lots of good resources online including reStructuredText Primer. You can also just copy and modify code from other files in the repo to add links, pictures, style, etc.

Right now we're performing updates to the qBraid SDK so frequently that people who have the environment installed often run into issues with deprecated API routes. Since we're too early on to account for all backward compatibility, we instead should have a version check. There should be an API route that returns the latest qBraid SDK version. This will be called from within the qBraid SDK, and checked against the installed version. If there is a mismatch, the user will be warned, and/or prompted to install the latest version.

Let's say, as a qBraid Lab user, I used my own IBMQ credentials to submit x number of jobs. These jobs would each have a corresponding MongoDB document listed under my email. Now, let's say I used the qBraid CLI to activate quantum jobs in the qBraid SDK environment. When I now call qbraid.get_jobs(), and try to recreate the IBMQ job object to retrieve the status, I am unable to do so because of a mismatch of credentials. We need a way to recognize this mismatch, either by having a proxy flag on the job document or using some other mechanism.

Functional language to be used internally (for now) in the algorithms layer:

• gate.py (w/some controls for illegal operations)
• library/<gate_name>.py extents gate
• circuit
• instruction
• moment
• qubit (with some controls)
• qubitset (maybe)
• clbitset (maybe)

Right now, qbraid.devices of the device_layer branch contains folders assigned to each qbraid supported circuit-building package. Each circuit-building package is linked to one or more QPU and/or simulator provider(s). Eventually, we will have a get_devices function local to each circuit-building package folder so that this global get_devices function can simply call on each, but for now, it will suffice to have all the functionality contained in this one function (we can easily break it up later). The ultimate goal of this issue is to arrive at an implementation of get_devices that pulls supported device lists directly from each qbraid supported provider. The steps toward this goal are as follows:

1. Fill in the "Available Devices" table of Device_Layer_Docs.ipynb with all of the devices and simulators accessible through braket, cirq, and qiskit (this will require some digging). There are a few listed already as examples, but with some missing information. The following links were the starting point to what exists so far: Amazon Braket supported devices, Google devices, BasicAer: Python-based Simulators.
2. Hard-code get_devices using the completed "Available Devices" table so that we have a working version.
3. Fill in the "Functions to get available devices" table directly underneath. This table should include any existing built-in functions that return lists or dicts of available devices or simulators. For example, qiskit has a backends function that returns a list of backends matching specified filtering. Some packages may not have any such functions, while others may have more than one.
4. Re-implement get_devices so that it leverages any useful updates to the architecture of the devices folder e.g. divide and conquer with local/global versions as described above. Incorporate the "device getter functions" found in Step 3 wherever possible to eliminate hard-coding.

Implement a native qubit operator class that is faster than what is present in openfermion and qiskit

In test_circuit.py line 401 test_cirq_to_all() fails in line 102 qiskit_circuit = qbraid_circuit.transpile("qiskit"). This issue traces back to qBraid/qbraid/transpiler/circuit.py line 90, output_circ.append(*instruction.transpile("qiskit")), which raises qiskit.circuit.exceptions.CircuitError: 'cargs not in this circuit'. The root of this error likely lives in qBraid/qbraid/transpiler/clbit.py inside of the _output_to_qiskit() and/or _create_qiskit_object() function(s). Note: this issue only arises when creating a qiskit measurement gate via the transpiler.

Update Mongo DB and relevant modules to agree with latest Amazon Braket supported devices list: https://docs.aws.amazon.com/braket/latest/developerguide/braket-devices.html

E.g. D-Wave removed, QuEra Aquila added.

The transpiler, in parts, was modeled after the Mitiq interface module. However, Mitiq is licensed under GNU General Public License v3.0. In the future, we need to address this with a re-factor, or by releasing the transpiler module as open-source under the same license.

Add Pytket support for transpiler/interface

See MSFT

https://docs.microsoft.com/en-us/azure/quantum/user-guide/machines/qc-trace-simulator/

The QDK QCTraceSimulator class runs a quantum program without actually simulating the state of a quantum computer. For this reason, the quantum trace simulator is able to run quantum programs that use thousands of qubits. It is useful for two main purposes:

Debugging classical code that is part of a quantum program.
Estimating the resources required to run a given instance of a quantum program on a quantum computer. In fact, the Resources estimator, which provides a more limited set of metrics, is built upon the trace simulator.

In qBraid/tests/circuits/test_circuit.py run test_qiskit_to_all() on line 392. On line 118 we create a qiskit swap gate, and on line 128 we create a qiskit measurement gate. Transpiling each of these gates to a cirq gates fails with Value Error: wrong number of qubits. The measurement gate transpilation is handled differently than other non-parameterized gates, but the swap implementation should work similarly to CX and other non-parameterized two-qubit gates. Running test_braket_to_all() on line 382 for the case of transpiling a braket swap gate to cirq also produces the same error.

Currently, we use a dictionary to map strings to gate objects and thus require as many else-if statements as there are supported gates to extract data. This is highly inefficient, and we should Instead use a data structure and/or search algorithm to eliminate this excessive branching in each qbraid.transpiler._utils sub-module.

The Readme should include the following:

• Description of the repository.
• Installation procedure for local machines.
• How to use it on qBraid.com?
• An example and a link to the tutorials folder for detailed examples.
• Contribution guidelines.
• Authors.

We want to be able to transpile circuits that contain measurements gates / operators. Start with implementing qiskit to/from cirq, since that seems the most straightforward:

• qiskit.circuit.QuantumCircuit.measure
• cirq.measure

After that is working, start looking into converting braket result types to/from cirq. The way braket does measurement is a bit different, so this stay may require a bit more discussion.

To implement, create a new branch in this repository, and commit/push your changes to that branch. Once you are ready for code review, open a pull request that links to this issue. To have changes merged, your new code must meet the following:

• All new code has corresponding unit tests and passes code coverage checks.
• Doc strings have been added/updated for all new/modified functions, and docs pass build test.
• All new code passes black formatting check

See workflows docs and main

See API issue Quantum devices extension: refresh device status #174.

We want programmatic way to get available devices to eliminate the need to periodically update Mongo whenever a new device is added or an old device is removed.

Bump amazon-braket-sdk from 1.27.1 to 1.29.1 #98

via

OpenQASM Local Simulator and OpenQASM default IR #418

When transpiling cirq to qiskit, the qubit ordering/indexing of the resulting circuit is not consistent with the original, nor is it self-consistent. In other words, multiple transpilations of the same cirq circuit result in multiple different qiskit circuits, each with a unique qubit ordering. To see if the matrix representation of a cirq circuit is equivalent to that of a qiskit circuit, one must flip the ordering of the qubits in one of the circuits, because the "to unitary" functions are implemented differently for each. However, this error seems to be an issue with how we track qubit indices internally because simply flipping the qubit order does not resolve the issue. See qBraid/tests/transpiler/test_circuits.ipynb for an in-depth explanation with examples.

Architect and implement quantum data structures layer (MVP)