OPSIM-1073: Modify filter scheduler (u/y swap default) and update twilight survey feasibility function #357
Conversation
| time_to_12deg : `float` | ||
| How much time must be remaining before 12 degree twilight in the morning (minutes) | ||
| time_remaining : `float` | ||
| Minimum about of time that must be available before trying to execute (minutes) |
There was a problem hiding this comment.
This feels like a confusing way to write this .. I think it's purpose is to make sure that the twilight NEO survey functions within a limited amount of time near 12 degree twilight and also happens to scale that amount of time depending on the time of year (at least for evening twilight, since that's set by sun_alt .. but it doesn't do the same for the morning twilight).
Would it make sense to recast this function in that light, as taking arguments of the minimum amount of time required, as well as a number between 0-1 that represents the fraction of the time from 12-18 degree twilight to pass as "good" to use?
The time between -12 and -18 degree twilight varies from 27 to 36 minutes over the year so some parts of the year could have more time available and some less.
There was a problem hiding this comment.
I poked around "how much time is available between -12 and -18 twilight", and also "how much time did we actually allocate to evening and twilight observations" and it's enlightening.
I think this change you're applying here will help, but there will still be some discrepancies between morning and evening twilight that probably aren't intentional.
There was a problem hiding this comment.
(histogram shows how many nights had a twilight length of X minutes .. splits between morning and evening -- the 'visits' histograms show how much time was actually used in baseline_v3.2, and the other histograms are the time between -12 and -18 twilight)
There was a problem hiding this comment.
which suggests you might go for something sort of like what I tested here - https://github.com/rhiannonlynne/notebooks/blob/main/twilight_time.ipynb
There was a problem hiding this comment.
There's an asymmetry in picking when/how to start the inner solar system observations, I'm not sure what the best way to deal with it is. At sunset, we clearly want to start the observations as soon as possible (but we can't start at too high an airmass because we need to be able to complete multiple visits before points set below the alt limit). At sunrise, we can go right to the alt limit since things are rising, so that means we want to start a sequence as late as possible.
It's all about how much margin for error we want to have, and it gets complicated because on one side that error is easy to express as an altitude-buffer and on the other side as a time-buffer.
This was the basis function used in v3.2. We can check if yours works better and put that in for v3.3.
There was a problem hiding this comment.
Yes .. tricky.
I assumed that the minimum time was being applied to sunrise because you ran out of time as the sun rose. Your description sounds like the minimum time could also be applied to sunset?
This is just a True/False for the whole sky, right? Does it make sense to also have a function which is weighting towards which airmass is chosen (I guess I had thought that would come from other places, like the footprint).
There was a problem hiding this comment.
One thing with the mix of sun altitude (for sunset) and time (for sunrise) is that it's not super easy to see how those differences are working out, as these are completely different kinds of "units", so it seems harder to maintain and interpret.
Agree that maybe the way to go is to just test both.
There was a problem hiding this comment.
Updated the notebook to actually run the SunAltitudeFeasibilityFunction as well, and I think these actually behave pretty similarly, if configured in similar sorts of ways. So maybe it just depends which one looks easier to keep.
There was a problem hiding this comment.
Having the fraction of twilight time as a kwarg might not be best. Since the amount of twilight time changes through the year sometimes it can start before it's ideal and/or not have enough time to complete a quad. There's also the potential to set it so it will silently fail to execute (e.g., max_fraction=0.1 and min_time=15.0).
There was a problem hiding this comment.
The time required to do a quad isn't really spelled out (probably should be documented somewhere or demonstrated how to calculate). The sun alt could be set to a point where quads aren't possible couldn't it?
| result = self.survey_features["n_obs_count_all"].feature / ( | ||
| self.survey_features["n_obs_count_in_filt"].feature + 1 | ||
| ) | ||
| return result |
There was a problem hiding this comment.
Just out of curiosity - this (the idea of distributing visits among filters) is also reflected in the footprint basis function, isn't it? Why is this necessary as well?
There was a problem hiding this comment.
For the twilight inner solar system survey we can't use the regular footprint basis function because we don't want to enforce spatial uniformity of the observations. We just want them on the ecliptic, we don't care if parts of the ecliptic don't happen to get observed. So the footprint basis function ends up with zero weight, it's just there as an effective mask, so it can't regulate filter distribution.
There was a problem hiding this comment.
Ah, thanks! That's a good reason.
rhiannonlynne
changed the title
yoachim
force-pushed
the
tickets/OPSIM-1073
branch
from
203951c
to
13a903c
Compare
Basis functions used by the twilight near sun survey. Also update filter schdeduler to default to u swaps with y.