Special instructions: FED included/excluded

[gladky]

from section FEDs to be included / excluded

  * *FEDs to be taken in/out by default*
      * *CTPPS_TOT*: CTPPS_TOTEM FEDs 584 and 585 are OUT of the run in normal data taking phases. These FEDs are only used for the alignment runs and special runs with low lumi.
      * Trigger FED 1405 *GTUPSPARE* is out of any global run.
      * *CASTOR* is not present in 2018.
   * Rules:
      * If CSC are out, EMTF FEDs 1384 and 1385 need to be taken out of run.
      * If all six Track Finder TF FEDs (1384, 1385, 1376, 1377, 1380, 1381) are out, uGMT FED 1402 need to be taken out of run.
      * *Normally, the TF FEDs need to be then taken manually back in, when the subsystem comes to global.*
      * If TRIGGER is out (running with random triggers from TCDS), TWINMUX FEDs 1390, 1391, 1393, 1394, 1395 need to be taken out of run because they are configured by TRG.

from section Short term special instructions [ up-to-date as of April 17 ]

* *CTPPS* and *CTPPS_TOT*: For high-lumi operations, include FEDs:
      * Pixels: 1462, 1463 and the corresponding amc13: FED 11462.
      * Diamonds: 582 and 583.
   * *CTPPS_TOT*:TOTDET FEDs 586 and 587 are OUT as they are not yet commissioned (2018-04-04 Hannes.)
   * *CTPPS_TOT*: CTPPS_TOTEM FEDs 584 and 585 are OUT of the run in normal data taking phases. These FEDs are only used for the alignment runs and special runs with low lumi (AG, July 9th 2017).

[gladky]

Some of the rules here we could verify with simple LM:

• LM will fire only during global runs or we check if the subsystem is masked or not
• define FED ids that we expect to be IN
• define FED ids that we expect to be OUT
• inform when we configuration doesn't comply with expectations

As this may change frequently we could implement it in following fashion:

• define list of fed ids that are expected to be OUT and IN in properties file
• introduce API in expert that will pick new properties file on request

This way we don't have to redeploy DAQExpert but we'll send the request to defined endpoint to signal that new configuration can be picked up

[hsakulin]

I would tend to NOT put these rules in the DAQExpert for the time being.

On 04 May 2018, at 15:17, Maciej Gladki notifications@github.com wrote:

Some of the rules here we could verify with simple LM:

• LM will fire only during global runs or we check if the subsystem is masked or not • define FED ids that we expect to be IN • define FED ids that we expect to be OUT • inform when we configuration doesn't comply with expectations As this may change frequently we could implement it in following fashion:

• define list of fed ids that are expected to be OUT and IN in properties file • introduce API in expert that will pick new properties file on request This way we don't have to redeploy DAQExpert but we'll send the request to defined endpoint to signal that new configuration can be picked up

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gladky]

Ok sure, it will stay as is. Just for reference, what's the reason behind this?

[hsakulin]

The rules are already checked by the Level-0.

The FEDs in&out section may change at any time on request of sub-systems.

[gladky]

Closing as it will stay in special instructions as is and won't be implemented in expert.