Add 2019 SVT EVIO reader #43
Assignees
Labels
enhancement
New feature or request
Comments
|
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? |
|
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>
.
|
|
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>
> .
>
|
|
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>.
|
|
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. |
|
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>
.
|
|
What are you calibrating that you need the raw evio? |
|
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>
.
|
|
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>
> .
>
|
|
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. |
|
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>
.
|
|
Well, since we're not going to be running for at least a year I think this can go on the way-back-burner. |
|
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>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is needed to port over SVT calibration code.
The text was updated successfully, but these errors were encountered: