QubitProcessorSpec no longer encoding `availability` correctly

[tjproct]

On develop (and probably master), when a QubitProcessorSpec is created with availability specified rather than geometry, the QubitGraph stored doesn't contain the connectivity information -- it's an empty graph.

pspec = pygsti.processors.QubitProcessorSpec(2, ['Gcnot',], qubit_labels=['Q0','Q1'], availability={'Gcnot':[('Q0','Q1'),]}) pspec.qubit_graph.edges() This will show an empty list, rather than [('Q0','Q1'),]

However, the processor's QubitGraph should inherit from the availability dict --- or at least this used to be what the intended behavior was, and some code in pyGSTi (the CRB and DRB code at least) relies on this and now fails with an obscure failure message at the Clifford compilation stage. I could fix this, but we should agree on what's meant to happen.

[coreyostrove]

Thanks for reporting this, Tim. I'm fairly certain that this problem is essentially the same as was reported in #251. It doesn't look like we have a fix for that yet though.

[tjproct]

Ah, I think you're correct Corey. #251 is a long and confusing thread, but I think its conclusion more-or-less amounts to this.

[enielse]

This a more complicated issue than it might seem. The geometry argument, which can be either a graph object or a string identifying a known graph (like "line") was originally intended to provide an alternative and more limited way of initializing the availability dictionary within a processor spec, but not actually being a public attribute of the processor spec. As such, the availability dictionary should be considered the authoritative store of the "which gates are available on which qubits" information, and the qubit graph as optional side-information whose sole purpose is to help define the availability attribute. In this picture, the behavior noted above is expected: if you specify the availability directly then there's no need to initialize the processor spec's qubit_graph attribute.

Ok, so that was the original idea. It seems reasonable and useful to me for the processor spec to hold some kind of qubit graph inside it, but we'll need to first figure out what this object should be in general. When the processor spec has just a single 2-qubit gate it seems intuitive (to me) that the edges of this graph would match the availability of this gate. But what if there are multiple 2Q gates with different availability? Would there be a graph for each 2Q gate? And what if there are 3Q gates (e.g. Toffoli)? It seems like it's worth doing something sensible that reduces to the single-2Q-gate case nicely, but I'd advocate for discussing and documenting what this is before we try to patch this issue as stated.

A more immediate fix may be to update the CRB & DRB code use the availability dict (though I'm not sure how much work that would be).

[tjproct]

Erik makes good points -- it seems that there are logically distinct objects that we might want to have a processor spec store: an availability that stores programmability information and a qubit_graph that stores information about a device's physical layout. These could be fairly distinct, but are typically connected. Its not obvious to me what behavior we want.

Erik's suggestion of updating the CRB & DRB code to use the availability dict is, I think, reasonable as a temporary solution. The easiest way to do that is to use the availability dict to create a QubitGraph inside that code. It'll do that many times, which is fairly ugly, but it should be an ok temporary solution at least.