AFIT-11 - Implementation of FEE configuration object by wpierozak · Pull Request #15888 · AliceO2Group/AliceO2

wpierozak · 2026-10-02T09:49:34Z

Implementation of FEE configuration CCDB object and DCS workflow that fetches JSON from DCS and transforms it to the CCDB object

…tion.h

…ource files

…tion parser to FT0 task

…ues in FT0DataProcessor

…r of channels in FT0 configuration to 208

…static memory corruption issue in HV schema; fixed schema issues in both FEE and HV

…to FITDCSConfigProcessor, added back DeadChannelMap definition in link file'

…tion object

Please consider the following formatting changes to AliceO2Group#15888

sahilupadhyaya92 · 2026-10-18T13:59:48Z

+// granted to it by virtue of its status as an Intergovernmental Organization
+// or submit itself to any jurisdiction.
+
+// \file FeeConfiguration.h


correct filename in comments

sahilupadhyaya92 · 2026-10-18T14:02:08Z

+  uint16_t adcDelays[NChannels];
+  uint16_t rangeCorrectionAdc0[NChannels];
+  uint16_t rangeCorrectionAdc1[NChannels];
+  uint16_t thresholdCalibration[NChannels];


thresholdCalibration is not included later in operator==(const ChannelsConfig& other) comparison and also not defined as a getter. Any specific reasons ?

sahilupadhyaya92 · 2026-10-18T14:05:17Z

