Metadata

[MerlinSmiles]

This is a first step towards saving of all avlailable (but still somewhat relevant) metadata as partly discussed in #93.

This is a work in progress, so far, I have been adjusting:

• parameters, added the arguments that we can pass upon initialization, but not set and get cmds and those fancy ones.
• instruments, could only test on mock here tonight, but tried to add things like address, ports, terminators, the __class__
• Also I added the IDN, I chose that the IDN is a key in the snapshot, and the key refers to a dict:

        self.IDN = {'vendor': None, 'model': None,
                    'serial': None, 'firmware': None}

I propose that we enforce this by default. I kind of did this already by adding the IDN to the Instrument class.

For now the station.snapshot() at least gives more information on the setup than before.

[MerlinSmiles]

I also changed a lot of the naming in station.py to reflect the option to put whatever into the station.

[MerlinSmiles]

The naming in the station was maybe not so smart. now I cant do station.instruments anymore but have to do station.components which is not intuitive.

But if we want to add all kinds of things to the station, we cant just call the things instruments?
Maybe we have to put them in different groups within the station.

[MerlinSmiles]

Trying to save the default measurement into the snapshot I run into the problem of non-unique parameters:

for i in station.default_measurement:
    print(i.__class__)
    print(i.name)

<class 'qcodes.instrument.remote.RemoteParameter'>
curr
<class 'qcodes.instrument.remote.RemoteParameter'>
curr
<class 'qcodes.instrument.parameter.StandardParameter'>
volt
<class 'qcodes.instrument.remote.RemoteParameter'>
volt
<class 'qcodes.instrument_drivers.ithaco.Ithaco_1211.CurrentParameter'>
Mælkebøtte

I cannot access the _instrument of the remote parameter.

Somehow I find the non-unique names of parameters and instruments troublesome.
When we at some point save metadata from a loop, we need to be able to uniquely gather the data from a parameter, and relate it to the exact instrument where it lives.

Also later in the data analysis we need to go the other way around for which we kind of need unique names, no?

I cant even tell the parameter what instrument it belongs to as the instrument name is not unique, and a unique name is only generated in the station.

I'm kind of confused here :)

[alexcjohnson]

Trying to save the default measurement into the snapshot I run into the problem of non-unique parameters

Good point - I guess we need a "full name" concept that gets used whenever a parameter is recorded out of the context of its instrument (if it even is part of an instrument). The easiest thing to do is make this a @property of Parameter:

@property
def full_name(self):
    if hasattr(self, '_instrument') and hasattr(self._instrument, 'name'):
        return self._instrument.name + '.' + self.name
    else:
        return self.name

When the RemoteInstrument gets created, this will get copied over, but it's no longer a property then, it gets evaluated to a static attribute. This means if you change the instrument name things will go screwy... but I suspect a lot of things would go screwy anyway if you change instrument or parameter names after creation.

[MerlinSmiles]

That name, would not be unique either.

I can easily make 10 instruments that have the same 'name'. Thus, if they have the same parameter-names, they wont be unique.

[alexcjohnson]

The naming in the station was maybe not so smart. now I cant do station.instruments anymore but have to do station.components which is not intuitive.

But if we want to add all kinds of things to the station, we cant just call the things instruments?
Maybe we have to put them in different groups within the station.

Moreover the fact that you have to try and pull out what kind of component you have later, based on its class, is problematic. Particularly for parameters, they really should be duck typed so people can write their own classes that don't inherit from ours at all.

Different groups sounds like the winner to me.

[MerlinSmiles]

@alexcjohnson today I was trying to collect metadata for the measurement during the run(), I kind of got it to work, but it was a huge mess. And I could not integrate the default_measurement parameters.
I didnt commit that stuff somewhere.

What would be the general strategy to save the whole measurement information?
I now have snapshots for instruments, parameters, and SweepFixedValues.
But a lot of this gets lost when those sweep points are evaluated before the run.

[alexcjohnson]

I can easily make 10 instruments that have the same 'name'

That seems like a problem for other reasons... we should enforce uniqueness of instrument names.

[MerlinSmiles]

I can easily make 10 instruments that have the same 'name'

That seems like a problem for other reasons... we should enforce uniqueness of instrument names.

Yes, I agree, but how, as it is now I dont have to put them into the station, so how would you enforce that without having a collecting mechanism?

[MerlinSmiles]

@alexcjohnson, is the mode of no interest?

[alexcjohnson]

mode is an internal thing that changes throughout the life of a DataSet. But I did include the run() flags which tell you what you might have wanted to know with mode and more, in a more useful way.

[alexcjohnson]

@MerlinSmiles I added a bunch of tests and cleaned up a few things as a result. I think this is OK from my perspective now, do you want to give it a last look?

I'm going to leave the integration of metadata with the DataManager for later; it has only minor effects and this PR is super huge already.

[MerlinSmiles]

Just a minor typo here transormations

[alexcjohnson]

thanks! qdev-dk-archive@cc0601e fixes this and your question from chat about the confusing call in make_sweep tests.

[MerlinSmiles]

This looks good to me! cant find anything that bothers me.

nice with the 'tyop' in the commit message :D

[alexcjohnson]

Any more comments before we merge this? @AdriaanRol @guenp @damazter ? This PR is probably too sprawling to review now anyway, I suggest we merge it and folks can play with it in master and open new issues as things come up.

[AdriaanRol]

No time for really checking it out but I want to use quite a few of these features in #179 so I'm in favor of merging