Closed NoureldinYosri closed 8 months ago
@verult @wcourtney is this what is needed to pass validation steps like ?
INVALID_PROGRAM: Operation I(q(9, 4)) contains a gate which is not supported.
@verult @wcourtney is this what is needed to pass validation steps like ?
INVALID_PROGRAM: Operation I(q(9, 4)) contains a gate which is not supported.
This validation happens client side using the gate set provided on the device description: https://github.com/quantumlib/Cirq/blob/2700f959ead6fb7c3bdcbdd96ce936e78a34843c/cirq-google/cirq_google/devices/grid_device.py#L596
The gateset is currently just a static superset of all supported gates, configured here, but should eventually rely on the gates specific to the device config.
I think we are talking about different things, the same gate/gateset can have different preresentations in Cirq. I think this is why we have serializable_forms
and deserialized_forms
A gate failes validation if it's not a member of the serializable_forms
of any _GateRepresentations
This PR just says that cirq.I, cirq.HPowGate, cirq.ops.SinqleQubitCliffordGate can be passed along as XZ gates, we can change this later if we want.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 97.76%. Comparing base (
a2425eb
) to head (0dc1a1c
). Report is 3 commits behind head on main.:exclamation: Current head 0dc1a1c differs from pull request most recent head 668c683. Consider uploading reports for the commit 668c683 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I think we are talking about different things, the same gate/gateset can have different preresentations in Cirq. I think this is why we have
serializable_forms
anddeserialized_forms
Looking at the only usage of serializable_forms
and deserialized_forms
- in _serialize_gateset_and_gate_durations
and _deserialize_gateset_and_gate_durations
(respectively) - it looks like those lists are used to (de)serialize gatesets rather than operations.
@verult has more context about the gateset design
GridDevice
uses the metadata.gateset
attribute to validate circuits. On the server side, this gateset is first constructed using the default gateset @wcourtney mentioned, but as part of instantiation, GridDevice
uses the proto serialization and deserialization logic to compute the "canonical" gateset, which includes the most general GateFamilies possible for the provided gateset. The GridDevice
instance on the cirq_google
client side also uses these canonical gatesets.
serializable_forms
is used to check whether a particular Cirq gate can be serialized to the corresponding GateSpecification
proto message. deserialized_forms
is the collection of gates and GateFamilies which will populate the gateset when the message is deserialized. So to make a gate pass validation, it needs to be added to both serializable_forms
and deserialized_forms
.
IIRC the main reason why the two fields are distinct is that ops.FSimGateFamily(gates_to_accept=[cirq.CZ])
does not accept the gate family cirq.GateFamily(cirq.CZ)
. We could reconsider this constraint if this makes adding gates harder.
Apologies for the confusion - I'm planning to add documentation for adding gates soon.
@verult PTAL
followup to https://github.com/quantumlib/Cirq/pull/6479