Allow different spins to have different lengths

[fretchen]

Suppose the following circuit:

qc = QuantumCircuit(2)
qc.lx(np.pi, [0])

qc.append(LxLyGate(gamma=np.pi), [0, 1])
qc.measure_all()
counts = backend.run(qc, spin=1/2).result().get_counts()

To implement a number of mixture experiments it would be necessary to set the length of each individual spin, which would modify the last line too:

qc = QuantumCircuit(2)
qc.lx(np.pi, [0])

qc.append(LxLyGate(gamma=np.pi), [0, 1])
qc.measure_all()
counts = backend.run(qc, spin=[5, 1/2]).result().get_counts()

No idea which part of the code has to be changed for that and if it is even possible right now. An approach that would be actually nicely compatible with the terminology of the fermions and experimental sequences would be the definition of load gates.

qc = QuantumCircuit(2)
qc.load(4,0)
qc.load(1,1)
qc.lx(np.pi, [0])

qc.append(LxLyGate(gamma=np.pi), [0, 1])
qc.measure_all()
counts = backend.run(qc).result().get_counts()

[eggerdj]

This does not seem so trivial. This would most likely require extending the SpinOp in Qiskit nature to accept spins with different lengths. Looking at SpinOp in Qiskit nature we have

    def __init__(
        self,
        data: Union[
            str,
            List[Tuple[str, complex]],
            Tuple[np.ndarray, np.ndarray],
        ],
        spin: Union[float, Fraction] = Fraction(1, 2),
        register_length: Optional[int] = None,
    ):

https://github.com/Qiskit/qiskit-nature/blob/42dfada1562464e2498660a6a67fa8bc0060d4fc/qiskit_nature/operators/second_quantization/spin_op.py#L170-L179 This means that all spins in the SpinOp have the same length, e.g. SpinOp([("XZX", 1.0)], spin=5/2) has three spins all with the same length. Alternatively, we could think of some fancy foot work in spin_circuit_solver to overcome this limitation but it seems cleaner to do this in Qiskit Nature.

[eggerdj]

FYI https://github.com/Qiskit/qiskit-nature/issues/383

[fretchen]

Agreed. As long as the issue remains in qiskit-nature it is likely a good approach to 'simply' implement this an indivdual provider back-end as it starts to be on the more specialized use-case.

[LaurinFischer]

Yes, Daniel is right that this limitation from the SpinOp is what prompted us to set this constant for now. We could build the necessary matrices within the SpinCircuitSolver ourselves if this turns out to be a difficult extension for the base SpinOp from qiskit nature.