Add 2019 SVT EVIO reader

[omar-moreno]

This is needed to port over SVT calibration code.

[JeremyMcCormick]

Suggestion: Why don't you write out LCIO from hps-java, which you can already read into hpstr?

Seems like maybe EVIO capability doesn't belong in hpstr (?).

Or is the calibration code based on using the EVIO API?

[omar-moreno]

This is meant to allow the porting of calibration code.

…

On Wed, Mar 25, 2020 at 10:07 PM Jeremy McCormick ***@***.***> wrote: Suggestion: Why don't you write out LCIO from hps-java, which you can already read into hpstr? Seems like maybe EVIO capability doesn't belong in hpstr (?). Or is the calibration code based on using the raw EVIO data? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JMXEKVBNKR57E64TOOK3RJLPHPANCNFSM4KIROW3A> .

[omar-moreno]

I have everything I need to do this i.e. the reader and event builder, but I just need to find the time to copy everything over. That said, this isn't something we need to worry for a few months.

…

On Wed, Mar 25, 2020 at 10:14 PM Omar Moreno ***@***.***> wrote: This is meant to allow the porting of calibration code. On Wed, Mar 25, 2020 at 10:07 PM Jeremy McCormick < ***@***.***> wrote: > Suggestion: Why don't you write out LCIO from hps-java, which you can > already read into hpstr? > > Seems like maybe EVIO capability doesn't belong in hpstr (?). > > Or is the calibration code based on using the raw EVIO data? > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#43 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AA4JMXEKVBNKR57E64TOOK3RJLPHPANCNFSM4KIROW3A> > . >

[normangraf]

I agree that we could use your time and effort elsewhere right now.

________________________________ From: Omar Moreno <notifications@github.com> Sent: Wednesday, March 25, 2020 10:16 PM To: JeffersonLab/hpstr <hpstr@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [JeffersonLab/hpstr] Add 2019 SVT EVIO reader (#43) I have everything I need to do this i.e. the reader and event builder, but I just need to find the time to copy everything over. That said, this isn't something we need to worry for a few months.

On Wed, Mar 25, 2020 at 10:14 PM Omar Moreno ***@***.***> wrote: This is meant to allow the porting of calibration code. On Wed, Mar 25, 2020 at 10:07 PM Jeremy McCormick < ***@***.***> wrote: > Suggestion: Why don't you write out LCIO from hps-java, which you can > already read into hpstr? > > Seems like maybe EVIO capability doesn't belong in hpstr (?). > > Or is the calibration code based on using the raw EVIO data? > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#43 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AA4JMXEKVBNKR57E64TOOK3RJLPHPANCNFSM4KIROW3A> > . >

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#43 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADRGZDWJ56ASGYPVPUIIL7TRJLQKPANCNFSM4KIROW3A>.

[JeremyMcCormick]

I was just wondering if it might be cleaner to write out whatever you need in terms of SVT calibration data from Java as the EVIO interface is quite well-developed and easy to use there. Then you could read these files into hpstr through the existing LCIO interface without needing then to import all the EVIO C/C++ code into hpstr. Just an idea to avoid having to import more IO code into the project.

[omar-moreno]

We tried to do this before and it was a pain and really slow. Also, we also need to support reading the binary files output by rogue which doesn't make sense to do in Java.

…

On Wed, Mar 25, 2020 at 10:32 PM Jeremy McCormick ***@***.***> wrote: I was just wondering if it might be cleaner to write out whatever you need in terms of SVT calibration data from Java as the EVIO interface is quite well-developed and easy to use there. Then you could read these files into hpstr through the existing LCIO interface without needing then to import all the EVIO C/C++ code into hpstr. Just an idea to avoid having to import more IO code into the project. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JMXG3AJ7UD2I7D7YNNTTRJLSGBANCNFSM4KIROW3A> .

[normangraf]

What are you calibrating that you need the raw evio?

[omar-moreno]

The SVT.

…

On Thu, Mar 26, 2020, 12:05 PM normangraf ***@***.***> wrote: What are you calibrating that you need the raw evio? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JMXHASKP3QGEPXCQ4QJDRJOROJANCNFSM4KIROW3A> .

[omar-moreno]

This is only needed for online, so this isn't something we need to discuss now.

…

On Thu, Mar 26, 2020, 12:23 PM Omar Moreno ***@***.***> wrote: The SVT. On Thu, Mar 26, 2020, 12:05 PM normangraf ***@***.***> wrote: > What are you calibrating that you need the raw evio? > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#43 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AA4JMXHASKP3QGEPXCQ4QJDRJOROJANCNFSM4KIROW3A> > . >

[normangraf]

I see no reason why you can't make all the histograms you need in hps-java and import those into root to do your calibration. Or even just do the calibration in hps-java. Just trying to push back a bit on the hpstr mission creep. I'm fine postponing this discussion.

[omar-moreno]

Like I mentioned earlier, we tried doing this in hps-java before the 2015 run and had issues. For one, the amount of memory needed to make the histograms was massive and led to hps-java constantly freezing up and crashing whatever machine it was running on and it was a factor of 10 slower than the C code. Also, we needed to interface with the parsing libraries written in C by the DAQ group. So it makes no sense to do this in hps-java. Especially given that we usually need these calibration files generated in a matter of minutes, in the counting house. This can't be achieved using hps-java.

…

On Thu, Mar 26, 2020, 12:29 PM normangraf ***@***.***> wrote: I see no reason why you can't make all the histograms you need in hps-java and import those into root to do your calibration. Or even just do the calibration in hps-java. Just trying to push back a bit on the hpstr mission creep. I'm fine postponing this discussion. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JMXF5CCIMRA6UKISGRG3RJOUKFANCNFSM4KIROW3A> .

[normangraf]

Well, since we're not going to be running for at least a year I think this can go on the way-back-burner.

[omar-moreno]

Agreed.

…

On Thu, Mar 26, 2020, 2:41 PM normangraf ***@***.***> wrote: Well, since we're not going to be running for at least a year I think this can go on the way-back-burner. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JMXDUKYMV2SODUYE6MXDRJPDYJANCNFSM4KIROW3A> .