Include RawEventHeader as art product
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.
#1 Updated by Eric Flumerfelt about 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 almost 2 years ago
This functionality is looking good, based on an initial couple of tests.
- 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();
- 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
- 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 almost 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 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 almost 2 years ago
- I removed the extra lines from SharedMemoryReader.
- 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.
- 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.
#6 Updated by John Freeman about 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 about 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.
#11 Updated by Ron Rechenmacher 6 months ago
- Status changed from Resolved to Reviewed