dqc_simulator.software.compilers
Distributed quantum computing compilers.
These compilers take a list of gate tuples, and output a time-sliced dictionary of what happens on each individual QPU.
Notes
Some compilation is also done in dqc_control.py. There common subroutines used by Cat-comm and TP-comm are broken down into individual gates and run on individual nodes. The role of these compilers is to break a monolithic quantum circuit into the lower level commands used in :mod: ~dqc_simulator.software.dqc_control. That said, very general compilers can be defined here. The main limitations are that they use only intraprocessor quantum gates and the interprocessor subroutines involved in Cat and TP-comm (at least for now) and that the backend defined in :mod: ~dqc_simulator.software.dqc_control may not be able to cope with carrying out multiple inter-QPU gates on a given node within the same time-slice. Each time slice is intended to be greedily compiled and executed by functions in :mod: ~dqc_simulator.software.dqc_control but near-arbitrary compilation can be done by careful choice of the time slices.
- class dqc_simulator.software.compilers.QpuOps
Bases:
objectData structure for tracking the operations of all QPUs within a DQC.
Intended to help users develop their own compilers.
Notes
The definitions of cat-comm and TP-comm subroutines work less well for many QPU systems (rather than 2 QPU systems) and so this is best used for compiling 2-QPU systems
- check_if_all_nodes_have_empty_trailing_time_slice()
- Returns
all_nodes_have_empty_trailing_time_slice – True if all nodes have an empty trailing time slice and false otherwise.
- Return type
- one_tp(gate_instructions, qubit_index0, node0_name, node1_name)
Add gate tuples for 1tp remote gate, in which a processing qubit is teleported to an automatically assigned comm-qubit in another QPU and then the gate or gates are done locally by the QPU.
No teleportation is done back to the original QPU to free up the comm-qubit used.
- remove_empty_trailing_time_slices()
Remove empty trailing time slices if they appear for all QPUs.
The constant number of time slices for all nodes is retained.
- teleport_only(gate_instructions, proc_qubit2teleport_from, comm_qubit2teleport_to, node0_name, node1_name)
Add gate tuples for a teleportation.
No subsequent gate is done automatically.
- Parameters
gate_instructions (empty list) – Must be empty list, and is included only for input checking
proc_qubit2teleport_from (int) – The index of the processing qubit to teleport from (the control qubit in the remote gate).
comm_qubit2teleport_to (int) – The index of the comm-qubit to be teleported to.
node0_name (str) – The name of the QPU node to be teleported from.
node1_name (str) – The name of the QPU node to be teleported to.
todo:: (..) – Deprecate the type check here, by changing the way gate tuples with four or more elements are interpreted. Length alone is not a stable interpretation method.
- tp_safe(gate_instructions, qubit_index0, qubit_index1, node0_name, node1_name)
Specifying gate tuples needed to implement remote gate using 1tp, then teleports back to original qubit on the QPU to free up comm-qubits.
In the ideal case, the qubits would be left in the state they would have been had it been possible to do a local gate between them (ie, all quantum information is stored in processing qubits).
- dqc_simulator.software.compilers.find_consecutive_gate(partitioned_gates, gate, gate_position)
Finds the next gate which has shared qubits with the specified gate.
Otherwise, the next gate in partitioned gates may be completely unrelated to the gate of interest with no need to maintain their ordering. They may even occur on completely different nodes or pairs of nodes.
- dqc_simulator.software.compilers.find_consecutive_remote_gates(partitioned_gates, filtered_remote_gates)
Finds the consecutive gates in a filtered set of remote gates (eg, those in the same qubit-node or node-node pair)
- Parameters
partitioned_gates (list of tuples) – All gates in quantum circuit (partitioned into different nodes)
filtered_remote_gates (list of tuples of form) – (gate, postional index of gate within partitioned gates) The filtered list of remote gates and their positional indices wrt the overall list of partitioned gates.
- Returns
burst_comm_blocks – The identified burst communication blocks as found in the first step of the autocomm communication aggregation process (identifying blocks) without circuit restructuring.
- Return type
list of lists
- dqc_simulator.software.compilers.find_pairs(partitioned_gates, pair_type)
- Parameters
partitioned_gates (list of tuples) – List of tuples with gate information including type of gate, qubit indices acted on, node names acted on, and (for remote gates) a string indicating the scheme (here this should be some placeholder string as the scheme is not yet decided).
pair_type (str) – Whether to return ‘qubit_node’ or ‘node_node’ pairs.
- Returns
pairs – The remote gates for each qubit-node or node-node pair
- Return type
- dqc_simulator.software.compilers.find_qubit_node_pairs(partitioned_gates)
- Parameters
partitioned_gates (list of tuples) – List of tuples with gate information including type of gate, qubit indices acted on, node names acted on, and (for remote gates) a string indicating the scheme (here this should be some placeholder string as the scheme is not yet decided).
- Returns
qubit_node_pairs – All of the gates associated with a qubit-node pair. Qubit-node pairs are referred to by a key of the form (qubit0_index, node0_name, node1_name), where the first two entries define the qubit and the latter the node. The remote gates for each qubit-node pair are lists of the form [gate, ID] where gate is the gate tuple form partitioned gates and ID
- Return type
- dqc_simulator.software.compilers.get_qubit_id(gate)
Collecting info needed to uniquely ID the qubits of a gate within a partitioned circuit
- Parameters
gate (TYPE) – DESCRIPTION.
- Returns
qubit0 (TYPE) – DESCRIPTION.
qubit1 (TYPE) – DESCRIPTION.
- dqc_simulator.software.compilers.order_pairs(pairs)
Sorts dict of the remote gates associated with different qubit-node or node-node pairs in descending order
- dqc_simulator.software.compilers.sort_greedily_by_node_and_time(partitioned_gates, new_time_slice4each_remote_gate=False)
Distributes the circuit between nodes and splits into explicit time-slices (rows in output array). Initialisation of qubits must be specified as an instruction in the partitioned_gates input.
- Parameters
partitioned_gates (list of tuples) –
The gates in the entire circuit. The tuples should be of the form: 1) single-qubit gate: (gate_instr, qubit, node_name) 2) two-qubit gate: (list of instructions or gate_instruction or
instruction_tuple if local, qubit0, node0_name, qubit1, node1_name, scheme if remote) #can later extend this to multi-qubit gates #keeping scheme as last element list of instructions: list
list of same form as partitioned_gates containing the local gates to be conducted as part of the remote gate. Ie, for remote-cnot this would contain the cnot (but not the gates used for
bsm or correction).Note if this is given as
empty list and scheme = “1tp” then it will just do a teleportation
- gate_instruction
Instruction The gate instruction for the target gate
- instruction_tupletuple
Tuple of form (gate_instruction, op), where op is the operatution used to perform the gate. This form is useful if you want to give several gates the same netsquid.components.qprocessor.PhysicalInstruction
- qubit{ii}: int
The qubit index
node_name: str The name of the relevant node scheme: str, optional
Only needed for remote gates
- gate_instruction
new_time_slice4each_remote_gate (bool, optional) – Whether to create a new time slice for all QPUs for every remote gates. This is a simplistic way of avoiding scheduling conflicts when more than 2 QPUs are used. The drawback is that the latency will be higher.
Notes
The scheduling here works less well for more than two QPUs and may lead to errors.
- Returns
Dictionary with term for each node which is an list of different time slices (each time slice is a list within the list)
- Return type
- dqc_simulator.software.compilers.sort_many_qpus_greedily_by_node_and_time(partitioned_gates)
Distributes the circuit between QPU nodes and splits into explicit time-slices (rows in output array). Initialisation of qubits must be specified as an instruction in the partitioned_gates input. Unlike sort_greedily_by_node_and_time with the default settings, this compiler is designed to avoid scheduling conflicts when more than 2 QPUs are used. The drawback is that the latency will be higher because a new time slice is created every time a remote gate occurs.
- Parameters
partitioned_gates (list of tuples) –
The gates in the entire circuit. The tuples should be of the form: 1) single-qubit gate: (gate_instr, qubit, node_name) 2) two-qubit gate: (list of instructions or gate_instruction or
instruction_tuple if local, qubit0, node0_name, qubit1, node1_name, scheme if remote) #can later extend this to multi-qubit gates #keeping scheme as last element list of instructions: list
list of same form as partitioned_gates containing the local gates to be conducted as part of the remote gate. Ie, for remote-cnot this would contain the cnot (but not the gates used for
bsm or correction).Note if this is given as
empty list and scheme = “tp” then it will just do a teleportation
- gate_instruction
Instruction The gate instruction for the target gate
- instruction_tupletuple
Tuple of form (gate_instruction, op), where op is the operatution used to perform the gate. This form is useful if you want to give several gates the same netsquid.components.qprocessor.PhysicalInstruction
- qubit{ii}: int
The qubit index
node_name: str The name of the relevant node scheme: str, optional
Only needed for remote gates
- gate_instruction
- Returns
Dictionary with term for each node which is an list of different time slices (each time slice is a list within the list)
- Return type