DAQ should fail to start if there are duplicate channel names.

LLO recently had an issue where duplicate channels were inadvertently added to the EDC channel list. After a power outage forced a DAQ restart, these duplicate channels started getting written by the framewriter into the raw, second trend, and minute trend frames. framecpp_verify reported this as an error on the LDAS side.

Duplicate channel names are prohibited by the frame specification. The DAQ should fail to start if it finds duplicate channel names, and the framewriter should fail to write frames if duplicates exist.

I think what may be happening here is that the main DAQ is only checking the 'fast' channels that come from the front-ends, but not the EPICS DCUID channel lists. This may be because previously the EPICS DCUID was handled locally on each data concentrator. We have certainly seen the existing DAQ code catch (and stop) when there are duplicates in the data from front-ends If that is the case, one fix is to put the duplicate channel check in the EPICS DCUID code when it starts up - this would ensure it got caught before it gets to the downstream main DAQ

I confirmed on the large test stand DAQ that this duplication is not caught, either for EDCU channels or front-end channels - see https://alog.ligo-la.caltech.edu/TST/index.php?callRep=15827

The relevant duplicate channel check code is from line 352 to 369 in daqd.cc. It is surrounded by curly brackets (likely to ensure unordered map variables are destroyed on exit) but appears OK. Also the system log entry "finished configuring data channels" from line 391 appears in rts-daqd journalctl on x2daqdc1, x2daqfw1 after tests

I heard from CIT that they are getting the same duplicate channel error code from framecpp_verify on files from the 40m. They are still investigating the source of the duplicate channels and when they may have first appeared.

Working on debugging now. I think the problem is the use of std::unordered_map< char, int> m. Using a char instead of std::string likely means the map elements are storing the address of the character array and not the string. One needs to provide a hash function for the char*. But we shall see

In daqd.cc I changed the duplicate channel check to use a std::string in the unordered map

   // See if we have duplicate names
    {

        std::unordered_map< std::string, int > m;
        std::string chanName;
        for ( int i = 0; i < daqd.num_channels; i++ )
        {
            chanName = daqd.channels[ i ].name;
            if ( m[ chanName ] )
            {
                system_log( 1,
                            "Fatal error: channel `%s' is duplicated %d",
                            daqd.channels[ i ].name,
                            m[ chanName] );
                return 1;
            }
            m[ chanName ] = i;
        }
    }

After running an new executable this manually on x2daqnds1, where previously daqd found no issues, here it did

[Fri Aug 30 11:33:04 2024] ->3: set log=2
[Fri Aug 30 11:33:04 2024] ->3: set zero_bad_data=0
[Fri Aug 30 11:33:04 2024] ->3: # use channel file cache for daq
[Fri Aug 30 11:33:04 2024] ->3: set master_config="/opt/rtcds/tst/x2/daq1/running/master"
[Fri Aug 30 11:33:04 2024] Fatal error: channel `X2:ISI-HAM8_7_CPS_Y_FC_DIFF_IN1' is duplicated 341758

This can be coded a few ways. One can simply loop through channels doing m[channame]++, then loop again and check for m[i].second

This may not be valid. This channel is not duplicated (or in list). Need to make sure I am allocating enough space for std::string - investigating

Nope it is valid - it is duplicate in the test point file !

[keith.thorne@x2portal.llodts1 8f21ed23a94bed69c6cfe1b930495554]$ grep X2:ISI-HAM8_7_CPS_Y_FC_DIFF_IN1 *
tpchn_x2isiham8.par:[X2:ISI-HAM8_7_CPS_Y_FC_DIFF_IN1]
tpchn_x2isiham8.par:[X2:ISI-HAM8_7_CPS_Y_FC_DIFF_IN1]
X2ISIHAM8.ini:[X2:ISI-HAM8_7_CPS_Y_FC_DIFF_IN1_DQ]
X2ISIHAM8.ini:#[X2:ISI-HAM8_7_CPS_Y_FC_DIFF_IN1_DQ]

created branch 655-daqd-dups to address this issue

created branch 655-daq-should-fail-to-start-if-there-are-duplicate-channel-names to address this issue

mentioned in merge request !649 (merged)

mentioned in commit 4312f2f1

mentioned in commit e996ef83

mentioned in commit a4ffed19

mentioned in commit bd02b917

closed with merge request !656 (merged)

closed with commit a4ffed19