Utilities for approximate hardware noise

[95-martin-orion]

This PR is part of #4640. It adds utility functions and objects for use in noise model generation.

Key changes include:

• Extraction of noise metric conversion methods from NoiseProperties. All top-level functions in this PR except decoherence_pauli_error were copied directly from the existing NoiseProperties class. These methods will be removed from NoiseProperties in an upcoming PR.
• Addition of decoherence_pauli_error. This method is copied from internal noise-generation tools.
• Addition of OpIdentifier class. This class is used as a key for noise-insertion maps.
• Addition of PHYSICAL_GATE_TAG. This tag is applied to "real" gates during noise model generation to prevent sequential noise models from applying noise to noise generated by a previous noise model.

[MichaelBroughton]

Is this class really needed ? (having looked at other PRs as well).

[95-martin-orion]

We could probably get away without it, but the result would be a lot messier. Here are the alternatives I considered:

• Just use Operation (it's hashable and contains the required info): this requires every current OpIdentifier reference to have some concept of "canonical" gates for each type supported in noise model generation (e.g. the PhasedXZGate constructor requires (x|z|axis_phase)_exponent args). This is considerably less convenient than just converting OpIDs to Operations during serialization.
• Use a (Gate, qubits) tuple: this works about the same as OpIdentifier, but it's ultimately less readable to be saying op_id[0] and op_id[1:] instead of op_id.gate_type and op_id.qubits

If you have any other recommendations, I'm happy to consider them, but my sense from working through this is that OpIdentifier adds readability for relatively little cost. I opted not to surface OpIdentifier at the cirq package level to avoid any potential confusion.

[95-martin-orion]

Needed some force-pushing to bring in the GateFamily changes, but OpIdentifier now relies on a GateFamily under the hood for matching operations.

[dkafri]

Couple more comments

[dkafri]

What would we do if we want an OpIdentifier for an Operation without a gate?

[95-martin-orion]

None of the models from noise required that, so I opted not to support it. Is there a particular case you have in mind?

(CircuitOperations are a definite complication as far as matching is concerned, but I don't expect them to be used as the match target for an OpIdentifier.)

[dkafri]

In my use cases I had custom Operations that were not constructed using a Gate. I suppose the user could always generate a placeholder Gate object to identify any such Operation.

I can't give any native cirq Operation where this may be an issue since I am not so familiar with all the native cirq ops. One place you may have issues is with measurement operations. I.e. the output of cirq.measure has a gate output that is key dependent.

[95-martin-orion]

That case should be OK - this only checks against qubits and gate types, both of which are defined explictly in the cirq.measure call. On a more general note, Cirq has been moving towards an "all operations have gates" structure (#4683), which should help with any remaining problem cases.

[95-martin-orion]

Pinging @MichaelBroughton for re-review.

[MichaelBroughton]

LGTM after snake case fix in a few of the helper functions there.

[CirqBot]

Automerge cancelled: A required status check is not present.

Missing statuses: ['Misc check', 'Pytest MacOS (3.7)', 'Pytest MacOS (3.8)', 'Pytest MacOS (3.9)', 'Pytest Windows (3.7)', 'Pytest Windows (3.8)', 'Pytest Windows (3.9)', 'Typescript lint check', 'Typescript tests', 'Typescript tests coverage']