Idea #20815

Include RawEventHeader as art product

Added by Eric Flumerfelt over 2 years ago. Updated 9 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


The RawEventHeader is used by the art input source to set some of the art event fields. However, there is some information in there that may not be available elsewhere. We should make sure that the RawEventHeader is added to the art Dictionaries and added to each event in the input source.

Related issues

Related to artdaq - Feature #5958: Add the ability to flag various conditions in a RawEventClosed12/18/2012

Blocks artdaq - Feature #24541: Generate requests in EventBuilders in child subsystemsClosed06/17/2020


#1 Updated by Eric Flumerfelt over 2 years ago

  • Status changed from New to Resolved
  • Assignee set to Eric Flumerfelt

There are two parts to this implementation: Adding the RawEventHeader to the ROOT dictionary, and putting the header into the art event in the input source.

1st part: artdaq_core:feature/RawEvent_HeaderInArtDictionary
2nd part: artdaq:feature/SharedMemoryReader_RawEventHeaderInArtEvent

Code has been tested using artdaqDriver and the version of EventDump_module found in the feature/SharedMemoryReader_RawEventHeaderInArtEvent branch.

#2 Updated by Kurt Biery over 2 years ago

This functionality is looking good, based on an initial couple of tests.

A few questions came up as I looked at things:
  1. I noticed that the following pair of lines shows up twice in the SharedMemoryReader constructor. Should/can the second pair be removed?
                                    incoming_events.reset(new SharedMemoryEventReceiver(ps.get<uint32_t>("shared_memory_key", 0xBEE70000 + getppid()), ps.get<uint32_t>\
    ("broadcast_shared_memory_key", 0xCEE70000 + getppid())));
                                    my_rank = incoming_events->GetRank();
  2. In the event dump, the RawEventHeader fragment count and the word count are typically listed as zero, as shown below. I wonder if this will always** be true, and therefore we should suppress those fields from the event dump output. (** since the determination of the fragment count and word count are determined from the "fragments_" data member in RawEvent, and since it is only the RawEventHeader that is stored in the art/ROOT event, it seems like we will never be able to display these values.)
    ***** Start of EventDump for event 427 *****
    Event Header: Run 237, Subrun 1, Event 427, SeqID 427, FragCount 0, WordCount 0, Complete? 1
  3. I ran a test in which one of the fragments in an event had its 'missing data' flag set to true. This didn't get reflected in the RawEvent Complete? flag (which still showed "1"). This could be because RawEvent::Complete? is intended for a different purpose, or because we haven't yet added the code to properly set the RawEvent::Complete? flag when a fragment has some missing data. Do you know whether either of these might be true?


#3 Updated by Eric Flumerfelt over 2 years ago

1. Looks like a merge issue, develop only has it once
2. That looks to be correct. However, this is a change that would either have to be made in artdaq_core (in, or by adding a full member-wise dump in EventDump_module (and remembering anywhere else that we print out the RawEvent that the fragments_ vector may be empty).
3. I believe that the RawEvent::isComplete() flag is intended to indicate whether all expected Fragments are present. I agree that this could be misleading, and we should carefully thing about the language we want to use. I would vote for adding another field to RawEventHeader so we can say "Complete, missing data" or "Incomplete, not missing data", etc.

#4 Updated by Kurt Biery over 2 years ago

  1. I removed the extra lines from SharedMemoryReader.
  2. It seemed like creating an operator<< function for RawEventHeader and using that in the EventDump_module was another option. I've committed some code along these lines. Please take a look and see if that makes sense.
  3. I agree with (what I believe to be) the sentiment of what you are saying. That is, maybe we leave RawEventHeader::is_complete as providing feedback on whether the correct number of fragments are present, and we add new data members over time to indicate other conditions, such as whether one of those fragments is an Empty fragment or one of those fragments has some sort of internal inconsistency.

#5 Updated by Eric Flumerfelt over 1 year ago

  • Related to Feature #5958: Add the ability to flag various conditions in a RawEvent added

#6 Updated by John Freeman over 1 year ago

I've merged artdaq-core's develop branch into feature/RawEvent_HeaderInArtDictionary and artdaq's develop branch into feature/SharedMemoryReader_RawEventHeaderInArtEvent and pushed the change to the central repo. However, if I perform a run with artdaq and artdaq-core modified in this fashion using the demo config, what I see is the following error message:

2019-10-30 13:43:54 -0500: %MSG-s ArtException:  PostEndJob ModuleEndJob
2019-10-30 13:43:54 -0500: cet::exception caught in art
2019-10-30 13:43:54 -0500: ---- OtherArt BEGIN
2019-10-30 13:43:54 -0500:   ---- LogicError BEGIN
2019-10-30 13:43:54 -0500:     NoDictionary: Could not find dictionary for: artdaq::detail::RawEventHeader
2019-10-30 13:43:54 -0500:     despite passing runtime dictionary checks.
2019-10-30 13:43:54 -0500:   ---- LogicError END
2019-10-30 13:43:54 -0500: ---- OtherArt END
2019-10-30 13:43:54 -0500: %MSG
2019-10-30 13:43:54 -0500: Art has completed and will exit with status 1.

Details are in mu2edaq13:/home/jcfree/run_records/3047

#7 Updated by John Freeman over 1 year ago

  • % Done changed from 0 to 100
  • Status changed from Resolved to Reviewed

Eric looked at my last comment and found that the build with the feature branches worked for him; looking back it seems like the problem may have been my using artdaq-utilities v1_05_02 in conjunction with the feature branches of artdaq-core and artdaq. Using the develop branch of artdaq-utilities, things work fine. E.g., if I take the root file from run 3050 (/home/jcfree/run_records/3050) and run EventDump on it with "verbosity: 2", I see the following:

Event Header: Run 3050, Subrun 1, Event 1, SeqID 1, Complete? 1, Version 0

...etc. Looks fine to me, although perhaps a little more information on the definition of "Complete" would be helpful (e.g. "<M> of <N> expected fragments"). Reviewed.

#8 Updated by Eric Flumerfelt 10 months ago

  • Blocks Feature #24541: Generate requests in EventBuilders in child subsystems added

#9 Updated by Eric Flumerfelt 10 months ago

  • Status changed from Reviewed to Resolved

I have updated the artdaq and artdaq_core feature branches with new code to be compatible with the current version of artdaq. See Feature #24541 for testing.

#10 Updated by Eric Flumerfelt 10 months ago

I have added a feature/20815_RawEventHeader_timestampField branch to artdaq-demo-hdf5 to reflect the addition of a timestamp field to RawEventHeader

#11 Updated by Ron Rechenmacher 10 months ago

  • Status changed from Resolved to Reviewed

#12 Updated by Eric Flumerfelt 9 months ago

  • Target version set to artdaq v3_09_00
  • Status changed from Reviewed to Closed

Also available in: Atom PDF