Feat: default parameter setup before loop

[nulinspiratie]

Lately I've been having more and more often that parameters need to be setup first before they can be used in a loop. This is closely related to the functionality proposed in #274, but is in this case specifically related to parameters.

One example is when acquiring traces using an acquisition controller, the trace output array depends on properties such as the sampling rate and the acquisition time. The metadata of the parameter therefore needs to be set before starting a loop, otherwise it will not match the expected shape of the output array.
This is quite a simple example, and setup actions can be quite more complex, involving configuration of instruments.

My current solution is adding a parameter.setup() function for each parameter, and call them before starting the loop. However, since this setup seems such a common necessity, I was wondering if it would make sense to implement setup() as a default method in the Parameter class, which could then be overwritten. This function would then be called every time a Loop is started, before the actual loop. By having it automated, such that the Loop runs parameter.setup() for every parameter that is swept and detected, one wouldn't have to worry about manually performing a setup.

I think it would be a useful feature, and would make it less likely for people to forget to setup each parameter needed for a measurement.

[giulioungaretti]

@nulinspiratie not sure I follow the metadata issue, and I would really like a more complex example just to understand what the needs are :D

[AdriaanRol]

@nulinspiratie @giulioungaretti I am a big fan of parameter.setup(), we have a similar construction in pycqed.

@giulioungaretti I think @nulinspiratie is refering to the metadata of the parameter itself that is required to determine the shape of the output but I'm not sure. In any case the required functionality is quite common. Especially when using parameters as more abstract things to acquire data.

[giulioungaretti]

@AdriaanRol I like the idea too, but not something that is called by default always. It looks like an anti pattern.

[nulinspiratie]

@giulioungaretti @AdriaanRol From my current experience, the setup of a parameter can fall into two categories, the first being the initialization of metadata, and in the second case, the parameter usually interacts with instruments,

For the metadata, I have given an example above. To give another example, I have created an acquisition controller for our AlazarTech ATS digitizer. This acquisition controller has a parameter called acquisition, which obtains data from the ATS and can perform averaging. It has three averaging modes:

1. Average over all N traces and the entire acquisition duration, return only a single point.
2. Average over all N traces, but not over time, return a single averaged trace.
3. No averaging, return all N traces.

Obviously the metadata of the acquisition parameter changes depending on the averaging mode. In particular, the output array shape is either a single value, a 1D array, or a 2D array, respectively. Furthermore, if the ATS is acquiring data through multiple channels, the output is in fact one of the above mentioned output arrays for each channel.

If this metadata is not appropriately set up before starting a loop, the datasaving will throw an error because its output is not as expected. Therefore, this metadata needs to be correctly set before starting the loop.

The second type of set up a parameter may need, in my experience, is to set up instruments. One example is a T1_parameter, whose set command specifies the wait duration, and get command performs an acquisition. Before a get can be called, this parameter will need to load the appropriate pulse sequence to an AWG. Depending on how this is implemented, sometimes setting up the AWG is done entirely during the set command, but in other cases most of the AWG setup is done once, before starting a loop. In the latter case, this would fall under the parameter.setup().