Page History
...
Accessed from psana event with a pattern like:
evt._dgrams[nDgram].detname[nSegment].drpClassName.attr1.attr2...
- detname is defined by the hutch. For example: "xppcspad" or "xpphsd"
- nSegment is an integer, denoting which portion of a larger detector this is (e.g. cspad panel number)
- drpClassName is defined by the DRP segment-level software via the "Alg" parameter to xtcdata/xtcdata/xtc/ShapesData.hh:Names class. For example: "raw", "fex", "roi1", "roi2"
...
In general xtcdata/xtc/ShapesData.hh::Name names should be python compatible containing only A-Z,a-z,0-9,_. Unfortunately there are exceptions that make general naming conventions difficult to enforce in "attributes" xtcdata/xtc/ShapesData.hh::Name. Note that python-compatibility is enforced for the "detector name" in the higher-level ShapesData.hh::Names. The exceptions for "Name:"
- ENUMDICT and ENUMVAL types have special handling that requires a ":".
- Attributes (e.g. attr1, attr2 in evt._dgrams[nDgram].detname[nSegment].drpClassName.attr1.attr2...) are created by adding "." in the names.
- I think if no alias is specified for epics variables then the ugly epics name is used (often having ":", ".", maybe others, but I haven't seen any)
- feels like we should prevent "." in the xtc name for epics vars, given the fatal error below where "." is incorrectly interpreted as an attribute delimeter
- in the case of step-scans I think the epics variables have no python-compatible alias name. Need to avoid "." here too?
For epics vars with ":" psana handles it correctly by using getattr() for epics vars. But that character does not work for names that are not epics/enumdict/enumval.
For epics vars with a "." we get the fatal error shown here in the ancillary "epicsinfo" object which has a dictionary mapping the xtc Name to the ugly/real epics name. This because the portion of the name after the "." is interpreted as a hierarchical attribute ("container" object) by psana's dgram.cc.The one "fatal" case I have seen is if an epics name has a "." in it which is interpreted as an attribute delimiter. This gives rise to this error:
Code Block |
---|
(ps-4.1.3) psanagpu102:~$ detnames exp=tmoc00118,run=232 Traceback (most recent call last): File "/cds/home/c/cpo/git/lcls2/install/bin/detnames", line 11, in <module> load_entry_point('psana', 'console_scripts', 'detnames')() File "/cds/home/c/cpo/git/lcls2/psana/psana/app/detnames.py", line 71, in detnames names = myrun.detinfo.keys() File "/cds/home/c/cpo/git/lcls2/psana/psana/psexp/run.py", line 159, in detinfo info[(detname,det_xface_name)] = _enumerate_attrs(getattr(self.Detector(detname),det_xface_name)) File "/cds/home/c/cpo/git/lcls2/psana/psana/psexp/run.py", line 118, in Detector setattr(det,drp_class_name,drp_class(det_name, drp_class_name, self.dsparms.configinfo_dict[det_name], self.dsparms.calibconst[det_name], env_store, var_name)) File "/cds/home/c/cpo/git/lcls2/psana/psana/detector/misc_detectors.py", line 23, in __init__ values = getattr(names,n).split('\n') AttributeError: 'container.Container' object has no attribute 'split' (ps-4.1.3) psanagpu102:~$ |
Proposal:
- all pvnames should have "." replaced with "_" in ShapesData.hh::Name to avoid confusion with hierarchy delimiter. This should be done by the step-scan software and epicsArch.
...
- We should not abort, but epics scans need to support "." but xtc naming does not. PvaDetector doesn't need it because it already has to provide an xtc-compatible name, I
...
- believe.
...
- at xtc-level
...
- enforce use of python-compatible characters plus ":" (for epics step-scans which have no alias) and "." for attribute hierarchies. If we support ":" for epics scans, might as well support it for epicsArch as well.