Skip to main contentIBM Quantum Documentation
This page is from an old version of Qiskit SDK. Go to the latest version

StagedPassManager

class qiskit.transpiler.StagedPassManager(stages=None, **kwargs)

GitHub

Bases: PassManager

A pass manager pipeline built from individual stages.

This class enables building a compilation pipeline out of fixed stages. Each StagedPassManager defines a list of stages which are executed in a fixed order, and each stage is defined as a standalone PassManager instance. There are also pre_ and post_ stages for each defined stage. This enables easily composing and replacing different stages and also adding hook points to enable programmatic modifications to a pipeline. When using a staged pass manager you are not able to modify the individual passes and are only able to modify stages.

By default, instances of StagedPassManager define a typical full compilation pipeline from an abstract virtual circuit to one that is optimized and capable of running on the specified backend. The default pre-defined stages are:

  1. init - Initial passes to run before embedding the circuit to the backend.
  2. layout - Maps the virtual qubits in the circuit to the physical qubits on the backend.
  3. routing - Inserts gates as needed to move the qubit states around until the circuit can be run with the chosen layout on the backend’s coupling map.
  4. translation - Translates the gates in the circuit to the target backend’s basis gate set.
  5. optimization - Optimizes the circuit to reduce the cost of executing it. These passes will typically run in a loop until a convergence criteria is met. For example, the convergence criteria might be that the circuit depth does not decrease in successive iterations.
  6. scheduling - Hardware-aware passes that schedule the operations in the circuit.
Note

For backwards compatibility the relative positioning of these default stages will remain stable moving forward. However, new stages may be added to the default stage list in between current stages. For example, in a future release a new phase, something like logical_optimization, could be added immediately after the existing init stage in the default stage list. This would preserve compatibility for pre-existing StagedPassManager users as the relative positions of the stage are preserved so the behavior will not change between releases.

These stages will be executed in order and any stage set to None will be skipped. If a stage is provided multiple times (i.e. at diferent relative positions), the associated passes, including pre and post, will run once per declaration. If a PassManager input is being used for more than 1 stage here (for example in the case of a Pass that covers both Layout and Routing) you will want to set that to the earliest stage in sequence that it covers.

Initialize a new StagedPassManager object

Parameters

  • stages (Iterable[str]) – An optional list of stages to use for this instance. If this is not specified the default stages list ['init', 'layout', 'routing', 'translation', 'optimization', 'scheduling'] is used. After instantiation, the final list will be immutable and stored as tuple. If a stage is provided multiple times (i.e. at diferent relative positions), the associated passes, including pre and post, will run once per declaration.
  • kwargs – The initial PassManager values for any stages defined in stages. If a argument is not defined the stages will default to None indicating an empty/undefined stage.

Raises

  • AttributeError – If a stage in the input keyword arguments is not defined.
  • ValueError – If an invalid stage name is specified.

Attributes

expanded_stages

Expanded Pass manager stages including pre_ and post_ phases.

invalid_stage_regex

Default value: re.compile('\\s|\\+|\\-|\\*|\\/|\\\\|\\%|\\<|\\>|\\@|\\!|\\~|\\^|\\&|\\:|\\[|\\]|\\{|\\}|\\(|\\)')

stages

Pass manager stages


Methods

append

append(passes, max_iteration=None, **flow_controller_conditions)

Append a Pass Set to the schedule of passes.

Deprecated since version 0.45

Creating flow controllers with flow_controller_conditions keyword arguments was deprecated. Instead, you must explicitly instantiate a controller and set the controller to passes argument.

Deprecated since version 0.46

qiskit.transpiler.passmanager.PassManager.append()’s argument max_iteration is deprecated as of qiskit 0.46. It will be removed in the 1.0 release. ‘max_iteration’ can be set in the constructor.

Parameters

  • passes (Task | list[Task]) – A set of passes (a pass set) to be added to schedule. A pass set is a list of passes that are controlled by the same flow controller. If a single pass is provided, the pass set will only have that pass a single element. It is also possible to append a BaseFlowController instance and the rest of the parameter will be ignored.

  • max_iteration (int) – max number of iterations of passes.

  • flow_controller_conditions (Any) –

    Dictionary of control flow plugins. Following built-in controllers are available by default:

    • do_while: The passes repeat until the callable returns False. Corresponds to DoWhileController.
    • condition: The passes run only if the callable returns True. Corresponds to ConditionalController.

    In general, you have more control simply by creating the controller you want and passing it to append().

Raises

TranspilerError – if a pass in passes is not a proper pass.

draw

draw(filename=None, style=None, raw=False)

Draw the staged pass manager.

passes

passes()

Return a list structure of the appended passes and its options.

Deprecated since version 0.46

The method qiskit.transpiler.passmanager.PassManager.passes() is deprecated as of qiskit 0.46. It will be removed in the 1.0 release. Use .to_flow_controller().tasks instead. This returns a sequence of linearized base task instances in tuple format.

Returns

A list of pass sets, as defined in append().

Return type

list[dict[str, qiskit.transpiler.basepasses.BasePass]]

remove

remove(index)

Removes a particular pass in the scheduler.

Parameters

index (int) – Pass index to remove, based on the position in passes().

Raises

PassManagerError – If the index is not found.

replace

replace(index, passes, max_iteration=None, **flow_controller_conditions)

Replace a particular pass in the scheduler.

Deprecated since version 0.45

Creating flow controllers with flow_controller_conditions keyword arguments was deprecated. Instead, you must explicitly instantiate a controller and set the controller to passes argument.

Deprecated since version 0.46

qiskit.transpiler.passmanager.PassManager.replace()’s argument max_iteration is deprecated as of qiskit 0.46. It will be removed in the 1.0 release. ‘max_iteration’ can be set in the constructor.

Parameters

  • index (int) – Pass index to replace, based on the position in passes().
  • passes (BasePass | list[BasePass]) – A pass set to be added to the pass manager schedule.
  • max_iteration (int) – max number of iterations of passes.
  • flow_controller_conditions (Any) – Dictionary of control flow plugins. See qiskit.transpiler.PassManager.append() for details.

run

run(circuits, output_name=None, callback=None)

Run all the passes on the specified circuits.

Parameters

  • circuits (_CircuitsT) – Circuit(s) to transform via all the registered passes.

  • output_name (str | None) – The output circuit name. If None, it will be set to the same as the input circuit name.

  • callback (Callable | None) –

    A callback function that will be called after each pass execution. The function will be called with 5 keyword arguments:

    pass_ (Pass): the pass being run
    dag (DAGCircuit): the dag output of the pass
    time (float): the time to execute the pass
    property_set (PropertySet): the property set
    count (int): the index for the pass execution
    Note

    Beware that the keyword arguments here are different to those used by the generic BasePassManager. This pass manager will translate those arguments into the form described above.

    The exact arguments pass expose the internals of the pass manager and are subject to change as the pass manager internals change. If you intend to reuse a callback function over multiple releases be sure to check that the arguments being passed are the same.

    To use the callback feature you define a function that will take in kwargs dict and access the variables. For example:

    def callback_func(**kwargs):
        pass_ = kwargs['pass_']
        dag = kwargs['dag']
        time = kwargs['time']
        property_set = kwargs['property_set']
        count = kwargs['count']
        ...

Returns

The transformed circuit(s).

Return type

_CircuitsT

to_flow_controller

to_flow_controller()

Linearize this manager into a single FlowControllerLinear, so that it can be nested inside another pass manager.

Returns

A linearized pass manager.

Return type

RunningPassManager

Was this page helpful?
Report a bug or request content on GitHub.