Open alonkukl opened 1 day ago
I think that the root cause of this crash is the way a layer generator is created from a gate set.
When a layer generator isn't given to QSearch (and to LEAP), then it asks the gate set object to generate a layer generator, using the function build_mq_layer_generator
.
In our case, there is no single qubit gate, so the above function adds the U3 as a single qubit, which in turn QFactor can't handle.
BQSKit shouldn't have added a gate that wasn't part of the original gate set. This behaviour is documented The resulting layer generator will use arbitrary single-qudit gates.
but it is wrong. It can produce a warning that a single qubit gate is missing, but it shouldn't add a gate to the gate set.
In my case, I can bypass this issue, by directly creating QSearch and providing it with the correct layer generator
WideLayerGenerator(VariableUnitaryGate(3), None)
Most gate sets will not include a general single-qudit gate, so we introduce one during compilation stages that focus on multi-qudit gate optimization/transpilation. You are right; in this case and cases like this, we shouldn't be mocking with the gate set. We should check if the gate set contains multi-qudit general gates. If so, we don't need to use the layer generator with single-qudit gates added.
I have a different perspective.
If the user has explicitly provided a gate set, the tool shouldn't change it. The tool can give a warning or an error if the gate set isn't general enough or has other issues.
In the case that I am referring to, the gate set is modified for specific compilation stages. The later stages reverse the modifications, so the user gate set is always honored.
OK, then your solution above looks good
The following code makes BQSkit crash with
pyo3_runtime.PanicException: not implemented
. Probably QFactor is getting a circuit with gates it can't handle.