check if default two qubit gate is supported by the device

[cqc-melf]

Description

Solve #457

Checklist

• I have performed a self-review of my code.
• I have commented hard-to-understand parts of my code.
• I have made corresponding changes to the public API documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have updated the changelog with any user-facing changes.

[yao-cqc]

Can we instead check this in the QuantinuumBackend constructor and use the same error message in set_compilation_config_target_2qb_gate?

[cqc-melf]

set_compilation_config_target_2qb_gate

set_compilation_config_target_2qb_gate already has a check, so I think that should be fine?

Unfortunately I can't use _gate_set in the constructor because that calls the API and breaks quiet a few things for backends constructed with the offlineapi.

Happy to find a workaround for that if you think that is important.

[cqc-alec]

It does feel wrong to set this config value inside rebase_pass(). Can we change the _default_2q_gate() function instead?

[cqc-alec]

By the way, deadhead and brathead both now accept the ZZPhase gate. So maybe we don't need this anymore, as ZZPhase is available on all devices?

[yao-cqc]

set_compilation_config_target_2qb_gate

set_compilation_config_target_2qb_gate already has a check, so I think that should be fine?

Unfortunately I can't use _gate_set in the constructor because that calls the API and breaks quiet a few things for backends constructed with the offlineapi.

Happy to find a workaround for that if you think that is important.

I think self._gate_set won't make any API call if the backend is constructed with the offline API. Maybe I misunderstood the problem?

[cqc-melf]

By the way, deadhead and brathead both now accept the ZZPhase gate. So maybe we don't need this anymore, as ZZPhase is available on all devices?

I think we discussed this in the last sprint planing that we still want to have this check additionally to make this future proof.

If you think this is not required, then we can close this.

[cqc-melf]

set_compilation_config_target_2qb_gate

set_compilation_config_target_2qb_gate already has a check, so I think that should be fine?
Unfortunately I can't use _gate_set in the constructor because that calls the API and breaks quiet a few things for backends constructed with the offlineapi.
Happy to find a workaround for that if you think that is important.

I think self._gate_set won't make any API call if the backend is constructed with the offline API. Maybe I misunderstood the problem?

I think I was wrong with the problem detection, the actual issue is that we have tests are not expected to make API calls that would make this calls with the changes in the constructor.

I have now gone the way and updated all the affected testcases.

[cqc-melf]

The failed tests on QA are timeouts, so should be fine to merge without them.

[cqc-alec]

I'm just a little worried that requiring login when constructing QuantinuumBackend may break some workflows; perhaps we should check this with nexus?

[cqc-melf]

I'm just a little worried that requiring login when constructing QuantinuumBackend may break some workflows; perhaps we should check this with nexus?

I checked with them, this is not a concern.

[cqc-melf]

I will take a look at the failed notebook and update that. Will ask for a review after that is updated.

[cqc-alec]

I will take a look at the failed notebook and update that. Will ask for a review after that is updated.

This is probably #474 . If so it needs an update from the US side.

[cqc-melf]

I will take a look at the failed notebook and update that. Will ask for a review after that is updated.

This is probably #474 . If so it needs an update from the US side.

Yes, looks like it.

Made one push for testing, can you approve this gain? @cqc-alec

[cqc-alec]

If we want to change the default we should change it here too, but I'm not sure if we want to do this.