Bringing back the old digi/rec-producer for testing/debugging purposes

[EinarElen]

This resolves LDMX-Software/ldmx-sw#1351 by adding a new producer called HcalSimpleDigiAndRecProducer. It takes simulation level information and performs rudimentary reconstruction, i.e: for each bar, make a hit where energy/PE, position, and time are a weighted average of the corresponding simhits (weighted by energy deposited).

This verision does not handle noise hits at the moment, but we could introduce that.

I think this is ready for being reviewed, although it needs some polishing (e.g. documentation/comments) before being merged. It could already be useful for some people so I'm creating the PR already.

Below is the hcal DQM plots comparing the regular hcal reco chain with the naive/simple one.

figures.zip

• PE distributions do not feature ADC saturation

• Position along the bars is obviously not well handled by this approach, several hits are far outside of the actual Hcal :)
  

• Hit times are not limited to the 8 time samples, so should also be taken with a bucket of salt
  

• Hit multiplicity is different, which i suspect is from reading out some hits that are out of time or just that the readout threshold is lower. The important part (vetoable hits) is more similar
  
  

• Lastly, I'm a bit curious about the inefficiency figures. In general, the simple reconstruction tends to give us better inefficiencies which probably is optimistic
  
  
  

[cmantill]

hi @EinarElen - this looks like a good idea and the validation plots look good to me.

Just for curiosity, have you played with the readout or in-time thresholds? Curious to see whether the distribution number of hits looks more similar if these are varied. I agree that the important distribution of vetoable hits looks more similar so perhaps that is better, but perhaps it might still be better to get rid of the small energy hits for clustering or visible search purposes.

[EinarElen]

hi @EinarElen - this looks like a good idea and the validation plots look good to me.

Just for curiosity, have you played with the readout or in-time thresholds? Curious to see whether the distribution number of hits looks more similar if these are varied. I agree that the important distribution of vetoable hits looks more similar so perhaps that is better, but perhaps it might still be better to get rid of the small energy hits for clustering or visible search purposes.

Not really, and on the current version there isn't really a in-time threshold at all (I can go ahead and add something like that though) :)

[tomeichlersmith]

I don't really have any comments on the algorithm. I think it makes sense and your plots convince me that there aren't glaring bugs lurking.

I do have a minor suggestion on the technical side. We use C++17 std, so we can take advantage of emplace_back's reference return allowing us to avoid an extra move construction required by push_back. Maybe not a super big performance boost, but I like the look of writing code this way (each barID gets a new hit which we then edit with the specifics in that bar).

[tomeichlersmith]

With the impending submodule->subdirectory transition on Wednesday, I am commenting here to remind you to either merge this PR before then or close it and re-apply the changes after Wednesday to make a new PR on the subdirectory of ldmx-sw.

[cmantill]

@EinarElen , do you want to answer to Tom's comments? Or should we leave this PR for the subdirectory?

[EinarElen]

I can send a patch tonight

[tomeichlersmith]

I have already done the transition and am in the final stages of testing. Updating submodule changes to apply to subdirectories is not a difficult process and one that I've tested on my own branch of the ECal submodule. Please follow those instructions and re-open this PR in ldmx-sw off the new trunk.

[EinarElen]

That works fine!

…

On Wed, May 1, 2024, 20:50 Tom Eichlersmith ***@***.***> wrote: I have already done the transition and am in the final stages of testing. Updating submodule changes to apply to subdirectories <https://ldmx-software.github.io/transition-to-ldmx-sw-v4.html> is not a difficult process and one that I've tested on my own branch of the ECal submodule. Please follow those instructions and re-open this PR in ldmx-sw off the new trunk. — Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMTCOVJHD5O4SCFHRC3OUTZAE2QJAVCNFSM6AAAAABF3MLRBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYHEYTOMBSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>