Executing a quantum circuit in simulation

Now, click the Simulate button. Give your experiment the name "10000". The default simulation parameters, editable next to the Simulate button, specify that the circuit will be run 100 times. Remember that in quantum computing, each time we prepare an input and run an identical circuit, we may get different results as, for measurements, there is a certain probability of 1 and a certain probability of 0. Therefore, any one run might not tell us much about the probability of the output. Luckily, either in simulation or on the real quantum computer hardware, we can choose to reset, set up the qubits again, and run the same circuit on those qubits. With enough runs, we will be able to infer the probability of each output in the first place. This should be easy in our case with this circuit, as we expect that the qubits labeled q[1]q[2], q[3], and q[4] should be 0 after measurement with 100% probability, and the qubit labeled q[0] should be 1 after measurement with 100% probability. 

Depending on whether resources are currently available, a window might pop up that the execution is pending. In that case, you can check on the execution under the Quantum Scores section. You may need to click Refresh and expand your circuit "10000" to see whether your execution is planned or ready. Here you can see on the right that I have two past completed execution and one execution pending:

When the results are ready, a large window will pop up:

Note that, although it's a bit confusing the results are listed in the opposite order with the qubit labeled q[0] appearing last, and the qubit labeled q[4] first, so the 10000 that we expect is written as 00001:

I will underline the bits when I discuss reading the measurement output from the IBM interface to emphasize that we must remember they are in the opposite order from q[0], q[1], q[2], q[3], and q[4] and, instead, go from the highest numbered qubit to the lowest. It is unfortunate that IBM chose this convention, as it easily leads to confusion. 

The number on top is the fraction of the total number of runs, in this case 100, which returned the bits on the bottom, for example, 100/100 or 1.000 fraction of runs, that is, 100% of runs returned 00001. This is exactly as we expect.