Implement custom observables for each benchmark

[jordandsullivan]

Is your feature request related to a problem? Please describe.
Currently for our expectation value benchmarks, we measure the Z operator on all qubits (equiv to preparing 0), but this may not be the appropriate benchmark for all of the circuits.

Describe the solution you'd like
Each small circuit used in the benhcmarking:

ucc/benchmarks/scripts/run_benchmarks.sh

Lines 49 to 56 in 8471ab3

	QASM_EXPVAL_FILES=(
	"benchpress/qaoa_barabasi_albert_N10_3reps_basis_rz_rx_ry_cx.qasm"
	"benchpress/qv_N010_12345_basis_rz_rx_ry_cx.qasm"
	"benchpress/qft_N010_basis_rz_rx_ry_cx.qasm"
	"benchpress/square_heisenberg_N9_basis_rz_rx_ry_cx.qasm"
	"ucc/prep_select_N10_ghz_basis_rz_rx_ry_h_cx.qasm"
	"ucc/qcnn_N10_4layers_basis_rz_rx_ry_h_cx.qasm"
	)

should have its own observable, which is currently set for all files in the exp_val python script as the Pauli Z operator:

ucc/benchmarks/scripts/expval_benchmark.py

Line 83 in 8471ab3

obs_str = "Z" * compiled_circuit.num_qubits

Describe alternatives you've considered
If it is difficult to determine an appropriate observable, we can simulate the ideal distribution and simply report the overlap of the simulated with the ideal rather than an observable measurement, but it would be preferable I think to use benchmarks closer to what you would be able to run on hardware, where we do not have access to the full density matrix! But we can still use this information to determine appropriate observables to measure (e.g. if the output measurements are all zeros or all ones, clearly measuring the ZZZ operator on all qubits would be appropriate, or if the correlations appear to be pairwise, doing a pairwise measurement, e.g XXII, XIIX would be appropriate, etc.)

We could leave the observable the same just for consistency, but I would argue choosing ones that would actually be relevant for the person running the circuit is more useful.

Suggested observables

(need to be confirmed)

1. QAOA on Barabási-Albert graph (qaoa_barabasi_albert_N10_3reps_basis_rz_rx_ry_cx.qasm):
   QAOA typically involves measuring the expectation value of the Hamiltonian corresponding to the optimization problem.
   Observable: Problem Hamiltonian (e.g., Ising or MaxCut Hamiltonian), however since this circuit was copied from Qiskit benchpress, we don't know exactly which Hamiltonian was used to generate this QASM code, we would need to reverse engineer or ask the devs to provide this for us.

2. Quantum Volume Circuit (qv_N010_12345_basis_rz_rx_ry_cx.qasm):
   For a QV circuit, the key measurement involves comparing the measured output distribution to the ideal distribution (obtained by simulating the circuit classically). Observables aren't directly applied here, but rather, a statistical metric such as the Heavy Output Probability (HOP) is used.

3. Quantum Fourier Transform (qft_N010_basis_rz_rx_ry_cx.qasm):
   The QFT circuit's observable is often the measurement of qubit states in the computational basis or Pauli operators.
   Observable: Pauli Z on each qubit (for detecting phase shifts). This one works with our existing observable
   observable = Z ^ Z ^ Z ^ Z ^ Z # Customize based on the number of qubits

4. Square Heisenberg model (square_heisenberg_N9_basis_rz_rx_ry_cx.qasm):
   The Heisenberg model is often studied using interactions between spin qubits. Observable measurements involve spin operators (Pauli operators).
   Observable: Pauli X, Y, or Z operators on pairs of qubits (to measure correlation or spin interaction). Again because it came from QASM code in Qiskit benchpress we don't know exactly which Hamiltonian was used to define this problem, we would need to reverse engineer or ask the devs to provide this for us.
   observable = (X ^ X) + (Y ^ Y) + (Z ^ Z) # Customize based on the interaction

5. GHZ State Preparation (prep_select_N10_ghz_basis_rz_rx_ry_h_cx.qasm):
   The GHZ state preparation circuit will measure correlations between qubits.
   Observable: Measurement of all qubits in the computational basis (Bell-state correlation). This one works with our existing observable
   observable = (I ^ I ^ I ^ I ^ I) # All qubits in computational basis

6. Quantum Convolutional Neural Network (qcnn_N10_4layers_basis_rz_rx_ry_h_cx.qasm):
   For a quantum neural network, the observable typically involves the Pauli expectation values or measurements at the output layer.
   Observable: Pauli operators or observable at the output layer qubits

observable_1 = Z ^ Z ^ Z ^ Z ^ Z ^ Z ^ Z ^ Z ^ Z ^ Z # Customize based on your quantum classifier
observable_2 = X ^ X ^ I ^ I ^ I ^ I ^ I ^ I ^ I ^ I ^ I ^ I # Pairwise mmts

[Misty-W]

1. We can use the problem Hamiltonian described in https://arxiv.org/pdf/2009.01095.
2. Adapt code from mitiq-metrics/volume/qv_batch_ibmq.ipynb

[bachase]

As an input for #235 , in addition to custom observables, will we need custom noise models (different from depolarizing model) that are related to that circuit? #222 suggests the noise value will at least be.

[jordandsullivan]

We may need different noise models for different benchmarks, yes. Indeed as you say, at very least, circuits with a much greater depth will likely need a lower error rate (even if it's still, e.g. depolarizing noise).

I think another useful feature would be to give people the option to select their preferred noise model and scale it up or down in simulation. Using particular quantum device emulators may also be a fruitful avenue here, esp as we intend UCC to to support more quantum hardware-level compilation passes, including error mitigation, which definitely needs different error models to show benefit for different techniques.

[Misty-W]

Created #252 to capture the scope completed in 0.4.3.

Moving this issue and remaining scope to next milestone.