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

add_noise, get_drift_time, getA functions #8

Open
Luapulu opened this issue Oct 21, 2020 · 9 comments
Open

add_noise, get_drift_time, getA functions #8

Luapulu opened this issue Oct 21, 2020 · 9 comments

Comments

@Luapulu
Copy link

Luapulu commented Oct 21, 2020

I have code for the following functions that may be worth merging in here (or perhaps in the legend DSP package)

add_noise

given some vector of noise and a signal, add noise to the signal. By default noise will be added starting at a random index in the noise vector. When the end of the noise vector is reached, it will wrap around to the start of the noise vector and keep adding until all of the signal has had noise added to it.

get_drift_time

get drift time of a signal, using a low and high threshold. I can also add relative thresholds, but haven't yet.

getA

gets the A value for A/E calculations form a signal. A two argument form also takes a time step, so that the maximum derivative of a signal is given, rather than the maximum difference.

Let me know if you're interested.

@oschulz
Copy link
Member

oschulz commented Oct 21, 2020

I actually have a major rewrite on this package pending, so I would like hold on it for a few weeks. But in general, such functions would certainly fit in here.

@hervasa2
Copy link

hervasa2 commented Jun 30, 2023

I have an allocation free getA function which takes ~5us per waveform that I have been using. It is based on a linear least squares fit performed on each sample using a window of samples around it. A related function returns the current pulse using 2 allocations and a similar computation time. @oschulz let me know if I push it.

@oschulz
Copy link
Member

oschulz commented Jun 30, 2023

Regarding fitting, we have signalstats() now - pretty fast, but not GPU-compatible yet (in the works). For amplitudes, we have SignalEstimator now, that one should be GPU-compatible already (may need more testing). Could you compare those with your routines, and see if we can speed things up even more?

@hervasa2
Copy link

Regarding fitting, we have signalstats() now - pretty fast, but not GPU-compatible yet (in the works). For amplitudes, we have SignalEstimator now, that one should be GPU-compatible already (may need more testing). Could you compare those with your routines, and see if we can speed things up even more?

Signal estimator would require the current pulse as input, correct? What I have is a function which returns the current pulse, taking the charge pulse as input using similar fitting methods as signal stats. As far as I see there is no function which does this, or am I wrong?

@oschulz
Copy link
Member

oschulz commented Jul 1, 2023

Currently, we turn the charge pulse into current pulses by first applying a differentiating SG-filter and then we use the SignalEstimator to perform a smoothed pick-off. This works on many traces in parallel, backed in memory by single flat matrices, so there's only a very limted number of memory allocations. I'm hesitant to used specialized code for things we can achieve by composing functionality, so we can maintain a smaller code-base. Everything will (relatively soon) by fully GPU-enabled, so the main throughput limitation will be network and memory I/O speed.

@oschulz
Copy link
Member

oschulz commented Jul 1, 2023

Can you do a benchmark comparison on, say 10000 pulses with Float32-samples?

@hervasa2
Copy link

hervasa2 commented Jul 1, 2023

Mine is about 4 times faster with the same allocations. But that's expected given that essentially it's just a specialized instance of SG-filter (SavitzkyGolayFilter(n,1,1)) which uses a recursive analytical solution for speed. See the results below. Is this increase of speed worth the increase in code base?

Side question, how is the time where the smoothed pick-off is done calculated?

Screen Shot 2023-07-01 at 11 23 46 AM

@oschulz
Copy link
Member

oschulz commented Jul 2, 2023

Is this increase of speed worth the increase in code base?

Probably not - we're probably not at the limit of what we can do with SavitzkyGolayFilter speed-wise yet. Also, I have a new CPU/GPU kernel in the works for things like linear fits over a window.

how is the time where the smoothed pick-off is done calculated?

I'll let @theHenks answer that. :-)

@theHenks
Copy link
Contributor

@hervasa2 What do you mean with the pick-off exactly? At the moment I am refactoring the LEGEND DSP stuff which was so far organized in scripts. But I can provide you the code for this.

Just to add this here: There was a recent discussion going on what is the optimal way of extraction for the A value in the PSD analysis. Maybe if we should also run our own tests first and then see if we not wanna change something.

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

No branches or pull requests

4 participants