Open bmhowe23 opened 7 months ago
To illustrate this. The OQC SDK or the
from client.qcaas_client.client import OQCClient, QPUTask
# email =
# password =
def get_two_qubit_coupling(email: str, password: str) -> list:
client = OQCClient(url='https://int.cloud.oqc.app/qpu',
email=email,
password=password)
qpu_id = "qpu:uk:3:9829a5504g"
calibration = client.get_calibration(qpu_id)
# fetched from https://int.uk.cloud.oqc.app/9829a5504g/monitoring/calibrations
return list(calibration['two_qubit'].keys())
get_two_qubit_coupling(email, password)
Return
['1-2', '10-1', '10-11', '12-13', '14-13', '14-15', '15-8', '16-17', '18-14', '19-11', '2-3', '20-19', '24-23', '24-27', '26-35', '27-34', '29-20', '29-30', '30-31', '31-30', '32-31', '33-32', '34-33', '34-35', '4-3', '4-5', '6-5', '7-16', '7-6', '8-5', '9-12', '9-2']
Shows unique couplings between different coupling similar to the static definitions here note the 1-based indexing in the above as opposed to the better zero based indexing in the cudaq routing file.
Since this is authentication protected here's a portion of the returned JSON to work against which could be included from this fake server utility as a new response
{'1-2': {'coupling': {'control_qubit': 1, 'target_qubit': 2}, 'fCX': 0.0}, '10-1': {'coupling': {'control_qubit': 10, 'target_qubit': 1}, 'fCX': 0.9999977226364618}, '10-11': {'coupling': {'control_qubit': 10, 'target_qubit': 11}, 'fCX': 0.999999}, '12-13': {'coupling': {'control_qubit': 12, 'target_qubit': 13}, 'fCX': 0.999999}, '14-13': {'coupling': {'control_qubit': 14, 'target_qubit': 13}, 'fCX': 0.999999}, '14-15': {'coupling': {'control_qubit': 14, 'target_qubit': 15}, 'fCX': 0.999999}, '15-8': {'coupling': {'control_qubit': 15, 'target_qubit': 8}, 'fCX': 0.999999}, '16-17': {'coupling': {'control_qubit': 16, 'target_qubit': 17}, 'fCX': 0.999999}, '18-14': {'coupling': {'control_qubit': 18, 'target_qubit': 14}, 'fCX': 0.999999}, '19-11': {'coupling': {'control_qubit': 19, 'target_qubit': 11}, 'fCX': 0.999999}, '2-3': {'coupling': {'control_qubit': 2, 'target_qubit': 3}, 'fCX': 0.999999}, '20-19': {'coupling': {'control_qubit': 20, 'target_qubit': 19}, 'fCX': 0.999999}, '24-23': {'coupling': {'control_qubit': 24, 'target_qubit': 23}, 'fCX': 0.999999}, '24-27': {'coupling': {'control_qubit': 24, 'target_qubit': 27}, 'fCX': 0.999999}, '26-35': {'coupling': {'control_qubit': 26, 'target_qubit': 35}, 'fCX': 0.999999}, '27-34': {'coupling': {'control_qubit': 27, 'target_qubit': 34}, 'fCX': 0}, '29-20': {'coupling': {'control_qubit': 29, 'target_qubit': 20}, 'fCX': 0.999999}, '29-30': {'coupling': {'control_qubit': 29, 'target_qubit': 30}, 'fCX': 0.0}, '30-31': {'coupling': {'control_qubit': 30, 'target_qubit': 31}, 'fCX': None}, '31-30': {'coupling': {'control_qubit': 31, 'target_qubit': 30}, 'fCX': 0.999999}, '32-31': {'coupling': {'control_qubit': 32, 'target_qubit': 31}, 'fCX': 0.999999}, '33-32': {'coupling': {'control_qubit': 33, 'target_qubit': 32}, 'fCX': None}, '34-33': {'coupling': {'control_qubit': 34, 'target_qubit': 33}, 'fCX': None}, '34-35': {'coupling': {'control_qubit': 34, 'target_qubit': 35}, 'fCX': 0.999999}, '4-3': {'coupling': {'control_qubit': 4, 'target_qubit': 3}, 'fCX': 0.6733723548983703}, '4-5': {'coupling': {'control_qubit': 4, 'target_qubit': 5}, 'fCX': 0.250}, '6-5': {'coupling': {'control_qubit': 6, 'target_qubit': 5}, 'fCX': None}, '7-16': {'coupling': {'control_qubit': 7, 'target_qubit': 16}, 'fCX': 0.999999}, '7-6': {'coupling': {'control_qubit': 7, 'target_qubit': 6}, 'fCX': 0.999999}, '8-5': {'coupling': {'control_qubit': 8, 'target_qubit': 5}, 'fCX': 0.999999}, '9-12': {'coupling': {'control_qubit': 9, 'target_qubit': 12}, 'fCX': None}, '9-2': {'coupling': {'control_qubit': 9, 'target_qubit': 2}, 'fCX': 0.0}}
What about using fCX to disconnect where we may have sporadic low fidelities (None, 0 or < some threshold)?
From the IQM side — we've recently added the possibility to specify gates per pair/qubit and in the near future we plan to make the would architecture endpoint /quantum-architecture calibration-aware.
Another comment from IQM side — in addition to what @kukushechkin said above, we also plan, in near future, to incorporate fidelity data into quantum architecture, explicitly list gate implementations, and separate QPU topology data from "gates". So, overall, it should be possible to fetch:
It may look something like this: /calibration/<UUID>/gates
would return:
"gates": {
"prx": {
"implementations": {
"drag_gaussian": {
"priority": 0,
"loci": [["QB1"], ["QB2"], ["QB3"], ["QB4"], ["QB5"], ["QB6"]]
},
"tgss_crf": {
"priority": 1,
"loci": [["QB1"], ["QB2"], ["QB3"], ["QB4"], ["QB5"], ["QB6"]]
},
...
}
},
...
}
and /calibration/<UUID>/metrics
would return:
"metrics": {
...
"QB9-QB10.cz_gate_fidelity": {
"value": "0.9784502054220903",
"uncertainty": "0.0024997208080908347",
"timestamp": "2024-04-29T14:50:28.381109"
},
...
}
Just for clarification, this item is still available for anybody to grab and implement for UnityHack.
Required prerequisites
Describe the feature
CUDA-Q currently supports specification of QPU mapping topologies via static configuration files in
It would be nicer if these topologies could be dynamically fetched from their corresponding host services, either via a standalone command-line tool and/or a library call that could be integrated into the runtime. (The most ideal solution is a common implementation that supports both options.)