After updating to the new dataset and latest version of qcodes (a few months since last update) we see quite a few warnings in the initialization at T3.
Should these be ignored or fixed in some way?

@Dominik-Vogel tagging you as I think you have been most involved with the decadac and R&S ZNB.

• now that we have the extension option to save png versions of the matplot can we make it an optional to save the qtplot versions as pngs (both seems overkill) or at least make them save in a subfolder to make things prettier?
• I was also wondering if it's possible the make the matplot pngs match the pdfs so if there is more than one plot per dataset they are saved with one image with all subplots and one individual one for each type?
  @ThorvaldLarsen @Dominik-Vogel thoughts?

Requests not implemented in #83 before merge. Would eb good to have a discussion whether there is a reason not to implement if that is the choice.

I have a couple of request:

• Can we make label and unit of the .data parameter depend on demod_type? So that the label will be e.g. Imaginary (V) or Phase (degree) automatically after changing demod_type?
• Would it be possible to include an update to the ATS9360_ext driver, which has the seq_mode parameter, in this PR to reflect the new setup with settings defined in the yaml file instead? Maybe @nataliejpg has an opinion on updating it. (see #100)
• Getting snapshot update warnings from 0D parameters. Solved by adding snapshot_get=False in the super.init call of Alazar0DParameter. (snapshot_get = False is default for ArrayParameters so there is no problem with AlazarNDParameter.)
• With the current driver I can simultaneously take data from all channels or slices of channels. Is it also possible to take data from an arbitrary set of channels? This seems more and more useful with the current workflow at T3.

@jenshnielsen @Dominik-Vogel @nataliejpg

How do people feel about restructuring the repository? I know that this by default is pretty annoying but I think it would be a lot easier to use and save a lot of headache later. My ideas are

• subfolders in the customised_instruments folder by name of the instrument manufacturer or user defined name, this would mirror the qcodes structure and is useful for cases of multiple customised channels which belong to one instrument or similar.
• a folder for customised_parameters where customised parameters live, the argument against this is that they might be very specific and only work with a particular (customised) instruments and might be better grouped with them
• put the alazar_controller folder inside customised instruments (and pull out the parameters to live in customised_parameters if we go ahead with that).
• delete the subgroup folders (transmon, majorana, spinqubit). If anyone is still using anything from them then it makes more sense to refactor it into somewhere existing or think of a new place to put it named based on functionality rather than the name of the subgroup expected to use it...

@jenshnielsen @WilliamHPNielsen @ThorvaldLarsen

Would be nice if the history logging split the log file for each day rather than just having a single file.
The pythonlog part does this already.

Apparently, Invoke-WebRequest fails on (ancient) powershell versions older than major version 3. The installation script could check the version and warn.

The former is depreciated so we should go through and replace.

When measuring and live plotting with multiple subplots the window with the plots does not resize itself to have reasonably sized subplots. Could we either make this configurable or set it to just do this to some good value automatically?

As discussed on slack; The do1d and do2d functions do not log any information about the sweeps they are starting. They ought to do that. In the core repo, the Loop also has a few print function calls that we should convert into log messages.

@qdev-dk/118

As far as I can see, the log level that is set int the qcodesrc is not used from within qcodes. Instead of setting the loglevel in the wrappers, here:

• want to change it so that it loops over entries in the config file instead of number of channels.
• voltage parameter is not channel.volt as for decadac.

There is a bug with the numbering of channels on Qdac. Python starts counting channels at 0 while the channel outputs on the qdac are named 01-48.

So when setting in the config file 0 = name, .... The qdac output channel set by this line is Ch01.

can we delete this branch now? @jenshnielsen @Dominik-Vogel

it should be possible to choose which subplot you want to load or liveplot as often we want to save the data of multiple subplots but not actually liveplot all of them (eg alazar controllers currently plotting raw_data!)

Moving towards more and more parallel measurements it would be nice to have liveplotting done with the plots in two rows (or three). Doing measurements with 12 plots atm and gets pretty hard to see them all with them on one line.

If we dont fix it here it would be good to keep in mind for a future update to liveplotting in qcodes.

@Dominik-Vogel Was wondering what your thoughts are about how to handle channels in the station configurator, maybe there could be a nicer way than the current on where you have to dig into the parameters by name?

Liveplotting fails for measurement calls on channellist. Same error on both VNA channels and Alazar channels.

With many instruments the .yaml file can get quite long and the possibility for mistakes fairly high over time. Recently had two instruments in the .yaml file duplicated without any errors.

Currently the code ignores the first one in the .yaml file and initialises with the last entry of a given name.

I propose that a check is added to the station configurator such that an error is raised if not all entries in the .yaml file have unique names.

@Dominik-Vogel

StationConfigurator doesn't import port settings from the configuration file, required for e.g. the magnets (qcodes.instrument_drivers.american_magnetics.AMI430). Proposed minimal fix: add

if 'port' in instr_cfg:
    init_kwargs['port'] = instr_cfg['port']

right after

if 'address' in instr_cfg:
    init_kwargs['address'] = instr_cfg['address']

Following the discussion with @Dominik-Vogel and @ThorvaldLarsen I wrote these down so we wouldn't forget them and we can in some cases go ahead an implement and in others maybe discuss a bit.

• make sure that when a non-spectroscopy channel is added all possible generators are deselected as generators on that channel and additionally set to have rf_off. At the moment it sets gen1 to be deselected but that's it.
• when adding a spectroscopy channel the frequency and power of the readout channel should be set (either we should pick some default initial values or use some logic based on existing channels). At the moment when adding a generator the vna also tries to give it a frequency range which is outside the one possible by the R&S SGS100A which causes an error.
• the parameters readout_freq and readout_pow shoudl belong to the spectroscopy channel and not the vna
• is there a way to get it to show all channels in the display when you add one (ie same as pressing 'display' -> 'split' - > 'dual')?
• can we overwrite the 'write' function to add a wait of 0.2 seconds after writing every command
• setMagCav should only exist if a spectroscopy channel is present (and should also really be one per spectroscopy channel but for now maybe simpler just to have some sort of logic which checks for existance in the get function), also new name??
• setMagCav should have settable max/min and detuning. I partially implemented this but it hasn't been tested. In the medium term these should be parameters

As seen in the lab:

When creating a new parameter that is a scaled version of an existing parameter, the validation of the new parameter's values does not correctly match the scaling. As an example, we consider the DummyInstrument. We recall that the "gates" by default have validators <Numbers -800<=v<=400>.

instruments:
  dummy:
    driver: qcodes.tests.instrument_mocks
    type: DummyInstrument
    init:
      gates: ['ch1', 'ch2']

    enable_forced_reconnect: true

    parameters:
      ch1:
        alias: mygate
        scale: 0.001
        unit: mV

Now, in python

from qdev_wrappers.station_configurator import StationConfigurator
scfg = StationConfigurator('MFE_conf.yaml')
dummy = scfg.load_instrument('dummy')

if we set dummy.mygate(500), we get a ValueError that the value is out of bounds, although this would correspond to only 0.5 volts on the instrument. Similarly, if we had scaled the value up in the yaml file, we would now be allowed to exceed the safety range defined by the instrument driver.

@Dominik-Vogel

@jenshnielsen @ThorvaldLarsen @nataliejpg See below a profile of a measurement I am doing with the Alazar card. The bottomline is:

• 126.496 s are spent acquiring, of which:
• 96.024 s are spent at _call_dll (actual measurement time)
• 12.384 s are spent at pre_start_capture, most of which is a call to demodulator.py:53(init)
• 13.981 s are spent at post_acquire (mostly at sample_to_volt_u12 and demodulate)

For reference, a naïve implementation of the demodulation routine (a single matrix product) takes a couple hundred ms. Some suggestions for optimization are:

• Call the Demodulator constructor in the AlazarChannel constructor instead of the acquisition code.
• Optimize sample_to_volt_u12? It's not clear to me what exactly takes that long in that method.
• Have a low-overhead alternative to Demodulator, for people who do not need the additional features.

1586515 function calls (1582362 primitive calls) in 138.488 seconds

Ordered by: cumulative time
List reduced from 1184 to 100 due to restriction <100>

ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 138.488 138.488 {built-in method builtins.exec}
1 0.003 0.003 138.488 138.488 :1()
1 0.013 0.013 138.486 138.486 scan.py:57(do2d)
42/40 0.000 0.000 126.577 3.164 parameter.py:252(call)
128/9 0.001 0.000 126.499 14.055 parameter.py:330(get_wrapper)
1 0.000 0.000 126.496 126.496 alazar_multidim_parameters.py:99(get_raw)
1 0.005 0.005 126.496 126.496 ATS.py:616(acquire)
211 96.024 0.455 96.024 0.455 ATS.py:915(_call_dll)
1 0.575 0.575 13.981 13.981 ATSChannelController.py:264(post_acquire)
1 1.254 1.254 13.405 13.405 ATSChannelController.py:295(handle_alazar_channel)
1 0.375 0.375 12.384 12.384 ATSChannelController.py:196(pre_start_capture)
1 9.690 9.690 11.986 11.986 demodulator.py:53(init)
138 9.091 0.066 9.091 0.066 {method 'commit' of 'sqlite3.Connection' objects}
112 0.002 0.000 8.151 0.073 sqlite_base.py:237(atomic_transaction)
2 0.004 0.002 7.287 3.644 measurements.py:184(flush_data_to_database)
2 0.000 0.000 7.284 3.642 data_set.py:357(add_results)
2 0.003 0.002 7.278 3.639 sqlite_base.py:397(insert_many_values)
1 0.000 0.000 7.163 7.163 measurements.py:287(exit)
1 0.026 0.026 5.597 5.597 ATSChannelController.py:366(_to_volts)
1 5.570 5.570 5.570 5.570 acq_helpers.py:4(sample_to_volt_u12)
1 4.288 4.288 5.400 5.400 demodulator.py:90(demodulate)
100 4.088 0.041 4.088 0.041 ATSChannelController.py:254(handle_buffer)
1 0.000 0.000 3.530 3.530 measurements.py:241(enter)
4 3.408 0.852 3.408 0.852 numeric.py:1076(outer)
4 0.000 0.000 2.708 0.677 data_set.py:241(add_parameter)
4 0.000 0.000 2.705 0.676 sqlite_base.py:1101(add_parameter)
161 0.001 0.000 1.865 0.012 sqlite_base.py:214(transaction)
161 1.742 0.011 1.864 0.012 {method 'execute' of 'sqlite3.Cursor' objects}
24 0.000 0.000 1.628 0.068 contextlib.py:85(exit)
56 0.000 0.000 1.628 0.029 {built-in method builtins.next}
46 0.000 0.000 1.628 0.035 sqlite_base.py:264(atomic)
2495 1.162 0.000 1.162 0.000 {method 'reduce' of 'numpy.ufunc' objects}
2 0.000 0.000 1.155 0.577 fromnumeric.py:2806(mean)
2 0.000 0.000 1.154 0.577 _methods.py:53(_mean)
4 0.000 0.000 1.081 0.270 sqlite_base.py:1140(_add_parameters_to_layout_and_deps)

Could be in the yaml file, but also make a function monitor.add_all_pars_from_instr(instr_ref)
:)
@Dominik-Vogel

