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.

...

• 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. PvaDetector  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.