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

Brainstorm: More robust peak splitting #933

Open
FaroutYLq opened this issue Nov 22, 2024 · 0 comments
Open

Brainstorm: More robust peak splitting #933

FaroutYLq opened this issue Nov 22, 2024 · 0 comments
Labels
question Further information is requested

Comments

@FaroutYLq
Copy link
Collaborator

FaroutYLq commented Nov 22, 2024

Non-deterministic behavior in peak splitting we once observed on OSG (with Microarch >= "x86_64-v3" already applied) has been a huge problem. So far in the examples we have, we see that max_goodness_of_split is not deterministic even for the very same peaklets, with uncertainty at <1E-3. That means, the peaklets with timestamp close to splitting threshold on different machine might be split in different ways.

In terms of the most scary part, I refer to here. It is wrapped by @numba.njit(nogil=True, cache=True), and I am not sure what performance might be trickily machine-dependent here.

Some quick thoughts:

  • Of course, the best we can do is to understand all the risk numba introduced in a bottom up way there.
  • If we cannot figure out, another thing we can try is to round max_goodness_of_split on purpose to 1% precision, which will eat up all the hypothetical machine-induced fluctuation. Assume the machine-induced fluctuation is indeed <0.1%, a 1% rounding will not change physics in any significant level, and will bring ~deterministic robustness to us.
@FaroutYLq FaroutYLq added the question Further information is requested label Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant