generate_preset_pass_manager as a user-facing function about qiskit HOT 5 OPEN

The following arguments are present in transpile but not generate_preset_pass_manager (excluding arguments that are present in PassManager.run instead):

• dt
• ignore_backend_supplied_default_methods

Do we need to add these arguments to generate_preset_pass_manager?

It's possible that dt has been subsumed by other arguments, such as target and/or timing_constraints; is this correct?

As for ignore_backend_supplied_default_methods, I couldn't quite understand its description from the documentation. Is it still needed?

from qiskit.

Come up with a better name (transpiler? build_pm?). It needs to convey what transpile is today

For this item, I suggest to slowly replace StagedPassManager for Transpiler object, which can have a constructor with the generate_preset_pass_manager parameters.

Currently, with generate_preset_pass_manager:

from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit_ibm_runtime.fake_provider import FakeAlmadenV2 

backend = FakeAlmadenV2()
 
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
type(pm)  # qiskit.transpiler.passmanager.StagedPassManager

pm.run(....)

Suggestion:

from qiskit import Transpiler
from qiskit_ibm_runtime.fake_provider import FakeAlmadenV2 

backend = FakeAlmadenV2()
 
transpiler = Transpiler(backend=backend, optimization_level=1)
type(transpiler)  # qiskit.transpiler.passmanager.Transpiler

transpiler.run(...)

from qiskit.

Luciano: I don't think it's necessarily the best idea to treat a particular preset-configuration function as if it's a class. Qiskit's presets might be commonly used, but making them the default type constructor could be very misleading about what StagedPassManager represents as a class, which is to the define the structure of how the pass manager is constructed. It makes it harder for users to build a new pass manager from scratch, which is something we'd really be explicitly promoting by wanting to promote the pass-manager interfaces to be higher level.

That's going to make it seem like the particular stages we use are special and inherent to the structure, and that's not intended at all, and will clash with structures that the pulse-compiler, using the qiskit.passmanager base classes want to do.

For the "Pulse has its own compiler" reason, I'd vote against making this pass manager part of the base qiskit space; I think something like

import qiskit.transpiler

transpiler = qiskit.transpiler.preset(backend=backend, optimization_level=1)
transpiler.run(qc)
# type(transpiler) is qiskit.transpiler.StagedPassManager

as the "low-knowledge path" is just as / more readable than Transpiler's mixing of behavioural (StagedPassManager) and configuration (qiskit.transpiler.preset) concerns. This way also doesn't compromise the experience of the "high-knowledge" user, who's entirely constructing their own pass manager / staged pass manager to do complex things:

from qiskit.transpiler import StagedPassManager, PassManager
from qiskit.transpiler.passes import ...

init = PassManager([ ... ])
optimization = PassMangaer([ ... ])

pm = StagedPassManager(init=init, optimization=optimization)
pm.run(qc)

from qiskit.

One suggestion that came up at the dev meeting today is to set a default value for optimization_level. We didn't decide what the default value should be.

from qiskit.

From internal discussions the proposal that came forward is that we define a simpler function default_passmanager. This is a shorter alternative to generate_preset_pass_manager.
This will return a PassManager that lies somewhere between levels 2 and 3: basically level 3 but with more reasonable timeouts so the worst-case runtime is bounded better.
In documentation we write an example of customizing this: for example overriding the routing stage or the init stage to do different routing or different synthesis.

from qiskit.