Mag-migrate mula sa BackendV1 patungong BackendV2
Ang Qiskit BackendV1 class ay na-deprecate na at aalisin sa serbisyo. Inilalarawan ng migration guide na ito ang maliliit na pagbabagong kailangan mong gawin kung gumagamit ka ng provider na nag-upgrade mula sa BackendV1 patungong BackendV2.
Kung eksklusibo kang gumagamit ng qiskit_ibm_runtime at qiskit_aer, walang kailangang gawin. Ang qiskit_ibm_runtime package ay palaging gumagamit ng BackendV2, at ang qiskit_aer ay gumagamit ng BackendV2 simula pa sa bersyon 0.13.
Mga pangunahing pagbabago sa BackendV2​
Ang Qiskit Backend model ay idinisenyo para bigyan ang Qiskit SDK ng
abstraction layer na nagbibigay-daan sa pag-reason tungkol sa mga quantum computer sa loob ng saklaw ng SDK. Ang unang iterasyon ng
modelo ay ipinakilala gamit ang BackendV1 class. Inimbak ng class na ito ang impormasyon ng backend sa isang serye ng
mga data container, partikular ang BackendConfiguration at
BackendProperties classes.
Binago ng BackendV2 class ang
paraan ng pag-access ng user sa karamihan ng backend properties para gumana ang mga ito kasama ang native na Qiskit data structures at magkaroon ng
mas simpleng access patterns. Ang pangunahing bahagi ng BackendV2 model ay ang
Target class, isang representasyon ng QPU na naglalaman ng mga transpilation constraints na magagamit ng Qiskit para i-optimize ang mga Circuit para sa execution.
Na-update na ang Qiskit SDK para eksklusibong gumana kasama ang mga BackendV2 input,
at karamihan sa mga provider ay nag-upgrade na mula sa BackendV1 patungong BackendV2. Inaasahan na ang mga kasalukuyang provider ay mag-deprecate ng lumang access kung posible para sa maayos na migration, ngunit sa huli kailangang i-adjust ng mga user ang kanilang code.
Ang prinsipyo ng BackendV2 ay
ang karamihan ng impormasyon tungkol sa isang backend ay nasa loob ng
Target object nito, at ang mga attribute ng backend ay madalas na nagtatanong sa
BackendV2.target attribute para magbalik ng impormasyon. Gayunpaman, sa maraming kaso ang mga attribute ay
nagbibigay lamang ng subset ng impormasyong maaaring nakapaloob sa Target. Halimbawa, ang backend.coupling_map
ay nagbabalik ng CouplingMap object na itinayo mula sa
Target na accessible sa
BackendV2.target attribute. Gayunpaman, ang Target ay maaaring
maglaman ng mga instruction na gumagana sa higit sa dalawang Qubit (na hindi maaaring i-represent sa
CouplingMap) o maaaring may mga instruction na gumagana lamang sa
isang subset ng mga Qubit (o dalawang Qubit link, para sa dalawang Qubit na instruction), na hindi
makikita sa buong coupling map na ibinalik ng
BackendV2.coupling_map. Kaya depende sa iyong use case,
maaaring kailangan mong tumingin nang mas malalim kaysa sa katumbas na access gamit ang
BackendV2.
Mga partikular na pagbabago sa BackendV2​
Karamihan sa mga attribute ay may direktang kapalit, na pinapasimple ang migration. Ang tanging punto ng hindi pagkakatugma sa pagitan ng mga interface ay nasa CouplingMap.
Nasa ibaba ang isang talahanayan ng mga halimbawa ng access pattern sa BackendV1 at ang bagong form
gamit ang BackendV2.
I-scroll pakanan para makita ang mahahalagang tala.
BackendV1 | BackendV2 | Mga Tala |
|---|---|---|
backend.configuration().n_qubits | backend.num_qubits | |
backend.configuration().coupling_map | backend.coupling_map | Ang ibinalik mula sa BackendV2 ay isang CouplingMap object. Sa BackendV1 ito ay isang edge list. Gayundin, ito ay isang view lamang ng impormasyon na nasa backend.target na maaaring subset lamang ng impormasyon sa Target object. |
backend.configuration().backend_name | backend.name | |
backend.configuration().backend_version | backend.backend_version | Ang BackendV2.version attribute ay kumakatawan sa bersyon ng abstract na Backend interface na ipinapatupad ng object, habang ang BackendV2.backend_version ay metadata tungkol sa bersyon ng backend mismo. |
backend.configuration().basis_gates | backend.operation_names | Ang BackendV2 ay nagbabalik ng listahan ng mga operation name na nasa backend.target attribute. Ang Target ay maaaring maglaman ng higit pang impormasyon kaysa sa maipapahayag ng listahang ito. Halimbawa, ang ilang operation ay gumagana lamang sa isang subset ng mga Qubit, at ang ilang pangalan ay nagpapatupad ng parehong Gate na may iba't ibang parameter. |
backend.configuration().dt | backend.dt | |
backend.configuration().dtm | backend.dtm | |
backend.configuration().max_experiments | backend.max_circuits | |
backend.configuration().online_date | backend.online_date | |
InstructionDurations.from_backend(backend) | backend.instruction_durations | |
backend.defaults().instruction_schedule_map | backend.instruction_schedule_map | |
backend.properties().t1(0) | backend.qubit_properties(0).t1 | |
backend.properties().t2(0) | backend.qubit_properties(0).t2 | |
backend.properties().frequency(0) | backend.qubit_properties(0).frequency | |
backend.properties().readout_error(0) | backend.target["measure"][(0,)].error | Sa BackendV2, ang error rate para sa Measure operation sa isang partikular na Qubit ang ginagamit para i-model ang readout error. Gayunpaman, ang isang BackendV2 object ay maaaring mag-implement ng maraming uri ng measurement at ilista ang mga ito nang hiwalay sa isang Target. |
backend.properties().readout_length(0) | backend.target["measure"][(0,)].duration | Sa BackendV2, ang duration para sa Measure operation sa isang partikular na Qubit ang ginagamit para i-model ang readout length. Gayunpaman, ang isang BackendV2 object ay maaaring mag-implement ng maraming uri ng measurement at ilista ang mga ito nang hiwalay sa isang Target. |