Qsoverlay switches order of gates?

[Astlaan]

Hello,

I'm having a strange behaviour when using qsoverlay:

# Quantumsim (via Qsoverlay) program generated by OpenQL
# Please modify at your will to obtain extra information from Quantumsim

import numpy as np
from qsoverlay import DiCarlo_setup
from qsoverlay.circuit_builder import Builder
from quantumsim.sparsedm import SparseDM

# print('GPU is used:', sparsedm.using_gpu)
#Now the circuit is created

def circuit_generated(noise_flag, setup_name = 'DiCarlo_setup'):
	qubit_list = ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16']
	if setup_name == 'DiCarlo_setup':
		setup = DiCarlo_setup.quick_setup(qubit_list, noise_flag = noise_flag)
	b = Builder(setup)
	b.add_gate('prepz', ['5'], time = 620)
	b.add_gate('X', ['5'], time = 630)

	b.finalize()
	return b.circuit

c = circuit_generated(False)
bell_state = SparseDM(c.get_qubit_names())
c.apply_to(bell_state)
measurement_result = bell_state.peak_multiple_measurements(c.get_qubit_names())
print(measurement_result)
print(c.gates)
print(c.gates[0].time)
print(c.gates[1].time)

When I run this program, this is what I get:

[({'0': 0, '1': 0, '10': 0, '11': 0, '12': 0, '13': 0, '14': 0, '15': 0, '16': 0, '2': 0, '3': 0, '4': 0, '6': 0, '7': 0, '8': 0, '9': 0, '5': 0}, 1.0000000000000004), ({'0': 0, '1': 0, '10': 0, '11': 0, '12': 0, '13': 0, '14': 0, '15': 0, '16': 0, '2': 0, '3': 0, '4': 0, '6': 0, '7': 0, '8': 0, '9': 0, '5': 1}, 0.0)]
[<quantumsim.circuit.RotateX object at 0x000001C47C7BA710>, <quantumsim.circuit.ResetGate object at 0x000001C47894F940>]
10.0
620

As it can be seen, the computed output is one of full zeros, despite applying an x gate.
I then checked the gate list in the quantumsim circuit object and, apparently, changed the time of the x gate (in such a manner that it even inverted the order of the gates).

[Astlaan]

Hello,
Any idea on this?
Urgent help is appreciated,

Thanks

[obriente]

That's very weird, it looks like a bug, but I can't see where it can be in the code. I'm away for the next week though - I'll try to find the time to look at it but I can't promise anything for a while.

[Astlaan]

After verifying a similar behaviour in #19 , made a pull request #20 that should also fix this.