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

ServiceX auto_schema and similar column names #665

Open
alexander-held opened this issue Apr 24, 2022 · 0 comments
Open

ServiceX auto_schema and similar column names #665

alexander-held opened this issue Apr 24, 2022 · 0 comments
Labels
bug Something isn't working

Comments

@alexander-held
Copy link
Contributor

Describe the bug
I have not understood this fully. I have a setup where I compare a calculation with a pure coffea processor to a ServiceX processor, which receives data through a func_adl query. I am cutting on jet.pt. When a column with name jet_pt_uncorr is fed into the processor in addition, it seems to interfere with the jet.pt cut. I am not sure what ends up happening to that column, it is neither events.jet.pt_uncorr nor events.jet.pt.uncorr in the processor.

cc @gordonwatts

To Reproduce
See https://gist.github.com/alexander-held/7a3f3e001bca54342bfa93040bdf428a.

By default, feeding all columns to the processor:

after filter 35905

When commenting out jet_pt_uncorr": e.jet_pt_uncorr (which is not used in the processor):

after filter 36673

With USE_SERVICEX = False at the top (no ServiceX used):

after filter 36673

Expected behavior
I have not manually verified the expected count, but suspect that 36673 is correct. I see the potential ambiguity of interpreting the _ in pt_uncorr, but would expect the presence of this column to not interfere with jet.pt.

Output
see above

Desktop (please complete the following information):

  • coffea 0.7.14, UNL open data coffea-casa / UChicago coffea-casa

Additional context
n/a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant