Add newly serializable gates to supported grid device gates

[NoureldinYosri]

followup to #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:

Cirq/cirq-google/cirq_google/devices/grid_device.py

Line 596 in 2700f95

raise ValueError(f'Operation {operation} contains a gate which is not supported.')

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

Cirq/cirq-google/cirq_google/devices/grid_device.py

Lines 75 to 88 in 0f4822b

	class _GateRepresentations:
	"""Contains equivalent representations of a gate in both DeviceSpecification and GridDevice.
	Attributes:
	gate_spec_name: The name of gate type in `GateSpecification`.
	deserialized_forms: Gate representations to be included when the corresponding
	`GateSpecification` gate type is deserialized into gatesets and gate durations.
	serializable_forms: GateFamilies used to check whether a given gate can be serialized to the
	gate type in this _GateRepresentation.
	"""
	gate_spec_name: str
	deserialized_forms: List[GateOrFamily]
	serializable_forms: List[cirq.GateFamily]

Cirq/cirq-google/cirq_google/devices/grid_device.py

Lines 100 to 101 in 0f4822b

	deserialized_forms=[_SQRT_ISWAP_FSIM_GATE_FAMILY],
	serializable_forms=[_SQRT_ISWAP_FSIM_GATE_FAMILY, cirq.GateFamily(cirq.SQRT_ISWAP)],

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

Cirq/cirq-google/cirq_google/devices/grid_device.py

Lines 251 to 260 in 2700f95

	gate_rep = next((gr for gr in _GATES if gr.gate_spec_name == gate_name), None)
	if gate_rep is None: # pragma: no cover
	warnings.warn(
	f"The DeviceSpecification contains the gate '{gate_name}' which is not recognized"
	" by Cirq and will be ignored. This may be due to an out-of-date Cirq version.",
	UserWarning,
	)
	continue
	gates_list.extend(gate_rep.deserialized_forms)

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]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.76%. Comparing base (a2425eb) to head (0dc1a1c).
Report is 3 commits behind head on main.

❗ 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     

☔ View full report in Codecov by Sentry.
📢 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

[verult]

Last bit of change, everything else lgtm

[verult]

nit: Just cirq.I would be good, to be consistent with the other deserialized_forms. These are what we want to display in the gateset object, so here we keep it as simple as possible.

[NoureldinYosri]

cirq.I is an object (an instance of cirq.IdentityGate), the others are classes. when I use cirq.I the code breaks because it assumes classes.