Closed Astlaan closed 5 years ago
I was also wondering why, in the circuit plot, the waiting times are as they are:
So, from what I understood, any circuit starts running at 10ns in this setup? However, why is there a 30ns delay between the Ry and the CZ gates, given that Ry only takes 20ns? Why is the waiting gate just 30ns in the 2nd wire after the CZ, given that this gate takes 40ns? After the 2nd Ry gate on the 2nd wire, there is also only 10ns of delay, when this gate takes 20ns?
Or is the above all okay because we're applying the instantaneous gates in the middle of their duration window?
Hi Astlaan,
Setup issue is fixed now - sorry about that. A while ago we shifted to setup not being a dictionary and forgot to update the tutorial.
The waiting times are indeed because the gates are applied in the middle of the window, and we unfortunately don't make it clear that the 30ns waiting time between the rotation and the cphase gate is 10ns from the rotation and 20ns from the cphase. This will hopefully be fixed in the new quantumsim release.
Thank you. Which setup should I load if I want to simulate the circuits without errors of any sort? To simulate the ideal output?
Also, this question is not completely related, but: Is an overall gate fidelity calculated for the DiCarlo Setup? Similar to what is avaialable in IBM Q Experience:
So when you call setup, you can set 'noise_flag=False' and get circuits without errors. You can also set T1 and T2. The 'gate error' is a bit more difficult because this is not well-defined, but you could set both the dephasing axis, and dephasing in the plane to the number here and I think this will be a quasi-reasonable model (read the docs of the DiCarlo model for more information)
The Introduction.ipynb does not work.
In the 3rd and 4th input, the variable
setup
is considered to be a dictionary.However,
setup = DiCarlo_setup.quick_setup(qubit_list)
And in the
DiCarlo_setup.quick_setup
implementation we can see that it returns aSetup
class, instead of a dictionary.Replacing
return Setup(**setup)
byreturn setup
appears to work, but I'm not sure if this ends up missing something...