allowing more than a QM existing at same time

[jjmartinezQT]

Setting the flag to allow multiple QM virtual machines at once. I think the qm.close is already executed when turning off the instrument, so if experimentalist do platform.disconnect() after each experiment, the virtual machine will be wipped off and not left floating around.

[linear]

QHC-622 Adapt the QM drivers so more than one user can measure at the same time.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.81%. Comparing base (b037fca) to head (f5664cf).
Report is 42 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #760   +/-   ##
=======================================
  Coverage   95.81%   95.81%           
=======================================
  Files         267      267           
  Lines        8679     8683    +4     
=======================================
+ Hits         8316     8320    +4     
  Misses        363      363           

Flag	Coverage Δ
unittests	95.81% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[jordivallsq]

Is this the only requirement from QM needed to connect multiple experiments? are there some restrictions in terms of no overlaping input channels or some sort of condition that can couse a crash?

[jjmartinezQT]

Is this the only requirement from QM needed to connect multiple experiments? are there some restrictions in terms of no overlaping input channels or some sort of condition that can couse a crash?

As reported by Yifei the way to do it is to set this flag to True and ensure qm.close() is done every time (see description of this PR for when that happens in Qililab), I assume to not have zombie virtual machines all around or not to reach a limit. The overlapping of input channels I believe it should be a matter of configuration (runcard) but we need to test it with the experimentalists.

[fedonman]

This change could lead to a hanging QM that is not closed.

Imagine the scenario that you execute a QProgram, the QM is opened, but something goes wrong in the QUA execution in hardware. For example, the user uses a loop with a very large arbitrary array and memory overflow happens (Jordi had this issue at some point). The python execution is halted and qm.close() is never called. With close_other_machines=True this was not an issue for the next QProgram execution. With close_other_machines=False there will be a port conflict when trying to open the second QM.

I believe we should add some kind of try/finally to close the QM in any case.

[jjmartinezQT]

This change could lead to a hanging QM that is not closed.

Imagine the scenario that you execute a QProgram, the QM is opened, but something goes wrong in the QUA execution in hardware. For example, the user uses a loop with a very large arbitrary array and memory overflow happens (Jordi had this issue at some point). The python execution is halted and qm.close() is never called. With close_other_machines=True this was not an issue for the next QProgram execution. With close_other_machines=False there will be a port conflict when trying to open the second QM.

I believe we should add some kind of try/finally to close the QM in any case.

Makes sense, where do you suggest to try close the QM, execute_qprogram method?

[jordivallsq]

I agree with the exception introduced to close only the user's connection (although the name turn off is scary for the qm.close ^^

[fedonman]

Seems ok for me! 💯 Have we test it in hardware with some on purpose exceptions?

Also, this might be changed in the future implementation of Session, since it will be responsible for handling these errors.

[jjmartinezQT]

Seems ok for me! 💯 Have we test it in hardware with some on purpose exceptions?

Also, this might be changed in the future implementation of Session, since it will be responsible for handling these errors.

ps: to clarify, it has been used by experimentalists over and over this branch, even when it crashes they can continue working without issue, so I will take that as hardware test.

Not yet tested in hardware, looking for the way to test it with the minimum impact to the guys measuring. Need to generate the on purpose exceptions, or a meaningful way to test this on hardware.