"Holder" parameters

[AdriaanRol]

Originally part of #8, making a separate issue because it is self contained and I am currently running into this problem a lot while rebuilding our "qubit-object" "meta-instrument".

simple creation of "parameter holding" parameters

When converting QTLab instruments I run into a lot of instruments that have simple "holder" parameters. They exist t ensure some parameter of an instrument is logged and viewable. They usually look something like

def _do_set_paramname(value): 
    self.paramname = value
def _do_get_paramname(): 
    return self.paramname

To have the same behaviour in QCodes I would have to do the following
Add the parameter to the init.

self.add_parameter('paramname',
           get_cmd=self._do_get_paramname,
           set_cmd=self._do_set_paramname,
           vals=vals.Anything())

Replace the set and get functions with an underscore

def _do_set_paramname(value): 
    self._paramname = value
def _do_get_paramname(): 
    return self._paramname

There is probably also another way by creating a parameter from scratch in the init and using that but I haven't looked into that yet.

As I very much like the idea of passing strings for instrument driver write commands I thought a similar shortcut for such 'holder' variables would be very nice, something along the lines of

self.add_parameter('paramname',
           get_cmd=holder_getfunc,
           set_cmd=holder_setfunc,
           vals=vals.Anything())

I do not know how best to implement how best to implement this as I am not familiar enough with all the under the hood things in QCodes but as it is such a common task I thought it might be a good idea to consider.

Is there some reason why you can't completely code-gen this (parameter-holding parameters)? Define an "add_simple_parameter" method that just takes the parameter name and vals, and that generates the getter and setter methods and adds them to the object directly?
I know you could do this back in old-school Python (I'm still vintage 1.4), but I don't know if 3.x has made it impossible.

@alan-geller This is exactly what I had in mind, though I am not sure yet on the implementation.

"Holder" parameters are an interesting case, and you're right that these will come up all the time. I'm guessing these are mainly for manual settings that the software otherwise has no way of knowing about, like what kind of attenuation, resistors, cables you have installed, or switches/dials that are invisible to software?

I'll make a Parameter subclass and Instrument method for them, they'd be pretty simple. I'm not sure about the name though... on the one hand I want to call them SoftParameter because they exist only in software, but that contradicts the fact that they are mirroring physical objects that have NO presence in software. Perhaps we call them ManualParameter because when you manually change them outside the software, you have to also manually change them inside software?

Which brings up the other challenge with these parameters: making sure they stay in sync with reality. The only way I see to promote this is visibility: making sure these parameters are very apparent (and easy to update) in whatever monitoring panel we make.

@alexcjohnson What do you think the best implementation is? I see several options with their own pros and cons, note that these relate mostly to how they will be used.

• How do we name this ?
  • soft(ware) parameter
  • holder parameter
  • simple/basic paramater
• Do we want to add an option/keyword to the existing add-parameter or do we want a new add_parameter function?

@damazter, I guess this is also tangentially related to the new types of parameters you were discussing in #28, what do you think of this (in relation to the add_parameter function)

[guenp]

@AdriaanRol I would say there are only 2 types of parameters: ones that you measure (such as temperature), and ones that you get/set occasionally (such as a sweep rate).
IMHO the software parameter, holder and simple/basic parameter all fall into the first category, which would just be covered by add_parameter, which could be a property. If you want the parameter to do something specific, you specify that by passing an fget or fset function that either 1) updates a software attribute, 2) updates an instrument attribute or 3) acts as a 'holder'. Whenever a parameter is changed, this is logged. This way, we don't make the concept of a parameter too complicated. Do you agree?

[damazter]

personally I would be in favor of subclassing the Parameter class.
This new class could be in the parameter.py file.
Such a new class is also how I solved the Alazar related problems. A good name has then to be thought of for this new class,
maybe
StorageParameter
InternalParameter
TrivialParameter
etc

[alexcjohnson]

closed by #39 (but feel free to make a new issue if anything comes up when any of you start using it)