Closed rlcee closed 10 months ago
@rlcee, the error I see with -n=4001
is:
%MSG-s ArtException: PostEndJob 04-Dec-2023 11:37:56 CST ModuleEndJob
---- EventProcessorFailure BEGIN
EventProcessor: an exception occurred during current event processing
---- FatalRootError BEGIN
Fatal Root Error: TStreamerInfo::BuildOld
Cannot convert mu2e::ComboHitCollection::_parent from type: art::ProductID to type: art::ProductPtr<mu2e::ComboHitCollection>, skip element
ROOT severity: 2000
---- FatalRootError END
---- EventProcessorFailure END
%MSG
If I then look at the streamer on disk for mu2e::ComboHitCollection
, I get:
root [4] TClass::GetClass("mu2e::ComboHitCollection")->GetStreamerInfos()->ls("");
OBJ: TObjArray TObjArray An array of objects : 0
StreamerInfo for class: mu2e::ComboHitCollection, checksum=0x5df5ad65
vector<mu2e::ComboHit> vector<mu2e::ComboHit> offset= 0 type=300 ,stl=1, ctype=61,
art::ProductID _parent offset= 0 type=62
bool _sorted offset= 0 type=18 record if this collection was sorted
So the _parent
data member on disk is an art::ProductID
. However, the type of _parent
for the in-memory dictionary is art::ProductPtr<mu2e::ComboHitCollection>
, and there is no I/O rule to effect the conversion.
What is your intention with this data product? Are you just trying to read it as part of the process and then skip writing it to the output file?
In the fcl you can find that we input-dropped the inconsistent products. Is there any else we have to do to achieve that goal? In any case, it seems that throw shouldn't depend on the details of -n? Thanks
In any case, it seems that throw shouldn't depend on the details of -n?
When -n=3999
is used, fast-cloning is deactivated, which is reported by art (but suppressed by the services.message
configuration in the trigger[01].fcl
files):
%MSG-w FastCloning: PostProcessEvent 04-Dec-2023 11:50:27 CST run: 1202 subRun: 0 event: 1
Fast cloning has been deactivated for the following reasons:
- There are fewer events to process than are present in the event tree.
%MSG
When fast-cloning is deactivated, ROOT reads each data product, which is often forgiving. However, when -n=4001
, fast-cloning is used, and the cloner checks whether the on-disk and in-memory types are consistent for a given data product. Hence the failure.
I am investigating why ROOT is searching for consistency among branches that are not persisted to the output file. In the meantime, you can disable fast-cloning via RootOutput
's fastClone: false
parameter. Longer term, Mu2e should discuss whether an I/O rule would be beneficial for mu2e::ComboHitCollection
. Stay tuned.
This error is a result of a lack of I/O rule. I've implemented an I/O rule at https://github.com/Mu2e/Offline/pull/1156, which resolves the error.
$ art -c trigger1.fcl dig.mu2e.NoPrimaryMix1BBUntriggered.MDC2020r_best_v1_0.001202_00000000.art -n 4001
...
TrigReport ---------- Event summary -------------
TrigReport Events total = 4000 passed = 60 failed = 3940
...
TimeReport ---------- Time summary [sec] -------
TimeReport CPU = 140.284813 Real = 140.444220
MemReport ---------- Memory summary [base-10 MB] ------
MemReport VmPeak = 5093.55 VmHWM = 1017.38
Art has completed and will exit with status 0.
Thanks Kyle. We have finished testing and it passes our tests. So far as Mu2e is concerned, you may close the issue at your convenience.
Thanks, Rob. Will do.
Reading an art file is successful if the number of events requested is less than the number of events in the file. If the number of events requested is larger than the number of events in the file, the exe throws on the first event. The error message points to a confusion concerning the input drop commands being used.
To reproduce, on a Mu2e interactive machine,
We can currently work around this problem so it is not particularly urgent.