Set parameters new
Merge request reports
Activity
added 1 commit
- 9f3bbb4f - Treat custom parameters as labels (no remote supported)
@matias.guijarro I discussed quickly with Linus and we want our added dictionary (currently passed as a json string) to overwrite but not remove the other existing parameters and labels. Since we don't anticipate to use remotes, we can just use the label mechanism, no need to use a patched
ParameterDefinition.I used a separate dict because we don't want to disturb the existing parameters dicts.
I tested it locally and the values show up in the HDF5 file.
This is done IMO.
Edited by Wout De Nolf-
Here is a quick test script if you want to test.
import json from tango import DeviceProxy exp = DeviceProxy( "tango://lid21data.esrf.fr:37869/id00/metaexp/nexus_writer_session" ) mgr = DeviceProxy( "tango://lid21data.esrf.fr:37869/id00/metadata/nexus_writer_session" ) exp.ping() mgr.ping() if mgr.State() == "RUNNING": mgr.endDataset() exp.proposal = 'id002006' exp.sample = 'wout' mgr.datasetName = '0001' exp.dataRoot = '/tmp/scans' mgr.startDataset() parameters = {"InstrumentDetector01Positioners_name": "dety detz", "InstrumentDetector01Positioners_value": "3.2 -15.7"} mgr.SetParameters(json.dumps(parameters)) parameters = {"InstrumentDetector01Positioners_name": "dety detz", "InstrumentDetector01Positioners_value": "10.2 -5.1"} mgr.SetParameters(json.dumps(parameters)) mgr.endDataset() -
@demariaa Just to be clear: if there are
parametersandlabels, they will be used but they will be overwritten by theSetParametersparameters. -
If they don't use the command
SetParameters, everything will work as usual. If they do use that command, they'll overwrite what is set on the tango attributes if some keys fromSetParametersare in parameters or labels.Btw I do not add attributes for these. So for the moment you cannot read them back, you can only set them (as a json string).
Edited by Wout De Nolf -
Coming to think of it, I overwrite the labels for sure (in case of name collisions) but I didn't check for the parameters.
Also here we again overwrite what is set in
datasetso I'll need to ensure what has priority over what:def exportInitial(self, dataset, metadatafilename, entries, files, parameters, sampleParamMap): try: self.entries = entries dataset = self.addParametersToDataSet(dataset, parameters)And then there is
SetSampleParameters. Aiai, I'm not done here...Edited by Wout De Nolf -
This is the current call order to
dataset.add_parameter((key, value)):-
MetadataManager.datasetParamMap<- "parameters" device property -
{**MetadataManager.labels_map, **MetadataManager.custom_labels_map}
labels_map<- "labels" device propertycustom_labels_map<- "labels" from the new SetParameters-
MetadataManager.sampleParamMap -
MetadataManager.getParameters()<- remotes from "parameters" device property
What happens if you add a parameter twice? Because it is stored in a list to 2-tuples in the dataset object, not as a dictionary. So in summary
parameters(local) < labels < custom labels (NEW) < sample params < parameters(remote)That doesn't make much sense.
Edited by Wout De Nolf -
-
The
datasetclass derives fromGeneratedsSuperwhich seems to come from Django? I guess it depends what is done with the list of parameters on the server side in case of name collisions @demariaa ?Edited by Wout De Nolf -
Actually I just noticed
MetadataManager.toDictionaryso the list of key-value pairs does get converted to a dict. So the last one prevails.I went through the code line-by-line and this is the order of parameter/label adding (slightly different from my first analysis):
# MetadataWorker.createDataset # Add "parameters" for n, v in MetadataManager.datasetParamMap.items(): if v: # remotes are filtered out dataset.add_parameter(parameter(n, v)) # MetadataWorker.createDataset # Add "labels" full_labels_map = {**MetadataManager.labels_map, **MetadataManager.custom_labels_map} for n, v in full_labels_map.items(): if v: dataset.add_parameter(parameter(n, v)) # MetadataWorker.createDataset # Add sample params to a separate list of tuples # So this does not affect the priority smpl = sample() for n, v in sampleParamMap.items(): if v: smpl.add_parameter(parameter(n, v)) dataset.set_sample(smpl) # MetadataWorker.exportInitial/MetadataWorker.exportFinal # Add the remote "parameters" for parameter in MetadataManager.getParameters(): dataset.add_parameter(parameter) # MetadataWorker.exportFinal # Not sure what this is client.sendObject(dataset) # MetadataWorker.toDictionary # Final order: last one prevails d = dict() d['proposal'] = dataset.get_investigation() d['beamlineID'] = dataset.get_instrument() d['datasetName'] = dataset.get_name() d['location'] = dataset.get_location() d['startDate'] = dataset.get_startDate() d['endDate'] = dataset.get_endDate() d['sampleName'] = dataset.get_sample().get_name() for p in dataset.get_parameter(): d[p.get_name()] = p.get_value() for key in sampleParamMap: d[key] = sampleParamMap[key]So the order is currently
fixed ones (proposal etc.) < parameters(local) < labels < custom labels (NEW) < parameters(remote) < sample paramswhile we want (I think)
parameters(local) < parameters(remote) < labels < custom labels (NEW) < sample params < fixed ones (proposal etc.)What do you think?
Edited by Wout De Nolf
-
We may also want to query or clear the custom parameters set by
SetParameters. They are cleared atStartdatasetjust likeparameters. Also those are accessible as tango attributes.I could create tango attributes for the custom parameters as well, but I'm afraid of the overhead.
Edited by Wout De Nolf mentioned in merge request bliss/bliss!2370 (closed)
assigned to @matias.guijarro and unassigned @denolf
-
ICAT cannot handle name collisions so I filtered them locally. This is the overwrite priority:
parameters (local/remote tango attrs) < labels (tango property) < custom (NEW) < sample params < globals (proposal etc.)Tested with a live proposal. Done imo @matias.guijarro
Edited by Wout De Nolf mentioned in commit 13596f96
