Add FST raw hits in StEvent and StMuDst

[techuan-huang]

FST group would like to have FST raw hits information for the detector QA in future calibration productions. So we would like to add this information into StEvent and StMuDst. In StEvent part, StFstRawHits.{h,cxx} are moved from StFstUtil to StEvent. A new collection (StFstEvtCollection) is created to keep the backward compatibility. In StMuDst part, 8 files were modified (StMuArrays.cxx/h, StMuDstMaker.cxx, StMuFstCollection.cxx/h, StMuFstUtil.cxx/h, and StMuTypes.hh) and 2 files were added (StMuFstRawHit.cxx/h). Two chain options (fstEvtRawHit and fstMuRawHit) are added to turn this feature on and off.

[starsdong]

Hi Techuan, Thank you. I wonder whether you have a comparison on the MuDst file size difference between before and after this change? Thanks

[techuan-huang]

Hi Techuan, Thank you. I wonder whether you have a comparison on the MuDst file size difference between before and after this change? Thanks

Hi Xin, I think you pointed out the key. I tried with a DAQ file with 7907 events and with only FST and sTGC information. The size before and after were ~28M and ~41M. Its ~48% larger.

[plexoos]

FST group would like to have FST raw hits information for the detector QA in future calibration productions.

Sounds like the inclusion of raw hits is required only for special processing, if so this PR should include a new BFC option to turn this feature on when needed but it should be off by default.

[starsdong]

Hi Te-chuan, it is possible that you can incorporate the suggestion from Dmitri to include a chain option for turning on the FstRawHits in the production?

[techuan-huang]

Hi Xin and Dmitri, Thanks a lot for your suggestions. I have added a new chain option "fstMuRawHit", and now FST raw hits are NOT stored in MuDst by default. They will be stored only when the new option is called during the production.

[starsdong]

Thank you, Techuan. I would like to hear the comments/approval from Daniel B., particularly for the MuDst related changes. Other owners, please feel free to comment as well.

[jdbrice]

We discussed this in our FWD software meeting. We do not normally add info directly to StMuDst that does not exists in StEvent. We had some discussion about the problems this might cause depending on our future plans with embedding. Because of these I am not ready to approve this, though we may in the future, especially if we reach parity with StEvent first.

[techuan-huang]

I have implemented FST raw hits also in StEvent. In order to keep the backward compatibility, I created StFstEvtCollection in StEvent to store the raw hits instead of moving the original StFstCollection to StEvent. A chain option (fstEvtRawHit) similar to the one for StMuDst is also added.

[plexoos]

One test job failed with the following message:

StChain:INFO  - MysqlDb::Connect: Load balancer took 0 ms, will use dbx.star.bnl.gov:3316
StChain:INFO  - Ssl_cipher = AES128-SHA
StChain:ERROR - MysqlDb::ExecQuery() line=662  Query Failed  Lost connection to MySQL server during query
Error: Process completed with exit code 1.

Will re-run it and the skipped jobs

[techuan-huang]

Typically in StEvent we create a hierarchy of collections which reflects the structure of the detector... e.g. an FST collection holds a collection of disks, which holds a collection of wedges, which holds a vector of hits. So a track which intersects any given wedge, you can quickly limit the possible hits to query.

I understand your concern, and the structure you mention is already used for FST hits (the space positions used in tracking). However, the FST RAW hits are not used in tracking and only used for QA. This is why we made chain options to turn it on only when needed. When it is off, everything should be the same as before.

[starsdong]

Daniel, could you please review this PR, comment or approve it so we can proceed soon? Thanks