qiskit.transpiler.generate_preset_pass_manager

qiskit.transpiler.generate_preset_pass_manager(optimization_level=2, backend=None, target=None, basis_gates=None, inst_map=None, coupling_map=None, instruction_durations=None, backend_properties=None, timing_constraints=None, initial_layout=None, layout_method=None, routing_method=None, translation_method=None, scheduling_method=None, approximation_degree=1.0, seed_transpiler=None, unitary_synthesis_method='default', unitary_synthesis_plugin_config=None, hls_config=None, init_method=None, optimization_method=None, dt=None, qubits_initially_zero=True, *, _skip_target=False)

Generate a preset PassManager

This function is used to quickly generate a preset pass manager. Preset pass managers are the default pass managers used by the transpile() function. This function provides a convenient and simple method to construct a standalone PassManager object that mirrors what the transpile() function internally builds and uses.

The target constraints for the pass manager construction can be specified through a Target instance, a BackendV1 or BackendV2 instance, or via loose constraints (basis_gates, inst_map, coupling_map, backend_properties, instruction_durations, dt or timing_constraints). The order of priorities for target constraints works as follows: if a target input is provided, it will take priority over any backend input or loose constraints. If a backend is provided together with any loose constraint from the list above, the loose constraint will take priority over the corresponding backend constraint. This behavior is independent of whether the backend instance is of type BackendV1 or BackendV2, as summarized in the table below. The first column in the table summarizes the potential user-provided constraints, and each cell shows whether the priority is assigned to that specific constraint input or another input (target/backend(V1)/backend(V2)).

Parameters

• optimization_level (int) –

  The optimization level to generate a StagedPassManager for. By default optimization level 2 is used if this is not specified. This can be 0, 1, 2, or 3. Higher levels generate potentially more optimized circuits, at the expense of longer transpilation time:

  • 0: no optimization
  • 1: light optimization
  • 2: heavy optimization
  • 3: even heavier optimization

• backend (Backend) – An optional backend object which can be used as the source of the default values for the basis_gates, inst_map, coupling_map, backend_properties, instruction_durations, timing_constraints, and target. If any of those other arguments are specified in addition to backend they will take precedence over the value contained in the backend.

• target (Target) – The Target representing a backend compilation target. The following attributes will be inferred from this argument if they are not set: coupling_map, basis_gates, instruction_durations, inst_map, timing_constraints and backend_properties.

• basis_gates (list) – List of basis gate names to unroll to (e.g: ['u1', 'u2', 'u3', 'cx']).

• inst_map (InstructionScheduleMap) – DEPRECATED. Mapping object that maps gates to schedules. If any user defined calibration is found in the map and this is used in a circuit, transpiler attaches the custom gate definition to the circuit. This enables one to flexibly override the low-level instruction implementation.

• coupling_map (CouplingMap orlist) –

  Directed graph represented a coupling map. Multiple formats are supported:

  1. CouplingMap instance
  2. List, must be given as an adjacency matrix, where each entry specifies all directed two-qubit interactions supported by backend, e.g: [[0, 1], [0, 3], [1, 2], [1, 5], [2, 5], [4, 1], [5, 3]]

• instruction_durations (InstructionDurations orlist) –

  Dictionary of duration (in dt) for each instruction. If specified, these durations overwrite the gate lengths in backend.properties. Applicable only if scheduling_method is specified. The format of instruction_durations must be as follows: They must be given as an InstructionDurations instance or a list of tuples

  ` [(instruction_name, qubits, duration, unit), ...]. | [('cx', [0, 1], 12.3, 'ns'), ('u3', [0], 4.56, 'ns')] | [('cx', [0, 1], 1000), ('u3', [0], 300)] `

  If unit is omitted, the default is 'dt', which is a sample time depending on backend. If the time unit is 'dt', the duration must be an integer.

• dt (float) – Backend sample time (resolution) in seconds. If provided, this value will overwrite the dt value in instruction_durations. If None (default) and a backend is provided, backend.dt is used.

