LArPandora - ProtoDUNEBeamEvent
Dear LArSoft Team,
I hope you are all well. I’m writing on behalf of the Pandora team as we have an issue related to accessing the triggered beam information inside LArSoft. At the moment the client application to Pandora, LArPandora, is a LArSoft owned object that must remain experiment agnostic, however, for validation purposes and physics studies we would like to read in the triggered beam information for the ProtoDUNE experiment. The issue we are facing is that this information is stored in the ProtoDUNEBeamEvent class, which belongs to the dunetpc repository. Adding a dunetpc dependance to LArPandora would break the agnosticism and so cannot simply add in the necessary dependance.
We have been thinking of the cleanest way to resolve this conflict and one suggestion we had, which we would like your thoughts on, would be to create an abstract class that could live inside LArSoft that could be populated by dunetpc and accessed by LArPandora. While in the first instance this class would primarily be used by ProtoDUNE, other LArTPC experiments do have beam line information and so a new abstract class could have use outside the scope of ProtoDUNE.
If you have thoughts or opinions on this topic, I would be pleased to hear them. Thanks in advance for your help and I look forward to hearing your response.
Steve Green on behalf of the Pandora team
#1 Updated by Lynn Garren about 2 years ago
It may be that with a little reorganization that some "experiment independent" code could be isolated. I think the issue is whether the structs FBM (Fiber beam monitor) and CKov (Cerenkov Threshold Detector) are really peculiar to DUNE or ProtoDUNE, or whether they can be useful elsewhere.
If so, it would appear that they and ProtoDUNEBeamEvent and ProtoDUNEBeamSpill (maybe with some renaming) could be moved into lardataobj, and the unwanted coupling could be avoided. An with no introduction of base classes and virtual functions.
#3 Updated by Steven Green about 2 years ago
Kyle Knoepfel wrote:
We would like to schedule a meeting to discuss this with you. When are you available to talk?
Apologies for my slow response. I will discuss with a few members of the Pandora Team to find and suggest some times for a meeting as soon as possible.
#4 Updated by Steven Green about 2 years ago
I've spoken to a few other people in the Pandora team and, unfortunately, it looks like there are no times we are all available until after Easter. We are very happy to organise something for then and suggests some dates if that timescale is ok with you?
One questions we did have regarding the meeting is what is the main aim? If you wanted to discuss the contents of the ProtoDUNEBeamEvent class then it would actually be more beneficial to organise a meeting with Jake Calcutt who is the author of that class. We are still keen to help out in any way possible with this issue though and if a meeting with us would be beneficial, or if you would like us to join in any meeting with Jake, then we will do our best to make sure it happens.
Thanks for your help with this, we greatly appreciate it.
Steve on behalf of the Pandora team
#5 Updated by Kyle Knoepfel about 2 years ago
ProtoDUNEBeam* classes have a lot of interface, and we are concerned that Pandora would need to depend on something so large and experiment-specific. Our hopes are that we could identify the abstractions of those classes required by Pandora, and then determine how those abstractions might be presented to Pandora in a way that is more experiment-agnostic.
#6 Updated by Steven Green almost 2 years ago
Apologies for the slow reply. In that case then I think it does sound sensible that we organise a meeting. Are there any particularly good dates coming up for you and the other members of the LArSoft team? I believe what we are interested in is essentially a measure of the momentum of the triggered particle and the particle ID, which is relatively small and could be made into a small experiment agnostic class that could be populated when the ProtoDUNE beam class is being created.
#7 Updated by Kyle Knoepfel almost 2 years ago
It's quite difficult to find a time where nearly all SciSoft team members' schedules line up. If you would like, I could meet with you, Jake, and anybody else, and we can come up with a proposal for LArSoft. Another possibility is that part of the SciSoft team meeting could be devoted to a discussion about this very issue--we meet on Mondays at 10:15 am (CDT). If you prefer to meet with the whole team, then I suggest this coming Monday, April 29 or May 6. Otherwise, I am fairly free next Thursday (May 2) and Friday (May 3).
Just let me know,
#8 Updated by Steven Green almost 2 years ago
I think we should probably just have a quick chat this week and try and try and get a proposal for LArSoft. What times are you available on Friday the week? I have teaching commitments all day Thursday and Friday afternoon so ideally early would be good, but I understand that might not be possible with the time difference.
#9 Updated by Steven Green almost 2 years ago
Ah that is unfortunate, sadly Thursdays and Friday afternoons (UK time) are when I have teaching commitments. Shall we try next week? I could do either 8-9:30 am (CDT) Tuesday 7th or 8-9 am (CDT) Wednesday 8th. Do either of those work for you?
#11 Updated by Steven Green almost 2 years ago
This is a brief report from the meeting that just took place (7th May 2019) to discuss this issue.
Attendees: Kyle Knoepfel, Leigh Whitehead, Steve Green
We discussed the creation of a new LArSoft owned class for generic trigger information including but not limited to PID, momentum and direction for an arbitrary number of particles per event. We would suggest that the class could live in lardataobj, although we all agreed that if the LArSoft team felt there was a better location for it that we would defer to their better judgement. This class could then be populated in dunetpc in exactly the same way as the pre-existing ProtoDUNEBeamEvent class and then read into Pandora via the larpandora client application. For the moment we suggest persisting both this new class and the current ProtoDUNEBeamEvent object as the ProtoDUNEBeamEvent object contains additional information that is ProtoDUNE specific.
As for the next step, we wanted to open up this suggestion to the LArSoft team to ask for feedback before looking to implement the above suggestion. If anyone has comments or questions that I can help with do please let me know. I look forward to hearing your response.