MultiParameter usability issues

[jenshnielsen]

Just some notes of various issues that we should improve with respect to MultiParameters

• [ ] If you provide setpoints but not setpoint_names the setpoints are not used in plots. But stored in set_array in the dataset. Should perhaps raise
• [ ] The documentation claims that setpoints can be a tuple of tuples of various types including numpy arrays. This is currently not true. The code checks that the inner type is among nt, DataArray, collections.Sequence, collections.Iteratorwhich numpy.ndarray is not. If you add it to the check it will fail with a type error (see below). I have not tested if DataArrays work correct. Converting to a tuple solved the immediate problem
• [x] Missing setpoint_units
• [ ] The multidimensional setpoints are too complicated to use (1D then 2D the 3D etc)

[jenshnielsen]

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-7-3209025a3c3c> in <module>()
----> 1 data = qc.Measure(a.acquisition).run()

/Users/jhn/src/Qcodes/qcodes/measure.py in run(self, use_threads, quiet, data_manager, station, **kwargs)
     76 
     77         data_set = self._dummyLoop.get_data_set(data_manager=data_manager,
---> 78                                                 **kwargs)
     79 
     80         # set the DataSet to local for now so we don't save it, since

/Users/jhn/src/Qcodes/qcodes/loops.py in get_data_set(self, data_manager, *args, **kwargs)
    721 
    722             data_set = new_data(arrays=self.containers(), mode=data_mode,
--> 723                                 data_manager=data_manager, *args, **kwargs)
    724 
    725             self.data_set = data_set

/Users/jhn/src/Qcodes/qcodes/loops.py in containers(self)
    521                 # note that this supports lists (separate output arrays)
    522                 # and arrays (nested in one/each output array) of return values
--> 523                 action_arrays = self._parameter_arrays(action)
    524 
    525             else:

/Users/jhn/src/Qcodes/qcodes/loops.py in _parameter_arrays(self, action)
    594             for j, (vij, nij, lij) in enumerate(zip(sp_vi, sp_ni, sp_li)):
    595                 sp_def = (shape[: 1 + j], j, setpoints, vij, nij, lij)
--> 596                 if sp_def not in all_setpoints:
    597                     all_setpoints[sp_def] = self._make_setpoint_array(*sp_def)
    598                     out.append(all_setpoints[sp_def])

TypeError: unhashable type: 'numpy.ndarray'

[jenshnielsen]

More of an Array parameter issue probably but anyway.

If you do a measurement of an array parameter the setpoint array is correctly created as a data array in the dataset but not labled as is_setpoint=True

[paul-lehmann-unibas]

I wanted to ask whether this issue is still actively pursued? I think I also read in some places that the MultiParameter might be deprecated at some point? I have frequent use cases for the MultiParameter, but it can be cumbersome to use. A feature I would like the MultiParameter to have would be to support multi-dimensional non-gridded setpoints.

[jenshnielsen]

This is not something that anyone to my knowledge are actively working on at the moment. None the less I think the MultiParameter sill has issues. If you have some concrete suggestions for improving the MultiParameter (or an alternative design) we are definitely happy to discuss that

[paul-lehmann-unibas]

Maybe to give a bit more context on my view of the MultiParameter: To me, the MultiParameter is effectively a completely defined measurement. I.e. all Parameters are defined along with the code (in get_raw) to execute the measurement. I would therefore like the MultiParameter to support basically all cases, the measurement context supports. It is relevant to me in the context of hardware-controlled measurements. I.e. the hardware is programmed once to go through setpoints of many control parameters and acquire many measurement parameters at each setpoint. I typically write such a measurement in a script using the measurement context. The advantage of doing the same thing with a MultiParameter would be that the hardware controlled part could be nested inside a software controlled part using the dond type functions.

As for concrete suggestions:

• Support arbitrary setpoints, especially non-gridded setpoints.
• Support undefined shapes. In case this is compatible with dond functions.
• The use of dictionaries instead of tuples for the attributes units, shapes, setpoints, ... and also potentially for the return value of get_raw.
• Ideally allow "registering" other parameters directly to the MultiParameter instead of specifying name and unit.