Repository: Qiskit/qiskit

Issue:
test_qobj_to_circuits_multiple is ocassionally failing
<!-- ⚠️ If you do not respect this template, your issue will be closed -->
<!-- ⚠️ Make sure to browse the opened and closed issues -->

### Informations

- **Qiskit Terra version**: latest master
- **Python version**: any
- **Operating system**: any

### What is the current behavior?

When running test_qobj_to_circuits_mutiple we're seeing occasional sporadic failures, like:

https://travis-ci.org/Qiskit/qiskit-terra/jobs/451515130#L2711

It looks like something is getting out of order and that's causing the tests to fail because the lists don't match 100%. We're seeing this mostly in CI, although I was able to reproduce after running `tox -epy37 -- --until-failure` (you can replace 'py37' with the version of python you have installed locally and it will work the same) which ran the tests in a loop until it encountered the failure.  I've attached the subunit file from the failed run for reference too: [failure.subunit.gz](https://github.com/Qiskit/qiskit-terra/files/2555411/failure.subunit.gz)

This leads me to believe there is some non-deterministic behavior in the test or function itself. Or there is a cross interaction with another test in the suite (which by switching to running in parallel in #737 would trigger).

### Steps to reproduce the problem

It's not a 100% failure so either run the tests in the loop until it fails, or look at one of the referenced CI failures.

### What is the expected behavior?

The test passes 100% of the time

### Suggested solutions

Figure out what is causing the failure and address it



Discussion:
Yea saw this as well
I am going to close this as I pretty sure the pr I just put in also fixes this (#1284) but let's open it if we see it again. 

Basically, the circuit changed the order of the qubits.
I think I saw this again in my PR #1285.  It failed, I restarted, it passed.

I can't reproduce it again. But I think the error was that a classical register was written before a quantum register. This might be possible, since @jaygambetta's PR #1284 ordered qregs and cregs, but not total registers. 

This test is stupid, it checks against a hardcoded QASM string. So the ground truth is something like:
```
qreg q[3];
creg c[3];
h q;
measure q->c;
```
and something like this fails:
```
creg c[3];
qreg q[3];
h q;
measure q->c;
```
this is possible as there is no order between classical and quantum 

I see three possible ways. 

1. Make sure when we call circuit.qasm() that we put quantum first. (i dont like this)
2. Have both options as checks and do an xor 
3. Overload __eq__ in QuantumCircuit and have it check the quantum registers, the classical registers and the data in the circuit. I prefer this way as this will be more useful in the long term. 


It just failed on me (https://travis-ci.org/Qiskit/qiskit-terra/jobs/456920806)  and it seems that the classical bits are the wrong order 

 ```
['OPE[238 chars]reg c10[2];\\ncreg c9[2];\\nx q12[0];\\nx q12[1];[111 chars];\\n']
 != 
['OPE[238 chars]reg c9[2];\\ncreg c10[2];\\nx q12[0];\\nx q12[1];[111 chars];\\n']"
```
I am confused by this and will look into it more. In fact, the second seems more correct. 
fwiw, when I added the test as part of #877 just comparing the qasm like that was done just to be fast and simple. Doing what @jaygambetta suggests in his 3rd option (either as an `__eq__` on the circuit object or externally in the test) does seem like a much better way to compare the input circuit and the circuit created from the qasm in the qobj are the same.

That being said it feels like something weird is going on here because the circuit.qasm() function should be deterministic in it's behavior. It just loops over circuit.qregs() prints the qasm for each, then cregs, and then instructions: https://github.com/Qiskit/qiskit-terra/blob/master/qiskit/_quantumcircuit.py#L314-L326 The internal order of those lists should remain the same for all the operations performed in the test.
Hmm, I've been unable to reproduce this locally. I've been running the test_wrapper module in a loop (with `tox -epy37 -- test_wrapper --until-failure`) and it's run > 4420 times so far without failing. I'll keep it running in the background, but when I tried that earlier (when I filed the issue) it was happening much faster.
yeah locally it does not work for me. I also ran it with pr #1296 1000 times with a loop and that has never failed
@mtreinish how can i make the print statements in that pr into a log that we add to master and caputure the output when it fails. 

Resolving patch:
diff --git a/qiskit/dagcircuit/_dagcircuit.py b/qiskit/dagcircuit/_dagcircuit.py
--- a/qiskit/dagcircuit/_dagcircuit.py
+++ b/qiskit/dagcircuit/_dagcircuit.py
@@ -738,7 +738,7 @@ def qasm(self, decls_only=False, add_swap=False,
         # TODO: some of the input flags are not needed anymore
         # Rename qregs if necessary
         if aliases:
-            qregdata = {}
+            qregdata = OrderedDict()
             for q in aliases.values():
                 if q[0] not in qregdata:
                     qregdata[q[0]] = q[1] + 1
@@ -754,9 +754,9 @@ def qasm(self, decls_only=False, add_swap=False,
             out = "OPENQASM 2.0;\n"
             if qeflag:
                 out += "include \"qelib1.inc\";\n"
-            for k, v in sorted(qregdata.items()):
+            for k, v in qregdata.items():
                 out += "qreg %s[%d];\n" % (k, v.size)
-            for k, v in sorted(self.cregs.items()):
+            for k, v in self.cregs.items():
                 out += "creg %s[%d];\n" % (k, v.size)
             omit = ["U", "CX", "measure", "reset", "barrier"]
             # TODO: dagcircuit shouldn't know about extensions


Test patch: