genDst adaption for eTOF

[PhilippWeidenkaff]

Contains:

-Implementation of eTOF makers in genDst script
-Adjustments to eTOF calib-, hit-, and matchmaker to check for muDsts when empty StEvents are found (needed to run in genDst.C due to EMC makers)
-Database interface for alignment parameters in Geometry class and Matchmaker

[plexoos]

Thank you Phillipp for addressing the comments!

[genevb]

Unfortunately, merging this PR appears to have caused numerous nightly test job failures for year 2019+ datasets (and tagging SL22b may have been premature). Example from a nightly test log file /star/rcf/test/dev/daq_sl302.ittf/Thu/year_2020/production_11p5GeV_2020/st_physics_20351078_raw_5000001.log:

StETofHitMaker:INFO - *** StETofHitMaker::Make() == StOK(0) ***
StETofMatchMaker:INFO - StETofMatchMaker::InitRun()
StETofMatchMaker:INFO - etofMatchParam: no filename provided --> load database table
StETofMatchMaker:INFO - match radius: 2
StETofMatchMaker:INFO - track cut (nHitsFit): 5
StETofMatchMaker:INFO - track cut (nHitsRatio): 0
StETofMatchMaker:INFO - track cut (low pt): 0.045
StETofMatchMaker:INFO - creating a new eTOF geometry . . .
StETofMatchMaker:INFO - eTOF geometry initialization ...
StETofMatchMaker:INFO - No etof alignment file provided --> use database:
StChain:WARN - StDbSql::QueryDb(table,time) line=439 etofAlign has No data for query
StETofMatchMaker:FATAL - TUnixSystem::DispatchSignals : segmentation violation

How to reproduce in DEV:

root4star -b -q -l 'bfc.C(2,"P2020a,btof,mtd,etofA,BEmcChkStat,picoVtxDefault,PicoCovMtxWrite,-hitfilt,QAalltrigs","/star/rcf/test/daq/2020/351/st_physics_20351078_raw_5000001.daq")'

Please have a look.

Thanks,
-Gene

[genevb]

gdb says:

Program received signal SIGSEGV, Segmentation fault.
0xeb6cd819 in StETofGeometry::readAlignmentDatabase (this=0x15966d50) at .sl73_gcc485/OBJ/StRoot/StETofUtil/StETofGeometry.cxx:1530
1530 St_etofAlign* etofAlign = static_cast< St_etofAlign * > ( dbDataSet->Find( "etofAlign" ) );
(gdb) p dbDataSet
$1 = (TDataSet *) 0x0

This appears to be the common case of not having a database table entry applicable for data for which the table isn't needed. The likely solutions are:

1. Place a default (ideal) entry in the database with beginTime from before all data for which this code may be run. We usually use "1996-01-01" as a default. It may also be necessary for the entryTime to be set (with the help of @dmarkh ) to "1996-01-01" to ensure old BFC chains for this data with this maker, but with a DbV, do not crash. This may not require a code update depending on what is supposed to happen for this case in the code.

2. Modify the code not to crash if no valid entry for the table is found.

However, there were other jobs that crashed too without the etofAlign error. Example:
/star/rcf/test/dev/daq_sl302.stica/Wed/year_2022/production_pp500_2022/st_physics_23010027_raw_1000015.log
which appears to have still crashed in the StETofMatchMaker:
StETofMatchMaker:FATAL - TUnixSystem::DispatchSignals : bus error

-Gene

[PhilippWeidenkaff]

Hi Gene, I'm uploaded a default alignment table. I also added an error-hand-down to the MatchMaker in a new pull request. This new pull request also contains a change in the default start time handling, which caused a 150 ps shift in the timing. It should still be included in the data reproduction! I'm rather confused by the second error. It seems like StMuDstMaker throws this bus error first: QAInfo: doPs for strangeMuDst: EndMaker total =1772.691406 heap =773.125565 and 175.093246( +5.760719) StStrangeMuDstMaker:INFO - *** StStrangeMuDstMaker::Make() == StOK(0) *** StMuDstMaker:INFO - StMuDSTMaker filling StMuFcsCollection from StEvent StMuDstMaker:INFO - fillMuFtt StMuDstMaker:INFO - fillMuFttRawHits StMuDstMaker:INFO - fillMuFttPoints StMuDstMaker:INFO - fillMuFttClusters StMuDstMaker:FATAL - TUnixSystem::DispatchSignals : bus error Function bfc() busy flag cleared Function bfc() busy flag cleared Then the chain starts shutting down and StEtofMatchMaker seems to crash after the MuDst is already written: StMuDstMaker:INFO - ##### virtual void StMuDstMaker::closeWrite() StMuDstMaker:INFO - ##### File=./st_physics_23010027_raw_1000015.MuDst.root NumberOfEvents= 661 ##### StStrangeMuDstMaker:INFO - StV0Controller: Total kept: 0 V0 candidates StStrangeMuDstMaker:INFO - StXiController: Total kept: 0 Xi candidates StStrangeMuDstMaker:INFO - StKinkController: Total kept: 0 Kink candidates StETofMatchMaker:FATAL - TUnixSystem::DispatchSignals : bus error The line directly above seems to come from StStrangeMuDstMaker::Finish(), so the chain should be calling the ::Finish() method of all makers now. StEtofMatchMaker::Finish() looks like this: Int_t StETofMatchMaker::Finish() { LOG_DEBUG << "StETofMatchMaker::Finish()" << endm; if( mDoQA ) { LOG_INFO << "Finish() - writing *.etofMatch.root ..." << endm; setHistFileName(); writeHistograms(); } if( mETofGeom ) { delete mETofGeom; mETofGeom = nullptr; } return kStOk; } Since mDoQa is false in this chain, literally the only thing that is happening is the deletion of the Geometry class. The destructor of the Geometry class should delete all relevant members correctly, but just to be sure i also added a clear() for the only new vector in there. However, any incorrectly deleted pointer in the destructor should thow an Segmentation fault, not a bus error. To be honest, i have no idea what a bus error is supposed to tell me. Best Regards Philipp June 23, 2022 11:37 PM, "Gene Van Buren" ***@***.*** ***@***.******@***.***>)> wrote: gdb says: Program received signal SIGSEGV, Segmentation fault. 0xeb6cd819 in StETofGeometry::readAlignmentDatabase (this=0x15966d50) at .sl73_gcc485/OBJ/StRoot/StETofUtil/StETofGeometry.cxx:1530 1530 St_etofAlign* etofAlign = static_cast< St_etofAlign * > ( dbDataSet->Find( "etofAlign" ) ); (gdb) p dbDataSet $1 = (TDataSet *) 0x0 This appears to be the common case of not having a database table entry applicable for data for which the table isn't needed. The likely solutions are: * Place a default (ideal) entry in the database with beginTime from before all data for which this code may be run. We usually use "1996-01-01" as a default. It may also be necessary for the entryTime to be set (with the help of @dmarkh (https://github.com/dmarkh) ) to "1996-01-01" to ensure old BFC chains for this data with this maker, but with a DbV, do not crash. This may not require a code update depending on what is supposed to happen for this case in the code. * Modify the code not to crash if no valid entry for the table is found. However, there were other jobs that crashed too without the etofAlign error. Example: /star/rcf/test/dev/daq_sl302.stica/Wed/year_2022/production_pp500_2022/st_physics_23010027_raw_1000015.log which appears to have still crashed in the StETofMatchMaker: StETofMatchMaker:FATAL - TUnixSystem::DispatchSignals : bus error -Gene — Reply to this email directly, view it on GitHub (#358 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AIXRR2XQL2C57PNNVKOBRCTVQTKIHANCNFSM5XLLC5JQ). You are receiving this because you authored the thread.Message ID: ***@***.***>

[plexoos]

Example from a nightly test log file /star/rcf/test/dev/daq_sl302.ittf/Thu/year_2020/production_11p5GeV_2020/st_physics_20351078_raw_5000001.log:

root4star -b -q -l 'bfc.C(2,"P2020a,btof,mtd,etofA,BEmcChkStat,picoVtxDefault,PicoCovMtxWrite,-hitfilt,QAalltrigs","/star/rcf/test/daq/2020/351/st_physics_20351078_raw_5000001.daq")'

I added the same test in #371. It passed without crashing

Here are the same lines from the log file (search for StETofMatchMaker::InitRun)

StETofMatchMaker:INFO  - StETofMatchMaker::InitRun()
StETofMatchMaker:INFO  - etofMatchParam: no filename provided --> load database table
StETofMatchMaker:INFO  -  match radius: 2
StETofMatchMaker:INFO  -  track cut (nHitsFit): 5
StETofMatchMaker:INFO  -  track cut (nHitsRatio): 0
StETofMatchMaker:INFO  -  track cut (low pt): 0.045
StETofMatchMaker:INFO  -  creating a new eTOF geometry . . . 
StETofMatchMaker:INFO  -  eTOF geometry initialization ... 
StETofMatchMaker:INFO  - No etof alignment file provided --> use database: 
StETofMatchMaker:INFO  - amount of valid modules: 36
StETofMatchMaker:INFO  - *** StETofMatchMaker::Make() == StOK(0) ***

The etofAlign table seems to be in the DB, and it contains some entries.
Maybe a full rebuild of the libraries can help... Not sure what else to suggest

[genevb]

Hi, Philipp

I see the default database entry is probably working now. However, I noticed that the default entry will be used for the first month of Run 20, which started in early December of 2019, because the entry you had in there before had a timestamp of 2020-01-01. If the default entry has the same content as the 2020-01-01 entry, then that is probably of no consequence. But if they are different, that may not be as desired.

Thanks,
-Gene

[PhilippWeidenkaff]

Hi Gene, Just to be sure, i set up a new database entry on 25.11.2019, in case we ever change the run19 alginment again. I also put up a new pull request, which i would like to still see included in the production library. Best regards Philipp June 25, 2022 10:06 PM, "Gene Van Buren" ***@***.*** ***@***.******@***.***>)> wrote: Hi, Philipp I see the default database entry is probably working now. However, I noticed that the default entry will be used for the first month of Run 20, which started in early December of 2019, because the entry you had in there before had a timestamp of 2020-01-01. If the default entry has the same content as the 2020-01-01 entry, then that is probably of no consequence. But if they are different, that may not be as desired. Thanks, -Gene — Reply to this email directly, view it on GitHub (#358 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AIXRR2QRHHAFWSUA6WENRCTVQ5RFLANCNFSM5XLLC5JQ). You are receiving this because you authored the thread.Message ID: ***@***.***>