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

ignore checks for savenever plugins #345

Merged
merged 5 commits into from Dec 1, 2020
Merged

Conversation

JoranAngevaare
Copy link
Member

What is the problem / what does the code in this PR do
Fix #247, XENONnT/straxen#149 and prevent an implementation such as XENONnT/straxen#261.

Can you briefly describe how it works?
The inconsistency in time ranges may occur when we are loading plugins that are not saved themselves. In XENONnT/straxen#261 I proposed to solve this by making sure that all data was stored. However, @JelleAalbers pointed out that it might be actually nicer to fix this on the strax side.

Can you give a minimal working example (or illustrate with a figure)?
It took quite some trial and error to get it working. I propose to keep some of the associated Errors as Userwarnings to monitor if we are actually not making any edge case not working. I've tried whatever I could come up with but so far the data returned is exactly the same as the one I would get if we would store all the save_when.NEVER plugins (Peaks in this case).

How to replicate
I just ran the wf plot as in XENONnT/straxen#149 just until I hit this error, run the following two commands and you will see that you are now able to actually plot the wf:

# where time_range=(9343216270, 9343224420) is a time range in simulated data 
# where from I figured out that I could run into this bug
st.get_array(run_id, 'peaks', time_range=(9343216270, 9343224420)) 

Copy link
Collaborator

@WenzDaniel WenzDaniel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine, but I think we should monitor this change a bit.

@JoranAngevaare JoranAngevaare marked this pull request as draft November 5, 2020 16:10
Copy link
Member

@JelleAalbers JelleAalbers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix Joran! I can remove the item "Fix the strax time range bug, it's only peaks, so just disable exhaustion check" from my todo list :-) I didn't understand the break in the input consolidation section yet.

strax/plugin.py Outdated
raise RuntimeError(
f"Plugin {d} terminated with leftover {d}: {buffer}")
# This can happen especially in time range selections
if int(self.save_when) != strax.SaveWhen.NEVER:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, nice, I think this is the key fix. (You could move the if condition up above the for loop for clarity, since the loop doesn't need to run at all for never-save plugins)

strax/plugin.py Outdated
# for a time range that is inconsistent with the
# chunking of the inputs. See:
# https://github.com/AxFoundation/strax/issues/247
break
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this triggers even during regular processing of a run, without a time range selection. Are you sure it is harmless? Maybe I'm not understanding why this break is needed; did we get the "ten passes" error message when plotting waveforms?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this was actually the first place I started looking. This was indeed not necessary and also felt slightly out of place. Fun fact, the input times were inconsistent (not the matter here).

I removed it now.

@JoranAngevaare
Copy link
Member Author

Checkout

# https://github.com/AxFoundation/strax/pull/345 (will fix in that
when reopening

@JoranAngevaare JoranAngevaare marked this pull request as ready for review November 30, 2020 15:37
@JoranAngevaare
Copy link
Member Author

This PR has been validated in https://github.com/XENONnT/analysiscode/blob/master/StraxTests/Fix_time_for_savenever.ipynb and https://github.com/XENONnT/analysiscode/blob/master/StraxTests/Fix_time_for_savenever_validation.ipynb. I'm confident and happy that we can close this extremely long outstanding issue.

# For non-saving plugins, don't be strict, just take whatever
# endtimes are available and don't check time-consistency
if int(self.save_when) == strax.SaveWhen.NEVER:
# </start>This warning/check will be deleted, see UserWarning
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you mean in a future upcoming release?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And you will just keep the end = max([v.end ....]) part right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that is true. I just added this warning to give a handle in case we start seeing shenanigans which I highly doubt at this point due to the tests I did.

Copy link
Collaborator

@WenzDaniel WenzDaniel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine and I looked through your tests as well. It looks like you spend a lot of time in setting them up. So I was wondering, do you think it would be possible to boil down your "offending" peak tests into some unity test or similar? Maybe you have already thought about it.

@JoranAngevaare
Copy link
Member Author

JoranAngevaare commented Dec 1, 2020

Looks fine and I looked through your tests as well. It looks like you spend a lot of time in setting them up. So I was wondering, do you think it would be possible to boil down your "offending" peak tests into some unity test or similar? Maybe you have already thought about it.

Thanks, actually, this should be hard because you basically need straxen. If I'd write a test it would take a lot of time because you'd be needing to copy over the chunks and set of a similar plugin-structure as in straxen but than with much more abstraction. In the end, the test would not be flexible.

As a trade-off I can try to see if I can somehow replicate with the demo data. If this is possible I would just move the test to straxen saving myself a lot of time.

Also, thanks to taking the time to look at the tests I did.

Copy link
Member

@JelleAalbers JelleAalbers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice work!

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

Successfully merging this pull request may close these issues.

Time range selection fails if intersecting with some objects
3 participants