• timing_constraints (TimingConstraints) –

  Hardware time alignment restrictions. A quantum computer backend may report a set of restrictions, namely:

  • granularity: An integer value representing minimum pulse gate resolution in units of dt. A user-defined pulse gate should have duration of a multiple of this granularity value.
  • min_length: An integer value representing minimum pulse gate length in units of dt. A user-defined pulse gate should be longer than this length.
  • pulse_alignment: An integer value representing a time resolution of gate instruction starting time. Gate instruction should start at time which is a multiple of the alignment value.
  • acquire_alignment: An integer value representing a time resolution of measure instruction starting time. Measure instruction should start at time which is a multiple of the alignment value.

  This information will be provided by the backend configuration. If the backend doesn’t have any restriction on the instruction time allocation, then timing_constraints is None and no adjustment will be performed.

• initial_layout (Layout | List[int]) – Initial position of virtual qubits on physical qubits.

• layout_method (str) – The Pass to use for choosing initial qubit placement. Valid choices are 'trivial', 'dense', and 'sabre', representing TrivialLayout, DenseLayout and SabreLayout respectively. This can also be the external plugin name to use for the layout stage of the output StagedPassManager. You can see a list of installed plugins by using list_stage_plugins() with "layout" for the stage_name argument.

• routing_method (str) – The pass to use for routing qubits on the architecture. Valid choices are 'basic', 'lookahead', 'stochastic', 'sabre', and 'none' representing BasicSwap, LookaheadSwap, StochasticSwap, SabreSwap, and erroring if routing is required respectively. This can also be the external plugin name to use for the routing stage of the output StagedPassManager. You can see a list of installed plugins by using list_stage_plugins() with "routing" for the stage_name argument.

• translation_method (str) – The method to use for translating gates to basis gates. Valid choices 'translator', 'synthesis' representing BasisTranslator, and UnitarySynthesis respectively. This can also be the external plugin name to use for the translation stage of the output StagedPassManager. You can see a list of installed plugins by using list_stage_plugins() with "translation" for the stage_name argument.

• scheduling_method (str) – The pass to use for scheduling instructions. Valid choices are 'alap' and 'asap'. This can also be the external plugin name to use for the scheduling stage of the output StagedPassManager. You can see a list of installed plugins by using list_stage_plugins() with "scheduling" for the stage_name argument.

• backend_properties (BackendProperties) – Properties returned by a backend, including information on gate errors, readout errors, qubit coherence times, etc.

• approximation_degree (float) – Heuristic dial used for circuit approximation (1.0=no approximation, 0.0=maximal approximation).

• seed_transpiler (int) – Sets random seed for the stochastic parts of the transpiler.

• unitary_synthesis_method (str) – The name of the unitary synthesis method to use. By default 'default' is used. You can see a list of installed plugins with unitary_synthesis_plugin_names().

• unitary_synthesis_plugin_config (dict) – An optional configuration dictionary that will be passed directly to the unitary synthesis plugin. By default this setting will have no effect as the default unitary synthesis method does not take custom configuration. This should only be necessary when a unitary synthesis plugin is specified with the unitary_synthesis_method argument. As this is custom for each unitary synthesis plugin refer to the plugin documentation for how to use this option.

• hls_config (HLSConfig) – An optional configuration class HLSConfig that will be passed directly to HighLevelSynthesis transformation pass. This configuration class allows to specify for various high-level objects the lists of synthesis algorithms and their parameters.

• init_method (str) – The plugin name to use for the init stage of the output StagedPassManager. By default an external plugin is not used. You can see a list of installed plugins by using list_stage_plugins() with "init" for the stage name argument.

• optimization_method (str) – The plugin name to use for the optimization stage of the output StagedPassManager. By default an external plugin is not used. You can see a list of installed plugins by using list_stage_plugins() with "optimization" for the stage_name argument.

• qubits_initially_zero (bool) – Indicates whether the input circuit is zero-initialized.

Returns

The preset pass manager for the given options

Return type

StagedPassManager

Raises

ValueError – if an invalid value for optimization_level is passed in.