Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 94 additions & 1 deletion docs/workflow.rst
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,106 @@
Using dwave-gate
================

The |cloud| quantum cloud service provides access to a simulator that enables
The |cloud|_ quantum cloud service provides access to a simulator that enables
you to test gate-model circuits intended to be executed on a dual-rail quantum
processing unit (QPU). You describe your circuits using the ``dwave-gate``
package's quantum circuit description language (QCDL), described here.

.. _QuantumCircuit: https://quantum.cloud.ibm.com/docs/en/api/qiskit/qiskit.circuit.QuantumCircuit

.. _qcdl_onboarding:

Onboarding for Beta Testers
===========================

.. important::
Features for real-time control, which are being phased into dual-rail
quantum computing systems, are already available on the simulator in the
|cloud|_ service for prototyping and learning.
Comment on lines +20 to +22

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad to see this mentioned somewhere


To construct :term:`QCDL` programs and submit to the dual-rail simulator in the
|cloud|_ service you need the following:

1. A |cloud|_ account that has been invited to beta test the dual-rail
simulator.
2. A development environment with the :ref:`index_ocean_sdk`.

.. _qcdl_onboarding_new_users:

New Users
---------

If you are already using Ocean software for an existing |cloud|_ service
account, see the :ref:`qcdl_onboarding_previous_users` section for working with
another project.

If you have accepted an invitation to the |cloud|_ service for the first time to
use the dual-rail simulator, the following documentation gets you started with
submitting your programs:

* The :ref:`index_leap_sapi` section.

This section describes the |cloud|_ service: the dashboard where you can see
your access to :term:`solver`\ s such as the dual-rail simulator, the API
token you need to submit programs to the simulator, whitelisting information
if required by your organization, and more.

* The :ref:`ocean_index_get_started` section.

This section explains how to start using the :ref:`index_ocean_sdk`, which
lets you write :term:`QCDL` programs and submit them to the simulator.

.. note::
Installing the SDK is recommended. If you chose to install only the
:ref:`index_gate` package, see the installation instructions
`here <https://github.com/dwavesystems/dwave-gate/blob/main/README.rst>`_.

.. _qcdl_onboarding_previous_users:

Previous Users
--------------

To submit programs to the dual-rail simulator in the |cloud|_ service, you must
accept the emailed invitation to a new project. You use the API token from this
project to access and send jobs to the simulator.

The :ref:`ocean_leap_authorization` section describes how to work with multiple
projects (see the "Multiple Leap Projects" tab).

The following are two simple ways to use the beta-tester project's API token
from your existing development environment.

* Add a section to your ``dwave.conf`` file.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is ti clear to users how/where to create this file? It hasn't been so for me and my team

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dwave config ls should list all available dwave.conf files, in order of preference.

@randomir randomir Sep 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you make a good point, @qci-amos, we should advise users explicitly to just run this:

dwave config create --profile beta

That command will locate the config file and/or create one if it doesn't exist; then it will create a new profile called beta (or update the existing one); and ask the user for the SAPI token.

@randomir randomir Sep 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should provide a fully automated flow example.

  1. Authorize Ocean to access Leap:
$ dwave auth login
Please visit the following URL to authorize Ocean: https://cloud.dwavesys.com/leap/openid/authorize?...
Authorization completed successfully. You can now use "dwave auth get" to fetch your token.
  1. Configure your beta profile:
$ dwave config create --profile beta --auto-token --project "D-Wave Gate Model Simulator Beta"
Using the simplified configuration flow.
Try 'dwave config create --full' for more options.

Updating existing configuration file: /home/radomir/.config/dwave/dwave.conf
Creating new profile: beta
Fetched SAPI token for project 'D-Wave Gate Model Simulator Beta' (R4zH) from Leap API.
Configuration saved.

Or as a one-liner:

dwave auth login && dwave config create --profile beta --auto-token --project "D-Wave Gate Model Simulator Beta"

Note I used the full project name for clarity, but it can be shortened to R4zH:

dwave auth login && dwave config create --profile beta --auto-token --project R4zH


You can see your ``dwave.conf`` file using the methods described in the
:ref:`cloud_configuration` or using the :ref:`D-Wave CLI <ocean_dwave_cli>`
section.
Comment on lines +78 to +80

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be nice if there was a cli way to do this


For example, add a ``beta`` section::

[defaults]
token = ABC-123456789123456789123456789

[beta]
token = BETA-123456789123456789123456789
Comment on lines +87 to +88

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my conf has leap_client_id and metadata_api_endpoint. Are these not needed for the beta testers?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed. The PROD values for these params are shipped with the client. You had to manually override/specify them if you ran in non-PROD envs.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so "beta" is some sort of alias/subset of PROD?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, "beta" (token) here refers to a new project "D-Wave Gate Model Simulator Beta". It's a project in the PROD environment.


You can then set ``profile="beta"`` to use the beta-tester project's API
token when accessing the simulator.

>>> from dwave.gate.leap import LeapQCDLSimulator
...
>>> simulator = LeapQCDLSimulator(profile="beta") # doctest: +SKIP

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't there a way to configure a default in dwave.conf?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dwave config create will update the default profile by default. That makes sense for new D-Wave users that are trying this out, but not for existing users. Now, I don't know who's going to be onboarding here.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

most of the examples that Trevor K and I are planning, he wouldn't specify profile= so ideally we could have a way to guide users to simply configure their dwave.conf appropriately instead of either encoding the profile in the examples or asking users to do that

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also specify the default profile in the DWAVE_PROFILE env var. That's the easiest way to "specialize" an environment. A shell, or a container.

$ DWAVE_PROFILE=beta python
>>> from dwave.gate.qcdl.leap import LeapQCDLSimulator
>>> simulator = LeapQCDLSimulator()
>>> simulator.properties
{'max_shots': 1000000, ...


* Set the ``DWAVE_API_TOKEN`` environment variable.

You can set this environment variable for a Unix operating system with a
Bash command such as,
``export DWAVE_API_TOKEN="BETA-123456789123456789123456789"``, for example,
or for a Windows system with a command such as
``set DWAVE_API_TOKEN=BETA-123456789123456789123456789``.

Remember to delete that environment variable when you return to your
work on your previous project.

.. _qcdl_programming_basic:

Expand Down