Bug #14378
Can not read association in old file.
Description
Dear LArSoft experts,
While investigating a problem with neutrino ID, I noticed something strange that may be related to the problem I have. It seems start from uboonecode v06_07_00 we cannot read associations in the old file.
To reproduce this problem, one can login uboone gpvm node and do the following:
source /grid/fermiapp/products/uboone/setup_uboone.sh setup uboonecode v06_06_00 -q e10:prof lar -c eventdump.fcl /pnfs/uboone/mc/uboone/reconstructed/prodgenie_bnb_nu_cosmic_uboone_reco2/reco2/prod_v05_08_00/prodgenie_bnb_nu_cosmic_uboone_0_20160324T215541_gen_3c68a4d8-e36e-46c0-b1bc-856dc806d4fb_20160325T161013_g4_20160402T121310_detsim_20160414T093830_reco1_20160415T230029_reco2.root -n 1 | grep 'art::Assns<recob::Vertex,recob::Track,void>' McRecoAprStage2 | pmtrack.................... | ..................... | art::Assns<recob::Vertex,recob::Track,void>................ | ...27 McRecoAprStage2 | pandoraNuPMA............... | ..................... | art::Assns<recob::Vertex,recob::Track,void>................ | ....0 setup uboonecode v06_07_00 -q e10:prof lar -c eventdump.fcl /pnfs/uboone/mc/uboone/reconstructed/prodgenie_bnb_nu_cosmic_uboone_reco2/reco2/prod_v05_08_00/prodgenie_bnb_nu_cosmic_uboone_0_20160324T215541_gen_3c68a4d8-e36e-46c0-b1bc-856dc806d4fb_20160325T161013_g4_20160402T121310_detsim_20160414T093830_reco1_20160415T230029_reco2.root -n 1 | grep 'art::Assns<recob::Vertex,recob::Track,void>' McRecoAprStage2 | pmtrack.................... | ..................... | art::Assns<recob::Vertex,recob::Track,void>................ | ....- McRecoAprStage2 | pandoraNuPMA............... | ..................... | art::Assns<recob::Vertex,recob::Track,void>................ | ....-
My problem is that I have a filter that open the reconstructed file and create new association if the event passes some cuts. In the release higher than v06_07_00 the new association also seems empty. This may be related to the problem with reading associations in the newer releases.
Thanks,
Tingjun
History
#1 Updated by Gianluca Petrillo over 4 years ago
- Description updated (diff)
- Category set to Data products
- Status changed from New to Accepted
- Occurs In v06_07_00 added
- Experiment LArSoft added
- Experiment deleted (
MicroBooNE)
Reformatted.
#2 Updated by Gianluca Petrillo over 4 years ago
I am willing as always to blame art. The module used by eventdump.fcl is FileDumperOutput, from art.
The difference you see there is not necessarily related to your problem.
In art 2.3, art::detail::has_size_member (canvas/Persistency/Common/Wrapper.h) returns true and art::Wrapper::productSize() returns the number of associations in the product.
In art 2.4, art::detail::has_size_member returns false and art::Wrapper::productSize() returns a laconic -.
The commit in question is canvas:1712daf17402363915c497dd16901b64836816b1 for file canvas/Persistency/Common/Wrapper.h.
These look like internal art machinery, so I am not sure this is the explanation to your problem. Does your actual problem go away reverting with LArSoft 6.6?
#3 Updated by Gianluca Petrillo over 4 years ago
For completeness, this is a test I base my statement on:
cat <<EOF > test.cpp#include "canvas/Persistency/Common/Wrapper.h" #include "canvas/Persistency/Common/Assns.h" static_assert(art::detail::has_size_member<art::Assns<int, float>>::value, "No size for Assns");
EOF
g++ --std=c++14 -Wall -pedantic -I"$CANVAS_INC" -I"$CETLIB_INC" -I"$ROOT_INC" -c -o /dev/null test.cpp
The assertion fails with LArSoft 6.7, not with 6.6.
#4 Updated by Lynn Garren over 4 years ago
- Project changed from LArSoft to art
- Category deleted (
Data products)
Reassigning this to art for guidance. I have used Gianluca's test code:
[garren@woof testart]$ setup art v2_03_00 -q e10:prof
[garren@woof testart]$ g++ --std=c++14 -Wall -pedantic -I${CANVAS_INC} -I ${CETLIB_INC} -I ${ROOT_INC} -c -o /dev/null test.cpp
[garren@woof testart]$ setup art v2_04_00 -q e10:prof
[garren@woof testart]$ g++ --std=c++14 -Wall -pedantic -I${CANVAS_INC} -I ${CETLIB_INC} -I ${ROOT_INC} -c -o /dev/null test.cpp
test.cpp:4:1: error: static assertion failed: No size for Assns
static_assert(art::detail::has_size_member<art::Assns<int, float>>::value, "No size for Assns");
^
#5 Updated by Kyle Knoepfel over 4 years ago
- Category set to Infrastructure
- Assignee set to Kyle Knoepfel
- Estimated time set to 0.50 h
- SSI Package art added
- SSI Package deleted (
)
I believe I understand the cause of the error. Investigating.
#6 Updated by Kyle Knoepfel over 4 years ago
- Status changed from Accepted to Resolved
Yes, I had accidentally omitted the const qualification on the size() member introspection when updating the metaprogramming. My apologies.
Implemented with commit canvas:5f12539.
#7 Updated by Kyle Knoepfel over 4 years ago
- Project changed from art to canvas
- Subject changed from Can not read assication in old file. to Can not read association in old file.
- Category deleted (
Infrastructure) - % Done changed from 0 to 100
#8 Updated by Kyle Knoepfel over 4 years ago
Tingjun, is this bug significant enough that a bug-fix release of art is necessary? Unless you rely on this printout for testing purposes or are explicitly using the art::Wrapper<T>::productSize() member function, we do not believe this error (now fixed) fundamentally affects any processing behavior.
#9 Updated by Tingjun Yang over 4 years ago
Hi Kyle,
Thanks for fixing this. I don't think this bug is significant enough for a new release of art. Most likely everything is fine and we just got confused by eventdump.fcl.
Tingjun
#10 Updated by Kyle Knoepfel over 4 years ago
- Target version set to 2.06.00
#11 Updated by Kyle Knoepfel about 4 years ago
- Status changed from Resolved to Closed