I think we should reformat the custom instruments file into a folder instead i.e. a Custom instruments folder that has files such as Decadac_cQED, ZNB_cQED, qDac_cQED... This way it is easy to get an overview of what instruments have extended and in PR's it is easy to see which instruments are affected.

Several places throughout qdev-wrappers the wrappers logger module is imported.
These should be updated to call the qcodes logger with updated function names (at the moment anytime one imports qdev-wrappers it prints the deprecation warning added in #168).

@Dominik-Vogel tagging you, as I think you have the best overview of the differences between the two logger modules in case one cant just simply replace the import call everywhere.

It would be nice to have the option to do a full station update at the beginning of each do1d/do2d scan. This is especially useful when having virtual instruments that inherits parameters from other instruments.

F.ex. I make a qc.Parameter() that changes two channels on the qdac. When sweeping this parameter the metadata of the qdac is not updated meaning the saved voltages are wrong.

Would be nice to have a few more example scripts and maybe also a readme or similar for the workflow (ie you should install XYZ, make a copy of the templates folder in M location, make L changes and then run N script to get started measuring) with explanation of how it all works etc.

Examples which would be nice:

• an extension to the vna example to flesh out how spectroscopy mode works with all the latest bells and whistles
• an example of using some of the analysis and plotting functions when they have been cleaned up a bit
• some more examples of how the wrappers facilitate multi qubit measurement eg uploading to the awg, setting things on alazar and microwave source concepts.