All zero counts when simulating RB data in v0.9.7.2-0.9.7.5

[enielse]

Describe the bug
Simulating RB data using the simulate.rb_with_pauli_errors function results in bogus identically-zero "success counts".

To Reproduce
When running the RB analysis tutorial, RBAnalysis.ipynb, if you set runsims=True and try to generate the "MySimulatedDRBData.txt" file from the line:

rb.simulate.rb_with_pauli_errors(pspec, errormodel, lengths, k, counts, 
                                              rbtype='DRB', filename=filename, verbosity=1)

The output counts (2nd column of the file) are all zeros, e.g.:

# Results from a DRB simulation
# Number of qubits
5
# RB length // Success counts // Total counts // Circuit depth // Circuit two-qubit gate count
0 0 50 106 90
10 0 50 799 784
20 0 50 1473 1385
30 0 50 2128 2059
...

Expected behavior
Counts should not all be zero.

Environment (please complete the following information):

• pyGSTi version 0.9.7.2 to 0.9.7.5
• python version 3.7
• OS X v10.13.6

[enielse]

This issue is due to 3 spurious lines added on Jan 28: e84cae0
In v0.9.7.5 these are lines 181-183 of .../extras/rb/simulate.py:

outputasstring = ''
    for s in output: outputasstring += str(s)
    return outputasstring

These lines take the outcome label, described as a tuple (as usual in pyGSTi) and reformat it as a string. This causes the results dictionary returned from circuit_simulator_for_tensored_independent_pauli_errors to have only string-ified outcome labels in it, which is not the format of idealout on line 302:

scounts.append(outcome.get(idealout,0))

causing outcome.get(idealout,0) to always give 0, hence the problem. It seems like the initial 3 lines were added to facilitate compatibility with some other code - let's look into this.

[newsma]

I had this problem a while ago. It was fixed by @kmrudin. See the following:
#53.

[enielse]

This has been updated (and maybe was before by krudin in another branch?) so that the line (now 308) reads:

scounts.append(outcome.get(''.join(str(idealbit) for idealbit in idealout), 0))

which should remedy this issue by converting idealout from a tuple to a string. This is fixed in version 0.9.8.