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

Hillas calculation failed for some telescopes in camera-frame #2062

Closed
TjarkMiener opened this issue Sep 5, 2022 · 3 comments
Closed

Hillas calculation failed for some telescopes in camera-frame #2062

TjarkMiener opened this issue Sep 5, 2022 · 3 comments
Labels

Comments

@TjarkMiener
Copy link
Member

Describe the bug
I'm using the latest ctapipe version (v0.16.0) with a subsample of Prod5b. When running the process tool, the Hillas calculation failed (either zeros or nan) for some telescopes in camera-frame.

To Reproduce
Steps to reproduce the behavior:

  1. $ ctapipe-process -i /data3/users/nieto/Prod5b_sample/Prod5b_LaPalma_AdvancedBaseline_NSB1x_gamma_North_20deg_DL0_1e6evt/gamma_20deg_0deg_run126___cta-prod5b-lapalma_desert-2158m-LaPalma-dark.simtel.zst --progress --write-images --write-parameters --write-showers --camera-frame

Expected behavior
Hillas calculation should be also working when camera-frame is selected.

Supporting information
Screenshot with corrupted tables for tel 3 (LST) and tel 6 (MST with NectarCam):
Screenshot from 2022-09-05 11-56-20
Provenance log:
ctapipe-process.provenance.log

Additional context
It would be also great to store the information about the camera-frame in the meta data and just keep one naming convention for the parameter tables, i.e. removing the prefix "camera_frame_"

@TjarkMiener TjarkMiener added the bug label Sep 5, 2022
@maxnoe
Copy link
Member

maxnoe commented Sep 8, 2022

I suspect the problem is that for these telescopes the first event is not reconstructible, we then provide the wrong default container and that messes up all following events.

Let me check

@maxnoe
Copy link
Member

maxnoe commented Sep 8, 2022

Yes, this is the case. We return the global DEFAULT_IMAGE_PARAMETERS, which always contains the telescope_frame variant.

I'd solve this by just going ahead and removing the --camera-frame option to be honest and not add further complication for something we do not intend to support anymore.

@maxnoe
Copy link
Member

maxnoe commented Sep 8, 2022

On the other hand, the fix wasn't too hard...

@maxnoe maxnoe closed this as completed in b377c00 Sep 8, 2022
maxnoe added a commit that referenced this issue Sep 8, 2022
Fix wrong container used for camera frame in ImageProcessor, fixes #2062
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants