Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor fix to OpHitFinderDeco_module. #62

Merged
merged 1 commit into from
Sep 26, 2024

Conversation

vpec0
Copy link
Member

@vpec0 vpec0 commented Sep 25, 2024

OpHitAlg_deco was trying to use raw::OpDetWaveform timestamp when processing recob::OpWaveform. This is unnecessary as the latter carries the former's timestamp, too. The way the timestamp was retrieved did not give freedom to not have recob::OpWaveforms for some raw::OpDetWaveforms.

…mp when processing recob::OpWaveform. This is unnecessary as the latter carries the former's timestamp, too. The way the timestamp was retrieved did not give freedom to not have recob::OpWaveform's for some raw::OpDetWaveform's.
@vpec0 vpec0 requested review from lpaulucc and mantheys September 25, 2024 15:13
@jroto
Copy link
Member

jroto commented Sep 25, 2024

Hi @vpec0 , if I understand well, this PR address this issue, right?

@mantheys
Copy link
Member

mantheys commented Sep 25, 2024

The reason this was implemented like this is the following:
2 TimeStamp classes:
○ raw:OpDetWaveform returns TimeStamp_t which is a double.
○ recob::OpWaveform returns a raw::RDTimeStamp which returns a ULong64_t.
■ Conversion from the original TimeStamp is not possible. Ideas?
■ Possible workaround -> keep using TimeStamp from raw:OpDetWaveform in
OpHitFinder and other modules.

In the deco wvfs, we cannot save negative timestamps. But these are necessary for simulation as the neutrino interaction happens at T0 but the background could produce signals earlier.

@aolivier23
Copy link
Contributor

I'm holding off on reviewing this for now while the discussion continues. I can add it to a release tomorrow if you resolve it by then. Otherwise, I'll be back in a week or so when the next LArSoft release is ready.

@jroto
Copy link
Member

jroto commented Sep 25, 2024

Hi @mantheys, please correct me if I'm wrong, but the issues you mentioned were already reported and solved in:
LArSoft/lardataobj#37
LArSoft/lardataobj#40
It looks solved to me, fTimeStamp is now a double in OpWaveform as in OpDetWaveform. This is why I opened this issue last year:
#41
Am I missing something?

@vpec0
Copy link
Member Author

vpec0 commented Sep 26, 2024

Hi @vpec0 , if I understand well, this PR address this issue, right?

It appears so. I was not aware of this issue, but it now makes sense.

This problem still persists. In the deco wvfs we cannot save negative timestamps. But these are necessary in simulation as the neutrino interaction happens at T0 but background could produce signals earlier. So unless queue find a different solution, I would not apply these changes.

I must agree with Jose here, the TimeStamp() method in recob::OpWaveform now returns double and it is filled with the timestamp of the raw::OpDetWaveform.

@mantheys
Copy link
Member

Sorry, my fault! I was not aware of the changes in Larsoft. Happy to see this solved!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants