Ensure calibration workflow can run with any supported `QPROGRAM`

[natestemen]

As it stands, the calibration workflow only works with Cirq. This is likely due to two reasons:

1. When generating test circuits in the Settings.make_problems function, we use the default circuit type which is Cirq with the underlying assumption that the executor can run Cirq.
2. In the Calibrator.run method, we append measurements using the Cirq interface.

Two solutions come to mind:

1. Track what frontend the user is using. Either by looking at typehints (personally, I do not like this approach), or by asking the user to pass a string specifying (also don't love this, but it might be the most simple). This method seems like it would fix point 1 above quite well, but I'm not sure how it would fix point 2 as after a cursory search we don't seem to have any sort of QPROGRAM agnostic measure_all function, which could be part of this solution.
2. Convert the users executor to accept any QPROGRAM type using our accept_any_qprogram_as_input function.

This would be great to try and get done this (march) milestone, so we can make a launch of calibration without the asterisk that not all frontends are supported yet.

cc @andreamari @nathanshammah since y'all unearthed this problem. Which, by the way, thank you!

[andreamari]

Hi @natestemen, Solution 2 would not work since accept_any_qprogram_as_input converts any input to a Cirq circuit and always expects a Cirq executor. We want the opposite: given a Cirq circuit we need to convert to "any" executor.

Unfortunately I think there is no clean way of guessing the frontend of the user unless they pass a string specifying it somewhere. Maybe it could be passed when initializing the Calibrator or when initializing Settings?

I know you are ooo. We can sync on this when you are back.

[natestemen]

I like what you've done in #1748. The other idea I had (which we do not have to go with, just want to put it down here so we can evaluate) is to have a helper function that would look something like this

def convert_to_cirq_executor(executor: Callable[[QPROGRAM], float], frontend: str) -> Callable[[cirq.Circuit], float]:
    def new_executor(circuit: cirq.Circuit) -> float:
        circuit = convert_from_mitiq(circuit, frontend)
        return executor(circuit)

    return new_executor

cc @Misty-W since you paired with Andrea on #1748.

[andreamari]

The convert_to_cirq_executor is also a valid solution which could also be implemented as a self.cirq_executor property of Calibrator objects.
If you think it's better than https://github.com/unitaryfund/mitiq/pull/1748, I can update https://github.com/unitaryfund/mitiq/pull/1748 accordingly.

No strong preferences from my side.

[natestemen]

No strong preference here either. @Misty-W WDYT?

[Misty-W]

Slightly prefer the self.cirq_executor because

1. It avoids the slight awkwardness/inconvenience of having the user specify the frontend and the question of where to put the frontend_type argument.
2. It's consistent with keeping the Mitiq internals as Cirq.

[natestemen]

the slight awkwardness/inconvenience of having the user specify the frontend

I agree, I don't love this aspect either, but I'm not sure the cirq_executor would alleviate this problem as we still need the frontend argument in convert_to_cirq_executor. It would be great if we could inspect a function of type QPROGRAM -> QuantumResult, and know which subtype of QPROGRAM it accepts, but I don't think we can do this without it being tedious, and extremely involved.

I might be missing something here, however.

[Misty-W]

That's right, I missed that! Seeing only what I wanted to see, ha! Forget point # 1, but I think point # 2 is still something to consider.

[Misty-W]

You'd think the frontends would check if the quantum program was compatible- then we could use their logic. I guess oftentimes the error messages are more like "such and such operation doesn't exist".