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

Computing the run pointing in sky coordinates #1302

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
Open

Conversation

moralejo
Copy link
Collaborator

@moralejo moralejo commented Oct 8, 2024

Addresses #1293
So far the first event's pointing was used. This is problematic for runs in which the pointing is unstable at the beginning.

So far the first event's pointing was used. This is problematic for runs in which the pointing is unstable at the beginning.
@moralejo
Copy link
Collaborator Author

moralejo commented Oct 8, 2024

Possible improvements:

  • check stability of pointing (and at least display a warning)
  • return the "first reliable event" and use it to omit the previous ones from the DL3 file?

@moralejo moralejo requested a review from juanjq October 8, 2024 08:27
Copy link

codecov bot commented Oct 8, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.50%. Comparing base (1d20811) to head (9df60c6).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1302      +/-   ##
==========================================
+ Coverage   73.48%   73.50%   +0.01%     
==========================================
  Files         134      134              
  Lines       14201    14211      +10     
==========================================
+ Hits        10436    10446      +10     
  Misses       3765     3765              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@moralejo
Copy link
Collaborator Author

moralejo commented Oct 8, 2024

I hope it is ok to do the change in docs/conf.py in this PR
That was just a deprecated option which made docs building fail.

evtwise_pnt_icrs = SkyCoord(
alt=pointing_alt[first_event:],
az=pointing_az[first_event:],
frame=AltAz(obstime=time_utc[first_event:], location=LST1_LOCATION),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Per astropy docs for AltAz, the optional parameter pressure defaults to 0, effectively turning off the refraction. This will give about 300 arcsec bias in the transformation.

Copy link
Member

Choose a reason for hiding this comment

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

Not for Cherenkov light produced in 10 to 20 km height

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Here we want to know where the gamma-ray source "really is", ¿right?, rather than where its optical image (if any) would appear on the camera. Any bias in g-ray direction reconstruction related to refraction must be addressed via simulations (i.e. by training algorithms with MC which implements C-light refraction) .

This said, I had not even thought about that... so good that you ask (and good that the default is P=0)

@moralejo moralejo marked this pull request as ready for review October 8, 2024 12:58
@moralejo
Copy link
Collaborator Author

moralejo commented Oct 8, 2024

I hope it is ok to do the change in docs/conf.py in this PR That was just a deprecated option which made docs building fail.

Done now in #1303

@morcuended
Copy link
Member

morcuended commented Oct 8, 2024

Something is not okay with the downloading of the test dataset in the CI. It's taking too long

@moralejo
Copy link
Collaborator Author

moralejo commented Oct 9, 2024

One unrelated test failed. Trying to fix it in #1307 #1300

lstchain/high_level/hdu_table.py Outdated Show resolved Hide resolved
lstchain/high_level/hdu_table.py Outdated Show resolved Hide resolved
lstchain/high_level/hdu_table.py Outdated Show resolved Hide resolved
lstchain/high_level/hdu_table.py Show resolved Hide resolved
moralejo and others added 3 commits October 10, 2024 17:22
Co-authored-by: Daniel Morcuende <dmorcuende@iaa.es>
Co-authored-by: Daniel Morcuende <dmorcuende@iaa.es>
Co-authored-by: Daniel Morcuende <dmorcuende@iaa.es>
morcuended
morcuended previously approved these changes Oct 11, 2024
Copy link
Member

@morcuended morcuended left a comment

Choose a reason for hiding this comment

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

Looks good to me

median_angle_wrt_mean_pointing = np.median(pnt_icrs.separation(evtwise_pnt_icrs))
median_angle_wrt_mean_pointing_2 = np.median(pnt_icrs.separation(evtwise_pnt_icrs[first_event:]))

log.info("Median of angle between pointing direction and mean pointing:")
Copy link
Member

Choose a reason for hiding this comment

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

This compares the median over all events to the median over the events without the ones excluded by "fraction".

Is this really what we want? Normal runs are long (~20 min) and the unstable pointing we saw was for the first ~35 seconds in the bad cases.

So the median won't be affected by the the first 35 seconds of unstable pointing and then stable pointing.

We looked at the deviation of the individual pointings from the "good pointing" in chunks of 2 seconds.

Copy link
Collaborator

Choose a reason for hiding this comment

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

If we want to detect unstable outlier values at the beginning, why don't we just use a sigma clipping routine from scipy or astropy?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This compares the median over all events to the median over the events without the ones excluded by "fraction".

Is this really what we want? Normal runs are long (~20 min) and the unstable pointing we saw was for the first ~35 seconds in the bad cases.

So the median won't be affected by the the first 35 seconds of unstable pointing and then stable pointing.

We looked at the deviation of the individual pointings from the "good pointing" in chunks of 2 seconds.

Right, this will not be sensitive to the instabilities if they are so small... Perhaps it makes more sense to simply write out in the log what fraction of the run has a pointing beyond, say, 0.05 deg of the target. But I do not know where it would make sense to set a threshold for a warning.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If we want to detect unstable outlier values at the beginning, why don't we just use a sigma clipping routine from scipy or astropy?

For simplicity, we know the problem occurs only at the beginning of the run. At least the problem we are addressing in this PR. And sigma clipping requires some settings, not obvious to me which ones would be adequate here.

morcuended
morcuended previously approved these changes Oct 18, 2024
Copy link
Member

@morcuended morcuended left a comment

Choose a reason for hiding this comment

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

It looks good to me as it is. Just stress @maxnoe comment #1293 (comment):

Maybe we should identify the time range of this unstable pointing and exclude it via the GTI.

So in the long run we want to exclude completely from the analysis those first seconds of the runs via GTI definitions (if there is unstable pointing)

@moralejo moralejo requested a review from maxnoe October 18, 2024 12:05
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.

4 participants