Add newly serializable gates to quantum engine gates

[NoureldinYosri]

followup to https://github.com/quantumlib/Cirq/pull/6479

[NoureldinYosri]

@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.

[wcourtney]

@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.

[NoureldinYosri]

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

https://github.com/quantumlib/Cirq/blob/0f4822b1ee85373c675222a22040d7f75adc6e60/cirq-google/cirq_google/devices/grid_device.py#L75-L88

https://github.com/quantumlib/Cirq/blob/0f4822b1ee85373c675222a22040d7f75adc6e60/cirq-google/cirq_google/devices/grid_device.py#L100-L101

A gate failes validation if it's not a member of the serializable_forms of any _GateRepresentations

https://github.com/quantumlib/Cirq/blob/2700f959ead6fb7c3bdcbdd96ce936e78a34843c/cirq-google/cirq_google/devices/grid_device.py#L251-L260

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.

[codecov[bot]]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6499      +/-   ##
==========================================
- Coverage   97.76%   97.76%   -0.01%     
==========================================
  Files        1105     1105              
  Lines       95130    95030     -100     
==========================================
- Hits        93001    92902      -99     
+ Misses       2129     2128       -1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[wcourtney]

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

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

[verult]

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.

[NoureldinYosri]

@verult PTAL