ReactionFilter outputs slightly different number of events when reading from HDDM or EVIO. (Also JANA's events read & processed don't match)

[nsjarvis]

Using version_5.21.0.xml, I found that when I use ReactionFilter to generate a tree file from EVIO it contains a different number of events than when I use danarest to make an HDDM file and then run ReactionFilter on the HDDM file. I found larger discrepancies when testing the AddFDCHits branch, which writes some extra lines into the HDDM file. Idk why this would be relevant. The numbers below are from using version_5.21.0.xml.

Also I found that JANA's output of events read and events processed don't match, and the discrepancies are different depending on whether I'm using ReactionFilter or danarest. I could imagine that it might not process SYNC events, but I can't imagine that this should vary with the plugin.

Sean suggested that I try the above with the kinematic fit switched off and indeed that removed the discrepancies for the file that I was looking at.

hd_rawdata_030894_000.evio (raw mode)

EVIO with danarest. 126531 events processed (126531 events read)
HDDM with ReactionFilter -PReaction1=1_14__11_12_14 -PReaction1:Flags=B4: 118060 events processed (118062 events read)
hd_root.root: /kpkm__B4/NumEventsSurvivedAction->GetBinContent(1) : 118062.00
tree_kpkm__B4.root: /kpkm__B4_Tree->GetEntries():63

EVIO with ReactionFilter -PReaction1=1_14__11_12_14 -PReaction1:Flags=B4 126531 events processed (126531 events read)
hd_root.root: /kpkm__B4/NumEventsSurvivedAction->GetBinContent(1)
hd_root.root: /kpkm__B4/NumEventsSurvivedAction->GetBinContent(1) : 118062.00
tree_kpkm__B4.root: /kpkm__B4_Tree->GetEntries():62

HDDM with ReactionFilter -PReaction1=1_14__11_12_14 -PReaction1:Flags=B4_F0: 118061 events processed (118062 events read)
hd_root.root: /kpkm__B4_F0/NumEventsSurvivedAction->GetBinContent(1) : 118062.00
tree_kpkm__B4_F0.root: kpkm__B4_F0_Tree->GetEntries(): 211

EVIO with ReactionFilter -PReaction1=1_14__11_12_14 -PReaction1:Flags=B4_F0: 126531 events processed (126531 events read)
hd_root.root: /kpkm__B4_F0/NumEventsSurvivedAction->GetBinContent(1) : 118062.00
tree_kpkm__B4_F0.root: kpkm__B4_F0_Tree->GetEntries(): 211

hd_rawdata_050934_000.evio

EVIO with danarest. 1615921 events processed (1615923 events read)
HDDM with ReactionFilter -PReaction1=1_14__11_12_14 -PReaction1:Flags=B4: 1476034 events processed (1476050 events read)
hd_root.root: /kpkm__B4/NumEventsSurvivedAction->GetBinContent(1) : 1476050.0
tree_kpkm__B4.root: /kpkm__B4_Tree->GetEntries():27578

EVIO with ReactionFilter -PReaction1=1_14__11_12_14 -PReaction1:Flags=B4 : 1615922 events processed (1615923 events read)
hd_root.root: /kpkm__B4/NumEventsSurvivedAction->GetBinContent(1) : 1476050.0
tree_kpkm__B4.root: /kpkm__B4_Tree->GetEntries():27578

I can imagine that the reaction tree size might differ depending on whether it is generated from EVIO or REST if the quantities used to determine kinfit convergence are not stored in the REST file with full precision.

When testing the branch AddFDCPositionstoRESTv2, which adds only the FDC track hit positions to the REST file and does not change anything else (but it's based on the current master), the number of events reaching the tree changed. For the same file hd_rawdata_050934_000.evio I obtained 27579 events via the REST file and 27576 directly from EVIO.

[nsjarvis]

Looking at hd_rawdata_030894_000.evio again with different numbers of threads, using the master branch of halld_recon compiled on Nov 27 (the most recent commit in its log is from Nov 15, 1be1308).

reactionfilter.pdf

[nsjarvis]

I think this shows that (1) when reading HDDM files, hd_root's stated number of 'events processed' is not always correct, and (2) the number of events that the ReactionFilter plugin writes into an analysis tree can be slightly different, depending on whether it was reading EVIO or HDDM.

[nsjarvis]

The discrepancy could be because the momenta are not stored with double precision in the HDDM file, and so when ReactionFilter requires kinematic fit convergence, it is not doing exactly the same calculation in both cases.

[aaust]

Could you please make a few tests with the latest jana2 build?

version_5.22.0_jana2.xml

The commands for hd_root are almost the same, but you have to use --loadconfigs for a configuration file. And the number of events to process is steered with jana:nevents.

[nsjarvis]

Using that build, unfortunately the danarest plugin crashed. @RaiqaRasool

16:53:28.526 [fatal] Exception in worker thread 1 while executing PhysicsEventMap2 on event #149
16:53:28.526 [fatal] Exception in worker thread 4 while executing PhysicsEventMap2 on event #93

JException
Type: std::runtime_error
Message: hddm_r::ostream::unlock_streambufs error - mutex unlock requested when lock not held.
Function: JEventProcessor::Process
Plugin: danarest

I attached the log file, it's quite long because it runs hd_root several times, the command line is written into the log file each time. This was the 4-thread version.

log_rftest_030894_000_j2_n4.txt

[RaiqaRasool]

Hi Naomi,

Thank you for pointing out this issue. The issue stemmed from the recent change to hddm_r that we discussed in the last meeting. I’ve already applied a fix to the rasool_jana2 branch of the halld_recon repository and have asked Alex to rebuild the version with this fix. I’ll provide an update once the new build is available.

Thanks again for your patience!

[aaust]

I just built version_5.22.1_jana2.xml and ran a successful test with the danarest plugin and 4 threads. Can you please try again?