This is a tough event, only 17 degrees up in the south at Az 159. The target star is quite close to another 12th magnitude star so may need a special aperture in PyMovie, too. The dip is 0.5 magnitudes, so integration will be necessary to get a steady image.
|
|
|
Fog covered Santa Cruz, up to the upper entrance to UCSC and above. But the upper Meadow was clear and dry. I set up there, and spent the night getting Erida and then trying Tiburcio, and in between got some footage on the planets, and trying to get all 5 nake eye planets on one fish-eye lens. The Erida occultation was made more difficult by being so close to another star that I needed to include.
My first attempt at PyMovie/PyOTE did not yield a red bar to the right of the black bar. I used just one tracking star, and a smaller aperture as per usual. And, the aperture danced between full sized and then small to enclose the more focused image. I wanted it instead to remain circular full sized for the entire light curve and so I changed the aperture to static and larger to enclose all the two stars and the asteroid. That worked to give a significant event...
For PyMovie, I used the vertical noise median filter, the largest setting on the aperture default (must do this before you start analyzing, in "preferences"). I used two tracking stars on opposite sides of the frame for more precise tracking.
PyMovie screen capture. I used two tracking stars on opposite sides of the field, and I set the aperture large enough to include the dim star just above/right of the target+asteroid. The asteroid was already brighter than the target, and adding this second star made the dip even smaller. |
The composite of the two tracking stars, and the target (red). No "sky" was included. |
The PyMovie light curve for the target. the occultation is the dip near middle. |
 |
PyOTE analysis
The second analysis, with the 2 tracking stars, the wider static aperture on target, succeeded in finding the event. The first attempt the R was clear, but the D was muddy and failed significance. In the light curve at right, changing these parameters got a cleaner "D" and a duration at ~maximum predicted. |
The vertical marker is at the predicted time of the occultation. |
PyOTE reductions for the time and errors. Wide error bars because of low signal, but the event lasted the full predicted duration and a few tenths more, so it was enough signal to pass the '0% chance of a false positive' test. |
report sent 6/26/22
=================================================================================
July 17, 2022
At the request of Dave Herald, I've re-looked at this event. Dave Gault is re-analyzing my video, and I've done a re-analaysis as well. I used two mid-brightness tracking stars to try and improve tracking, I used the default aperture sizes which now includes the target, the 13.5 mag star immediately to its right, and also a 13.9 star immediately right of that, and of course the asteroid itself. The predicted drop in brightness is now 0.2. I also used one of the tracking stars as a reference star, as Dave Herald did. The new PyOTE result is for still a 0.2 drop at the predicted time, and 7.5 sec duration, with 3.7 sec 2-sigma error bar on that duration.... but the light is noisier and fails the "0% chance of false positive" test. I'm sending them to Dave G and Dave H and they will decide whether this is to be included in astrometry.
For the record, I'll say that Bob Anderson who wrote PyMovie and PyOTE, has said he never intended this very high 0.0000% chance of false positive to be used as the include / exclude criterion for making use of asteroid occultation data for science purposes. It was an indicator, that's all. As a scientist myself, I consider it rather ridiculous to use it for this purpose. The value of observations in improving the orbit of an asteroid and other purposes, should take precedence. The value LOST by excluding such an observation, vs. the value gained by not degrading the astrometry by the tiny chance the observation was actually a miss or null. And additionally; clearly, proper odds of a "false positive" really should take into account whether the event was close to the predicted time, the error bars on the original predictions, the RUWE value, the depth of the event, and the duration of the event. If these other values for the observed event are all consistent with the predictions and the event by eye seems rather clearly to be there, although there's a tiny chance it's random noise, then the odds are high it's real and the value weighs that it should be included in later science. It's not a matter of getting "return on invested time/effort", it is a question of the scientific value. We're not deciding "guilty beyond a reasonable doubt" with lives at stake. We're deciding, here, whether it is of more value to refine the orbit of Erida with the astrometric position of this GAIA target star, for improving future predictions of events by Erida which may be of brighter stars that can therefore provide enhanced science on Erida (shape, for example)... or not. Risk/reward needs to be considered. So, if the purported event was quite far from the predicted time or well outside the predicted shadow and the event was shallow, that would be sufficient in my eyes to exclude it from future science, even if it nominally passed the "O chance of false positive" test but only just. The risk of ruining a good orbit by one quite deviant position is too high. The risk of including an event such as my Erida observations, are clearly ~0. It won't change the orbital determination to any significant degree; it's consistent with the existing orbit.
 |
 |
 |
 |
 |
PyOTE analysis. This time, I used the tracking star as reference, with 32 point smoothing.
 |
 |
 |
July 19
My noisy light curve was about what Dave Gault got using PyMovie and PyOTE, and including the 3 stars. A re-analysis using Tangra and AOTA by Dave Herald has cleaned up the light curve and gotten good agreement with the predicted depth and duration, and confidence it was indeed an event. The problem with using PyMovie in standard mode in this situation is that the 3 tight stars including the target, were roughly linear in direction and not at all circular, and so the surrounding "sky" torus for sky-subtraction can include scattered star light which should instead have been in the star count. This actually makes for significantly WORSE the scatter errors, since you're not adding noise in quadrature from other stars, you're literally amplifying noise since you're subtracting sky counts that should instead have been added as star counts. The solution is to NOT use a sky subtraction. Your photometry will not be that of the stars, in this case, but all we're trying to do is determine if there was an event and a clean D and R, and for this, the procedure is the right one, and that's what Dave Herald did in his analysis with Tangra and AOTA. Here's DH's comments...
That of the crowded group of stars around the target. My magnitude calculations for the two non-occulted stars + asteroid (@ 13.39) is a magnitude of 12.12. Add in the target at 14.01, and the total mag is 11.94. So the mag drop is 0.18 mag, or to 85% of full light level
The light curve that DaveG got is very noisy. Similar to that from Richard’s csv file he sent previously |
I reprocessed using aperture photometry mean background, and a large background aperture (500 pixels). The putative event seems more likely. |
I then reprocessed using Background mode, above. Not much difference... |
I then tried Optimal Extraction photometry, which makes things worse. |
Noting that the stars were faint, I then tried plotting the signal – with no background subtraction. The resulting light curve with Optimal Extraction is above. |
and with straight aperture photometry is above. In these last two plots the event is (in my opinion) quite clear. Sudden drop, flat bottom, sudden rise. Unique in the light curve, and consistent as between two different measurement methodologies (aperture vs Optimal extraction). It seems to me that this is an instance where the noise added via the background subtraction has only served to degrade the quality of the light curve
|
When I run it through AOTA I get event times (corrected for camera delays for a Watec 910 camera) of 6 41 37.7 ±0.9, and 6 41 42.7 ±1.5; a 5 second duration, which seems reasonable. Subject to anything DaveG may suggest, I’m now happy with this event. By not doing a background subtraction we get a very clean light curve with the appropriate magnitude drop. |
A final comment on this situation. We have traditionally applied background subtraction, as that is the normal way of doing aperture photometry. The rational for doing this is to match the vertical scale of a light curve to stellar magnitudes – as in variable star photometry. However our primary interest is in the horizontal scale, not vertical scale. In that context, background subtraction is not needed. And sometimes (I’ve seen it more than occasionally) the noise added by undertaking the background subtraction seriously degrades the signal. [In this regard, I need to do something in AOTA so that it can better handle signal-only light curves – by providing a means to subtract a fixed amount from all values] - Dave Herald
July 31
I updated my IOTA report to reflect DH's timings and his 2-sigma timing accuracy.
 |
