CombinedParameter

[damazter]

@giulioungaretti
Taking a look at the parameter.CombinedParameter
The way it works now is that it settable only to a certain index of a set array.
I would argue that it would be more useful if these parameters are settable to any tuple.
Then it would also be logical to implement a get function for these parameters that return a tuple as well.
I thought that this was also the solution we discussed in the our last QCoDeS meeting.

The reason why I would like this implementation is the following.
There are two different sorts of combined parameters in my mind.
The first kind is just a collection of individual parameters combined in a vector as is implemented in QCodes Now.

The other is a single parameter with many vector components. Setting this parameter only calls a single set function. (An example of this is the magnetic field. It has three components, but they can only be set together, not seperately.)

Then, it should be possible to get and set this parameter as any other, but instead of scalars, one would have tuples.

As for implementation. (this is just my humble oppinion)
Rather than implementing vector parameters around the CombinedParameter, I would like to see that the behaviour of parameters is generalized to being able to handle vecotr values.

Combining two parameters (of dimension 2 and 3 for example) should then give a parameter (let'
s call it par) which can be set like
par.set([[1, 2], [9, 8, 7]])

As a summary:
I think the problem with the current implementation of CombinedParameter is that it does enable native support for vector-like parameters, it only covers the (although very useful) single usecase for a path-like sweep of parameters that already exist.

[AdriaanRol]

@giulioungaretti , from what I understand this means that CombinedParameter is not what was discussed a few weeks ago on Skype.

The idea was that a CombinedParameter is a Parameter, meaning that it is getable, setable and supports usage in the loop. In the current implementation it only supports use in the Loop through a set_array.

The underlying problem this relates to, and that the proposed implementation would solve, was that of "tuple-like" parameters, simply put parameters that have multiple units and labels. Again the concept of the parameter supports this but the implementation does not (I quoted the qcodes docs below to illustrate my point).

A Parameter represents a state variable of your system. Parameters may be settable, gettable, or both. While many Parameters represent a setting or measurement for a particular Instrument, it is possible to define Parameters that represent more powerful abstractions.

The variable represented by a Parameter may be a simple number or string. It may also be a complicated data structure that contains numerical, textual, or other information. More information is available in the API documentation on the Parameter type.

[majacassidy]

@damazter @AdriaanRol - I agree. This is super important for even our simplest measurements. We need to be able to set and get a 3-dimensional magnetic field, and it needs to be logged correctly

[giulioungaretti]

@majacassidy @damazter @AdriaanRol all of the things you are asking can be implemented already :D @alexcjohnson has been working on the docs showing how to do it . So they'll come soon an show the 💡 !!

[giulioungaretti]

btw @damazter @nataliejpg vna's driver does already return a tuple