Discussion: Expanding chamberInfo.py to multi-AMC's/crates (Short Term)

[bdorney]

Brief summary of issue

Types of issue

• [ ] Bug report (report an issue with the code)
• [ ] Feature request (request for change which adds functionality)
• [x] Discussion

Some Proposals

I need a short term hack to be able to handle multiple AMC's in the same crate, and possibly multiple crates by the same DAQ machine. Right now the following dictionaries in chamberInfo.py are index by ohN:

• chamber_config,
• GEBtype,
• chamber_vfatMask, and
• chamber_vfatDACSettings

With the advantage of being human readable but has some drawback that it requires the link number to be common across all dictionaries (room for sysadmin to make a mistake).

Couple ideas come to mind to expand this to a multi AMC/crate environment:

Idea 1: Dictionary Index Is A Mathematical Expression

All dictionaries are kept but we extend index by following:

idx = (crate -1) * 144 + (slot - 1) * 12 + ohN

• Pros: probably requires minimal refactoring for all dependant scripts/functions in gemplotting and vfatqc
• Cons: probably the hardest to maintain...however I expect this to be a "short term solution" and be replaced by a test stand's DB or the production DB (@ P5).

This would also retire the cardName option and probable force the (shelf,slot,ohN) ordered triplet. This is an advantage as it would match cms address table expectations.

Idea 2: Dictionary Keys Are Now Tuples

All dictionaries are kept but their keys are transformed into tuples of(shelf,slot,ohN) to access value of interest.

• Pros: Still minimal refactoring, no complicated index rule to worry about
• Cons: Some refactoring of TTrees in treeStructures.py to contain an AMC branch (backwards compatibility for analyzing old data, but this is solvable), still links a set of common indices across multiple dictionaries. Again expected to be a "short term" solution.

This would also retire the cardName option and probable force the (shelf,slot,ohN) ordered triplet. This is an advantage as it would match cms address table expectations.

Idea 3: Compress Dictionaries into Subset of Nested Dictionaries

The following dictionaries:

• chamber_config,
• GEBtype, and
• chamber_vfatMask.

would be compressed into one dictionary, chamber_config, which would use tuples of the form (shelf,slot,ohN) as the key and would look like:

chamber_config = {
    (1,2,2):{"name":"GE11-X-S-CERN-0001", "GEBtype":"short", "vfatmask":0x8},
    (1,2,7):{"name":"GE11-X-S-CERN-0002", "GEBtype":"short", "vfatmask":0x0},
    ...
    (2,1,3):{"name":"GE11-X-L-BARI-0013", "GEBtype":"long", "vfatmask":0x0801}
    }

To maintain human readability the chamber_vfatDACSettings dictionary would remain as in Idea 2.

• Pros: No complicated index rule to worry about, reduces total number of dictionaries, more pythonic
• Cons: Significant refactoring needed.

Idea 4: Use XML's To Store Config

Using the XML format that the DB will use for GEM hardware, have a set of these XML's on the DAQ machine. These are then maintained by the sysadmin, at runtime (or at setup time) are parsed and used to generate the relevant dictionaries needed. The dictionaries needed could then follow from one of the three ideas above.

• Pros: Probably closest to our longterm desires. Prep's for DB interface in online SW
• Cons: Significant refactoring needed. Tool for parsing XML's must be designed. Not something I could do by myself.

Summary

For a short term solution I think Idea 1 is the fastest to implement and requires the least modification to the existing codebase. Depending where we are with the other SW tools may depend how this moves forward.

Context (for feature requests)

We now have two AMC's in the QC8 uTCA crate (shelf 1). The DAQ machine that runs this setup is running two uTCA crates (shelf 1 - QC8, shelf 2 - Sust. Ops).

Right now the gemuser account is setup only to use QC8 and someone needs to setup their own env on their own account to run the Sust. Ops. setup. And now gemuser cannot easily use two AMC's for tasks such as:

• Configuring,
• Calibrating,
• Connectivity testing,
• etc...

[jsturdy]

I guess I owe you 5CHF @bdorney https://github.com/cms-gem-daq-project/gem-plotting-tools/pull/89#issuecomment-384214775

[bdorney]

Resolved by #189