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.

...