Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advanced Runtime topic edits #1254

Merged
merged 7 commits into from
Apr 29, 2024
Merged
Show file tree
Hide file tree
Changes from 2 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
8 changes: 4 additions & 4 deletions docs/run/advanced-runtime-options.mdx
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Advanced runtime options
description: Specify options when building with Qiskit runtime primitives
title: Advanced Qiskit Runtime options
description: Specify options when building with Qiskit Runtime primitives

---

Expand Down Expand Up @@ -129,7 +129,7 @@ sampler.run([circuit1, circuit2], shots=128)
</TabItem>

<TabItem value="PrimV1" label="V1 primitives">
You can pass any options to `run()`. Because most users will only overwrite a few options at the job level, it is not necessary to specify the category the options are in. The code below, for example, specifies `shots=1024` instead of `execution={"shots": 1024}` (which is also valid).
You can pass any options to `run()`. Because most users will only overwrite a few options at the job level, it is not necessary to specify the options category. The code below, for example, specifies `shots=1024` instead of `execution={"shots": 1024}` (which is also valid).
```python
estimator = Estimator(session=backend, options=options)
result = estimator.run(circuit, observable, shots=1024).result()
Expand Down Expand Up @@ -271,7 +271,7 @@ algorithm. These methods can be set through the `resilience_level` option. For

<Tabs>
<TabItem value="PrimV2" label="Estimator V2">
With Estimator V2, you can set resilience levels 0-2 and you can also turn on and off various error mitigation settings for fine tuning.
With Estimator V2, you can set resilience levels 0-2 and you can also turn on and off various error mitigation settings for fine-tuning.

```python
estimator = Estimator(backend=backend)
Expand Down
18 changes: 5 additions & 13 deletions docs/run/max-execution-time.mdx
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
---
title: Maximum execution time for a Qiskit Runtime job or session
description: Describes how long a Qiskit Runtime job or session can run.
title: Maximum execution time for a Qiskit Runtime job
description: Describes how long a Qiskit Runtime job can run.

---

# Maximum execution time for a Qiskit Runtime job or session
# Maximum execution time for a Qiskit Runtime job

To ensure fairness and help control costs, there is a maximum amount of time each Qiskit Runtime job and session can run. If a job exceeds this time limit, it is forcibly canceled and a `RuntimeJobMaxTimeoutError` exception is raised. If a session exceeds its limits, any queued jobs are canceled but any jobs that are already running are not.
To ensure fairness and help control costs, there is a maximum amount of time each Qiskit Runtime job can run. If a job exceeds this time limit, it is forcibly canceled and a `RuntimeJobMaxTimeoutError` exception is raised.

<span id="max-job"></span>
## Job maximum execution time
Expand All @@ -16,11 +16,7 @@ The maximum execution time for a job is the smaller of these values:
- The value set for max_execution_time
- The system-determined job timeout value

<Admonition type="note">
As of 7 August 2023, the `max_execution_time` value is based on _quantum time_ instead of wall clock time. Quantum time is the duration a quantum system is committed to fulfilling a user request.

Simulator jobs continue to use wall clock time because they do not have quantum time.
</Admonition>
The `max_execution_time` value is based on _quantum time_, not wall clock time. Quantum time is the duration a quantum system is committed to fulfilling a user request. However, simulator jobs use wall clock time because they do not have quantum time.
beckykd marked this conversation as resolved.
Show resolved Hide resolved

Set the maximum execution time (in seconds) on the job options by using one of the following methods:

Expand Down Expand Up @@ -48,10 +44,6 @@ The system calculates an appropriate job timeout value based on the input circui

For example, if you specify `max_execution_time=5000` (approximately 83 minutes), but the system determines it should not take more than 5 minutes (300 seconds) to execute the job, then the job is canceled after 5 minutes.

## Session maximum execution time
beckykd marked this conversation as resolved.
Show resolved Hide resolved

When a session is started, it is assigned a maximum session timeout value. After this timeout is reached, the session is terminated, any jobs that are already running continue running, and any queued jobs that remain in the session are put into a failed state. For instructions to set the session maximum time, see [Specify the session length](run-jobs-in-session#specify-length).

## Other limitations

* Inputs to jobs cannot exceed 64MB in size.
Expand Down
Loading