Project

General

Profile

Idea #20815

Include RawEventHeader as art product

Added by Eric Flumerfelt about 1 year ago. Updated 12 days ago.

Status:
Reviewed
Priority:
Normal
Category:
-
Target version:
-
Start date:
09/12/2018
Due date:
% Done:

100%

Estimated time:
Experiment:
-
Duration:

Description

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

History

#1 Updated by Eric Flumerfelt about 1 year 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 10 months ago

Eric,
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?

Thanks,
Kurt

#3 Updated by Eric Flumerfelt 10 months 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 RawEvent.cc), 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 10 months 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 24 days ago

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

#6 Updated by John Freeman 12 days 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 12 days 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.



Also available in: Atom PDF