Circuit based protocols run only on simulation

[andrea-pasquale]

Whenever we run a protocol containing circuit execution, it seems that the platform is ignored and the execution is launched on the default global backend which is most likely going to be numpy. I remembered that we already dealt with this issue in the past #941. I don't know why this is happening again, perhaps it could be due to some recent changes in Qibo. I need to investigate more.
To reproduce the issue it is sufficient to run any protocol involving circuits on the dummy platform.
Thanks @jykhoo1987 for spotting this issue.

[alecandido]

Isn't it related to the discussion in #1063?

I guess the backend is being instantiated in a way that ignores the specified platform (possibly using the global one, through get_backend() at this point).

I didn't inspect it directly, but if needed, I can take a look.

[andrea-pasquale]

Indeed, you are correct. At this point we can just move the discussion here if you agree.

[andrea-pasquale]

The problem is related to the fact that it is not trivial to get the backend from the platform (we need to do that since in qibocal the acquisition functions accept only the platform). This is why we tried to patch the code with #941 or #1063.
A way to get the backend from the platform could be to use available_platforms from qibolab.

We could do something like this:

if platform.name in available_platforms() + ["dummy"]:
    backend = construct_backend(backend="qibolab" , platform=platform)
else:
    backend = get_backend()

directly in the functions which are transpiling/executing circuits in qibolab.
This solution should work for both 0.1 and 0.2 for any protocol, although in 0.2 the available_platforms function is not directly part of the API I don't think that it will be changed anytime soon and in my opinion should be part of the public API.
Thoughts @alecandido @stavros11 @Edoardo-Pedicillo?

[stavros11]

This solution looks okay to me. We could also make available_platforms public in qibolab 0.2, as this is not a breaking change. We would just lose compatibility with current 0.2 releases if we use it in qibocal. Note that it is also possible to obtain the same information now in a slightly more convoluted way:

from qibolab import MetaBackend

MetaBackend().list_available()

Another general comment regarding this issue is that we are potentially not getting when running on TII-QRC chips because the slurm prologue is setting the $QIBO_PLATFORM environment variable which set the GlobalBackend to qibolab with the corresponding platform.

In general, if you also agree, I would like to move towards not using the GlobalBackend in qibocal at all and instead rely on local instantiations of backend and using backend.execute_circuit(circuit, nshots) directly (expert mode), instead of circuit(nshots). The reason being that GlobalBackend is "global" which comes various issues, such as the current one (being hard to trace exactly what it is).

[andrea-pasquale]

In general, if you also agree, I would like to move towards not using the GlobalBackend in qibocal at all and instead rely on local instantiations of backend and using backend.execute_circuit(circuit, nshots) directly (expert mode), instead of circuit(nshots). The reason being that GlobalBackend is "global" which comes various issues, such as the current one (being hard to trace exactly what it is).

I agree, for sure relying on a local backend is the proper solution. It would just be a bit repetitive to do it since we will need to change the acquisition function for all protocols in qibocal. I've also other refactors in mind so sooner or later we will need to modify the protocol structure. As already discussed I would postpone this type of refactors after merging the 0.2 branch.

If everybody agrees I can open a PR with the fix involving available platforms (for main and eventually 0.2) if the fix is required urgently.

[alecandido]

In general, if you also agree, I would like to move towards not using the GlobalBackend in qibocal at all and instead rely on local instantiations of backend and using backend.execute_circuit(circuit, nshots) directly (expert mode), instead of circuit(nshots). The reason being that GlobalBackend is "global" which comes various issues, such as the current one (being hard to trace exactly what it is).

Yes, I perfectly agree on this.

Even more in general, it would be great to drop the GlobalBackend at all from Qibo, since globals are causing more harm than good.
I'm not proposing it, because we're keeping it to simplify end users' adoption, since it's rather customary to use platforms in these ways in some contexts.
However, if it's acceptable for end users, it should never be used inside our packages.

We could do something like this:
[...]
This solution should work for both 0.1 and 0.2 for any protocol, although in 0.2 the available_platforms function is not directly part of the API I don't think that it will be changed anytime soon and in my opinion should be part of the public API.

Instead of relying on the available_platforms() function, it should be possible to just attempt QibolabBackend instantiation, and then catch an error (which in turn should do the same thing, but keeping the Qibolab interface smaller).
Or go through the MetaBackend, as suggested by @stavros11.

Eventually, I would like to take some time and refactor part of the internal structure of Qibocal, and how the information is passed around. I'm postponing this since this summer (after the Output refactor), but it's not yet the best time to do that, even because there is the Qibolab 0.2 adoption still ongoing, which is better decoupled.

[andrea-pasquale]

At this point I would just go through MetaBackend as suggested by @stavros11.