Array id names

[MerlinSmiles]

From the discussion in #184, I'd implemented the pattern <inst_name>_<param_name> and append a _set if it was a setpoint array.

Also fixed the tests and toymodel thingys to work with the changes.

I am however sure that this PR will break some local data-handling code people might have around.

[peendebak]

The Load-and-plot-old-data.ipynb does not work for me, the line qc.MatPlot(data.amplitude) should be qc.MatPlot(data.meter_amplitude).

[peendebak]

@MerlinSmiles Is there any way to overrule the automatic naming of the array_ids? The current scheme is inconvenient for me.

For example, with this PR my measurements result in an array with id keithley3_amplitude. I do not want the instrument keithley3 to be there, because tomorrow I might have connected the same measurement to another instrument (e.g. keithley1). In the rest of the code (e.g. plotting, processing) I then have to change keithley3_amplitude into keithley1_amplitude everywhere.

An option would be to make virtual instruments for every physical instrument I have, but that seems like a bit too much overhead.

Are there any references to the array_id after measurements outside the DataSet? In change case I could do something like

station.set_measurement(meter.amplitude)
data=qc.Loop(....)
for key in data.arrays: 
   data.arrays[key].array_id = mynameformatter(data.arrays[key].array_id)

[MerlinSmiles]

@peendebak did you close this intentionally?

As for your question. In this version, there is no way of stopping it. And I don't think there should be a way to stop this.
I strongly think we need this change in the light of the problems discussed in #184. We have to have unique array IDs and a way to distinguish them without random generation.

I understand the issue in your example.
I fixed this in the toymodel here qdev-dk-archive@e3ebe20

The thing is in your example if you on the third day want to measure keithley1_amplitude, and keithley3_amplitude in the same measurement, you would have to access the data by amplitude and amplitude_1 or something like that, and you wont know which is which, if you then change the order of the measurements, the naming will be different again.

for renaming the array_id, yes you can. the dataset loads all information from the metadata snapshot, so you still have the original array.name

pprint([(array_id, array.array_id, array.name) for array_id, array in data.arrays.items()])
for array_id, array in data.arrays.items():
    array.array_id = array.name
pprint([(array_id, array.array_id, array.name) for array_id, array in data.arrays.items()])

you can get direct access to the array metadata also:

pprint(data.metadata['arrays'])

[peendebak]

Sorry for closing, that was not my intention! The ids indeed have to be unique, and your method might already be better than assining random _0 or _1's.

Now that I think of it, I think I don't really care about the names that most. Most of the time I only have a single variable I measure, and I would like to plot or extract that data without remembering what the instrument or parameter was. So I would be happy to extend the functionality of the DataSet, so I can do

qcodes.QtPlot(dataset.main_array() )
A = dataset.main_array()

The main_array function would return the unique array if there is only 1 array, would return the array specified in the metadata (if the user has set that information) or raise in error.

[alexcjohnson]

@MerlinSmiles I like the new names - only quibble is with how you extract the instrument name from the parameter. We shouldn't be using _instrument from outside Parameter and its subclasses - for one, it doesn't even exist in all subclasses! I would propose something like:

class Parameter:
    @property
    def full_name(self):
        try:
            inst_name = self._instrument.name
            if inst_name:
                return inst_name + '_' + self.name
        except AttributeError:
            pass
        return self.name

Then I guess we also need something like this for names? I'm sure the two can be abstracted into something nice and DRY.

[MerlinSmiles]

@alexcjohnson I tried to implement your proposed changes, but I am not sure how to do this for multi-valued arrays.
I hope this hasnt become a huge mess due to all the changes merged in there :(

[MerlinSmiles]

@alexcjohnson no need to chek for now, this merging stuff removed my changes 🐙

[MerlinSmiles]

to be continued in #234