+
+template <int NChannels>
+struct ChannelsConfig {
+  int16_t timeAligments[NChannels];


Spelling of "Alignment" is incorrect almost throughout the draft.

sahilupadhyaya92 · 2026-10-29T09:17:12Z

+{
+struct TriggersConfig {
+  int16_t vertexTimeLowThreshold{o2::fit::config_helpers::DefaultValue};
+  int16_t vertexTimeHighThreshold{o2::fit::config_helpers::DefaultValue};


Just cross-check the data types..
FDD has the same time thresholds declared as "float" and here is "int16_t"

sahilupadhyaya92 · 2026-10-29T09:33:02Z

+#pragma link C++ struct o2::fv0::Fv0FeeConfiguration + ;
+#pragma link C++ struct o2::fit::ChannelsConfig < 48> + ;
+#pragma link C++ struct o2::fv0::Fv0HvConfiguration + ;
+#pragma link C++ struct o2::fit::HvChannelsConfig < 48> + ;


Missing ??
#pragma link C++ struct o2::fv0::TriggersConfig + ;

sahilupadhyaya92 · 2026-10-29T10:12:58Z

+  void setValidateUpload(bool validate)
+  {
+    mValidateUpload = validate;
+  }


mValidateUpload is not initialized in the constructor.
If createObjectInfo() is called before setValidateUpload(), this reads an indeterminate value.
Should we provide an explicit default initialization?

sahilupadhyaya92 · 2026-10-29T11:50:57Z

+
+namespace o2::fit
+{
+rapidjson::Document FITDCSBaseConfigReader::parseJsonBuffer(gsl::span<const char> buffer, bool throwOnInvalidSchema)


Maybe we should also check document.HasParseError() in parseJsonBuffer(), as we already do for schemaDocument in loadSchema() ?
Currently, improper JSON could be returned as the schema validation is being skipped here..

sahilupadhyaya92 · 2026-10-29T19:54:31Z

+{
+  long dataTime = (long)(pc.services().get<o2::framework::TimingInfo>().creation);
+  if (dataTime == 0xffffffffffffffff) {                                                                                                     // means it is not set
+    dataTime = std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now().time_since_epoch()).count(); // in ms


The use of std::chrono::high_resolution_clock here might not guarantee a Unix-based epoch, whereas CCDB validity timestamps require Unix time in milliseconds. Could we double-check whether this is safe? Alternatively, std::chrono::system_clock is also an option.

sahilupadhyaya92 · 2026-10-29T20:43:00Z

+    BOOST_CHECK_EQUAL(parsed.adcZeros[idx], adcZeros[idx]);
+    BOOST_CHECK_EQUAL(parsed.adcDelays[idx], adcDelays[idx]);
+    BOOST_CHECK_EQUAL(parsed.channelMaskData[idx], channelMaskData[idx]);
+    BOOST_CHECK_EQUAL(parsed.channelMaskTriggers[idx], channelMaskTriggers[idx]);


Just curious.. Any reason not to include thresholdCalibration in the test payload ? This is part of ChannelsConfig, but it currently isn’t covered by the channel parsing test.

sahilupadhyaya92 · 2026-10-29T21:00:16Z

+  SimpleFITFEEConfigurationReader reader;
+  reader.parsePmConfig(doc, pmConfig);
+
+  BOOST_CHECK_EQUAL(pmConfig.orGate, orGateValue);


I understand that this is just checking this pmConfig.orGate. We should also check pmConfig.trgChargeLowLevel and pmConfig.trgChargeHighLevel on PM level.
Also, which one actually is this pmConfig.orGate variable ?

sahilupadhyaya92 · 2026-10-30T09:47:46Z

+                    "or_gate": {"type": "number"},
+                    "trg_charge_low_level": {"type": "number"},
+                    "trg_charge_high_level": {"type": "number"},
+                    "fddCoincidenceMode": {"type": "boolean}


missing " after "boolean

sahilupadhyaya92 · 2026-10-30T09:51:13Z

+                    "threshold_calibration": {"type": "array", "items": {"type": "integer"}}
+                },
+                "additionalProperties": false,
+                "required": [


Should threshold_calibration also be included in the required list? parseChannelData() always attempts to parse this array, so a configuration without it would pass schema validation but fail during parsing

sahilupadhyaya92 · 2026-10-30T09:56:27Z

+                    "or_gate": {"type": "number"},
+                    "trg_charge_low_level": {"type": "number"},
+                    "trg_charge_high_level": {"type": "number"},
+                    "fdd_coincidence_mode": {"type": "boolean"}


I noticed that PmConfig contains fddCoincidenceMode and the schema allows fdd_coincidence_mode, but parsePmConfig() never assigns this field. Should it also be parsed here? Otherwise, the stored configuration will always retain the default value (false), even when the JSON specifies a different coincidence mode.

sahilupadhyaya92 · 2026-10-30T10:03:44Z

+                "items": {
+                  "type": ["object", "null"],
+                  "properties": {
+                    "or_gate": {"type": "number"},


Could the PM fields or_gate, trg_charge_low_level, and trg_charge_high_level use "type": "integer" rather than "number" in the schema? The parser reads them using GetUint(), while "number" also permits floating-point values that GetUint() cannot handle.

sahilupadhyaya92 · 2026-10-30T11:13:31Z

+
+} // namespace o2::fdd
+
+#endif // O2_FV0_DCSCONFIGREADER_H


minor typo. should be O2_FDD_....

sahilupadhyaya92 · 2026-10-30T11:28:36Z

+  if (triggersNode.HasMember("sides_combination_mode") == false) {
+    throw std::runtime_error("Missing sides_combination_mode node!");
+  }
+  const auto& sidesCombinationMode = triggersNode["sides_combination_mode"];


I noticed that sidesCombinationMode is omitted from fetchFddFeeConfig.C, although it is required by FDDFEEConfigurationReader. Is there a specific reason for not including it in the JSON output?

Also, could you clarify the intended usage of fddCoincidenceMode? It is defined in PmConfig, but it is neither required by the JSON schema nor populated by parsePmConfig()

sahilupadhyaya92 · 2026-10-30T12:55:13Z

+  config.innerRings = innerRingsLevelNode.GetInt();
+  config.nChannels = nChannelsLevelNode.GetInt();
+  config.charge = chargeLevelNode.GetInt();
+  config.outerRings = chargeLevelNode.GetInt();


Should be config.outerRings = outerRingsLevelNode.GetUint(); ?

sahilupadhyaya92 · 2026-10-30T13:15:12Z

Hi @wpierozak ,

Thanks for the implementation!

The overall structure looks good, particularly the shared FIT configuration readers and their integration into the FDD, FT0, and FV0 DCS workflows.
I’ve left a few inline comments regarding the parsing and representation of some configuration fields.
One additional point concerning the shared CCDB handling: could you please verify that the upload-validation flag is always initialized before DcsCcdbInfo::createObjectInfo() is called? The mValidateUpload member has no default initializer, so its value would be undefined if a configuration path does not explicitly set it.

Otherwise, the implementation looks consistent across the three detectors.

I would suggest to make 4 PRs out of this one: FIT common, FT0, FV0 and FDD.

Thanks a lot for the work!

wpieroza and others added 25 commits August 5, 2026 07:16

Created configuration structures for Channels, Tcm and Pm data

93263cb

Cleaned detector_config::Channels structure

734c2be

Created FEE configuration data types for subdetectors

cf7aa81

Renamed DataFormatsFIT/FeeConfiguration.h to DataFormatsFIT/Configura…

7b1adf6

…tion.h

preparing structure for configuration parsing

2f84eea

Updated DCS code for FT0

2174edf

fixed compilation issues

7152c6e

Created config processors for subdetctors

1575a23

Moved FT0DCSConfigProcessor to seperate file

967fe04

Moved FV0 and FDD config processor classes to dedicated headers and s…

ee61e3d

…ource files

Created FT0FeeConfigurationReader class

3142db3

Created schema validation for FEE configuration

9323b44

Created base class for DCS configuration readers, wired FEE configura…

d173b88

…tion parser to FT0 task

Refactored FITFEEConfigurationReader for better code reusability

abd01f2

Implemented basic unit tests for FITFEEConfigurationReader

4ce8011

Fixed FEE configuration serialization issue

f1efb89

Created HvConfigurationReader and refactor DCSMonitoring classes

a1a512a

Created unit tests for FITHvConfigurationReader and fixed runtime iss…

ccef6c4

…ues in FT0DataProcessor

Included configuration parsing in FV0 config processor; Changed numbe…

201810c

…r of channels in FT0 configuration to 208

Created configuration data types for FDD

02737d6

Updated FDD config processor to include configuration parsing; fixed …

355d969

…static memory corruption issue in HV schema; fixed schema issues in both FEE and HV

Fixed error handling in FDD and FV0 to preven abort on exception

581a9f2

Created scripts to fetch FEE configuration

2d2eb2d

Changed configuration filenames, renamed FITDCSConfigProcessorSpec.h …

d054cc4

…to FITDCSConfigProcessor, added back DeadChannelMap definition in link file'

Added side_combination_mode to configuration structure

5ce8687

alibuild mentioned this pull request Oct 2, 2026

Please consider the following formatting changes to #15888 wpierozak/AliceO2#11

Merged

wpierozak and others added 4 commits October 2, 2026 12:48

Added fdd coincidence mode and threshold calibration to FIT configura…

34e7cab

…tion object

Please consider the following formatting changes

159c731

Merge pull request #11 from alibuild/alibot-cleanup-15888

347489f

Please consider the following formatting changes to AliceO2Group#15888

Added missing copyrights

9cdce47

sahilupadhyaya92 reviewed Oct 18, 2026

View reviewed changes

Comment thread DataFormats/Detectors/FIT/FDD/include/DataFormatsFDD/FeeConfiguration.h Resolved

sahilupadhyaya92 reviewed Oct 29, 2026

View reviewed changes

sahilupadhyaya92 reviewed Oct 30, 2026

View reviewed changes

Conversation

wpierozak commented Oct 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sahilupadhyaya92 Oct 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sahilupadhyaya92 commented Oct 30, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

sahilupadhyaya92 Oct 18, 2026 •

edited

Loading