Bugfix IBMQ Retrieve Results

[pcwysoc]

Hopefully fixes an issue where the code could not handle more bits returned from IBM than the number of qubits in the experiment. This is the case in my default workflow. I ended up reverting to older code that I had locally. This older code also handles MCMs, which I do not believe current code does. @ndsieki I would be very interested in your thoughts on this, as you've been maintaining the IBMQ code recently and may be using a different workflow.

We should also investigate why retrieving results is so slow. It takes several hours to load larger batches of jobs from IBM. My current guess is that it is due to a checkpoint being written when each job is retrieved, which is probably not necessary and slowing things down wildly.

[ndsieki]

I think we'd also like this code to be able to handle the case where only some of the qubits on the device are measured. Given that we also need to handle mid-circuit measurements (which also affect the length of the bitstring results), perhaps one approach would be to provide two arguments to retrieve_results(): one that specifies a list of ordered target indices for the data bits in the bitstring results, and another that specifies a list of ordered target indices for the mid-circuit measurement bits in the bitstring results. These arguments would supercede the ordered_target_indices variable that is currently used internally in retrieve_results().

Re: the speed of retrieve_results(), I have found the checkpointing to be a bottleneck. Given the speed of the result retrieval for each batch, and the fact that the job IDs are checkpointed during submit(), I think it makes sense to only checkpoint once, after all results have been retrieved.

[coreyostrove]

I think we'd also like this code to be able to handle the case where only some of the qubits on the device are measured. Given that we also need to handle mid-circuit measurements (which also affect the length of the bitstring results), perhaps one approach would be to provide two arguments to retrieve_results(): one that specifies a list of ordered target indices for the data bits in the bitstring results, and another that specifies a list of ordered target indices for the mid-circuit measurement bits in the bitstring results. These arguments would supercede the ordered_target_indices variable that is currently used internally in retrieve_results().

Re: the speed of retrieve_results(), I have found the checkpointing to be a bottleneck. Given the speed of the result retrieval for each batch, and the fact that the job IDs are checkpointed during submit(), I think it makes sense to only checkpoint once, after all results have been retrieved.

I have no immediate concerns about the proposed approach. @ndsieki, @pcwysoc: Are you two cool with taking the lead on making and validating these changes?

[pcwysoc]

@coreyostrove sounds good. I can work on implementing a fix, but it will difficult for me to test right now as I don't have IBM access right now. @ndsieki happy to jump on a call and help you work through this if you're open to taking the lead.