Add interface for dilution fridge logging

[sorewachigauyo]

For https://github.com/qiboteam/dashboards/pull/15, we are using TemperatureController.read_data() to poll temperature data for the Prometheus DB. I heard that this class may also be used in Qibocal routines for some temperature dependence. However, this setup is unique to TII.

To provide a common interface to current (and perhaps future) fridge types, I propose we could either

1. Create a base class (e.g. TemperatureLog) with some common API. We will then derive a class for each of different fridge type or unique access method to the fridge particulars (like the TII setup). This class can be added to the platform at runcard create() so that it can be accessed via the Platform object for logging uses.

2. Create a class that will initialize the corresponding fridge driver. This keeps the API of TemperatureController and existing scripts such as our dashboard temperature monitoring will run without issue.

There are not too many makers of dilution refrigerators in the world, so this shouldn't blow up. We are getting a Leiden fridge next week, so I will update this next month with the new driver.

Checklist:

• [ ] Reviewers confirm new code works as expected.
• [ ] Tests are passing.
• [ ] Coverage does not decrease.
• [ ] Documentation is updated.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 44.44444% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 66.52%. Comparing base (a514441) to head (af41e70).

Files	Patch %	Lines
src/qibolab/instruments/bluefors.py	44.44%	10 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #873      +/-   ##
==========================================
- Coverage   66.59%   66.52%   -0.07%     
==========================================
  Files          55       55              
  Lines        5942     5960      +18     
==========================================
+ Hits         3957     3965       +8     
- Misses       1985     1995      +10     

Flag	Coverage Δ
unittests	66.52% <44.44%> (-0.07%)	:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[sorewachigauyo]

Test script

from qibolab.instruments.bluefors import FridgeLog

folder_path = "/mnt/smb_share"
bf = FridgeLog('bf_fridge',
              address=folder_path,
              channel_vacuum_can=1,
              channel_pumping_line=2,
              channel_compressor_outlet=3,
              channel_compressor_inlet=4,
              channel_mixture_tank=5,
              channel_venting_line=6,
              channel_50k_plate=1,
              channel_4k_plate=2,
              channel_magnet=None,
              channel_still=5,
              channel_mixing_chamber=6)

print(bf.read_data())

and output

Connected to: None bf_fridge (serial:None, firmware:None) in 0.00s
[{'_50K_flange': {'temperature': 48.4718, 'timestamp': 1713531924.209889}, '_4K_flange': {'temperature': 9.37715, 'timestamp': 1713531924.209889}, '_Still_flange': {'temperature': 24.5761, 'timestamp': 1713531924.209889}, '_MXC_flange': {'temperature': 33.6633, 'timestamp': 1713531924.209889}}]

[alecandido]

@sorewachigauyo why did you close this?

I'm not suggesting you to revert your action, it's only to understand.

[sorewachigauyo]

Ah sorry, was caught up in something and forgot to add comment

From the previous dashboard meeting, trying to shoehorn and maintain a one-sized fit all solution for the fridge logging does not make too much sense. For dependencies of this, it would be easier to call the future QiboDB instead, since these two represent essentially the same parameter.

I will add some docker instances in the dashboard repo instead for the interfacing.

[alecandido]

Perfect, thank you very much for your answer :D