This event is high rank and getting decently inside the path has very high confidence of a hit. Santa Cruz is inside the path, but not by much. Unfortunately, Karl, Kirk and I all fall pretty much on top of the same tracks. I'd suggest Karl observe from home, and Kirk and I drive south to Aptos and observe from separate places. My initial thought is - if Kirk carpools with me, I set him at Cabrillo Observatory and I continue south to Mar Monte.
|
|
Skies had cirrus during the afternoon, but cleared quite well by occultation time. Kirk carpooled with me, I placed him at Cabrillo Observatory, as Karl was going to anchor the northern limit from home. We crawled in rush hour traffic, but got there in plenty of time.
Nolthenius Data: PyOTE log file
I drove south to Mar Monte Rd. The -11 sun angle wasn't near the trouble I thought it might be. It helped that the target was in the middle of Auriga, 52 degrees up in the NE, away from the sun. At 4x the target was tough, but at 8x it was solid and easy to see and that's what I used on my Watec 910hx/RC, given the long 9s max duration. I made a couple of dumb errors, suitable for late night chart-making and then a rushed pulling stuff together out of the apartment. I transposed the RA min/sec between the two charts above. Only the LCD chart (square) was correct. I did have trouble ID'ing the field, and just before I was about to recheck the coords on the two charts (not the first time I've done this), Kirk called my iPhone which I'd fortunately placed right next to my set up, and informed me quickly about this error, still 12 minutes before the event, and enough time for me to recover and get on target. I called Karl and informed him of this error, but Karl was not realizing how close he was to the event, I relayed info quickly, reminding him that the event now was only 3-4 minutes away, and hung up. He was not able to find the target until after the event. A combination of troubles, too, as the first 2-star align was using Betelguese and Capella, which the 8SE scope did not accept. Perhaps the two stars were too close to give a firm solution to the orientation matrix. In the twilight, we were pretty much limited to 1st magnitude stars, and there were none I could see in the west, although I squinted hard to try to find Deneb and failed, deciding instead on Rigel; Capella and Rigel were my two align stars, and it succeeded. Same for Kirk.
I used a fixed 5.3 pixel static aperture for the target, and two tracking stars. The target remained well inside the ring throughout the event. I did an extended taping, realizing the possibility of seeing small moons given the unusually slow asteroid motion. I did a full 6 minutes of taping.
Screen Capture of the PyMovie settings. |
I taped for 6 full minutes, since the data quality was so good, I figured I'd be able to see a moon even if it was only 1/10 the diameter of the primary. No satellite seen. But see Kirk's data later... I commented during the taping, as I looked up after the event, that a thin cirrus band was going over the target are. The tracking#1 star shows this. |
PyMovie raw data on the target star. The ratty area on the right side is when a thin cirrus cloud covered. You can see it in all stars on the image at left. |
Histogram of Monte Carlo simulations, showing the main occultation satisfies the no false-positive test. |
Because of the cirrus, I thought it best to use the tracking star (unsaturated, not the brighter saturated stars) as a reference, suitably smoothed. There's a dip at 2:20:47.1 which would line up with Kirk's possible moonlet, but it's so short as to be of normal photometric noise. I will try to do a multi-aperture re-look and post that later. From calculations, if Kirk's moonlet was near-central, it's unlikely the shadow extended quite down to my side. My observations don't shed, at this point, any yea or nay on Kirk's. |
Duration 10.0 seconds, surprisingly long for a predicted maximum duration of 8.9 seconds and I was rather close to the northern limit of a high-rank event. |
 |
 |
A snapshot with my PowerShot camera of the external monitor, with the 13.1 magnitude target labelled. |
My setup, badly underexposed - yes. |
Using camera flash. |
Kirk set up at Cabrillo Observatory, checking the altitude of the target on his iPhone app before full deployment. He noted my transposed charts' RA coordinates and was thoughtful enough to phone me, 13 minutes ahead of the event, which sped up my recovery. Thanks! I then called Karl.
Kirk recorded at 4x on his Watec 910hx/rc
Kirk is using an iPhone app for checking the position of the target star at time of event, to make sure it clears the local trees. |
Looks good, onward with setup... |
2 tracking stars, target (gold), sky (blue). |
Zoomed in on the occultation, taking up most of the duration of this record (about 10 seconds of light curve here). |
About 40 seconds after the main event, there's a possible secondary occultation in Kirk's record. |
A brush of equipment (?) resulting in a video interuption (gap) of all data happened shortly before the occultation, and was trimmed out of this record above. PyMovie raw data, of the target, with the possible moonlet shown. |
No chance of a false positive on the main event. |
The possible moonlet event is at center; Pyote does find it, and it has the same correct magnitude dip as the primary. |
The primary event was 7.6 sec for Kirk, vs. 10.0 s for me, about 5 miles down the road. That suggests a small north shift. |
The possible secondary occultation is above. Central time for the purported moonlet occultation is 2:20:47.1 UT. About 1 second long. By clipping out the main asteroid occultation, the true noise statistics relevant for finding the secondary event allow PyOTE to find it.. |
Zoomed in. |
The red bar is the actual number of Monte Carlo simulation trials which gave a dip of sufficient length and dip which corresponds to what was observed. 99.9% of trials do not produce such a dip nor one of greater significance. However, the black bar corresponds to not even one trial in 50,000 would give such a dip. The policy of the auditors is to reject any event which has even 1 chance in 50,000 of being a false positive. This is far too harsh a rejection standard, as you've heard me argue in the past. This event, I'd argue, is clearly enough to at least warrant a note in future predictions to study light curves for a possible moonlet of 1/10 diameter or bigger, of the primary. We were fortunate this asteroid was moving slowly enough that such a small asteroid moon would still be time-resolved. |
Kirk's set up, near event time. You can see very thin cirrus in the area. Light curves for events were calibrated by using the tracking stars, for both of us. |
And towards the twilight sky |
Our main event observations are consistent with a slightly larger asteroid of perhaps 12% bigger than predicted, and on path. I was 0.12 nominal predicted diameters south of Kirk. Further analysis of the light curves for this possible "moonlet" continues...
Jan 27: Kirk re-did photometry using LiMovie and the secondary event and general data is noisier and not so visually evident... On the IOTA submission, he wrote: "Possible second event at 02:20:46.5736 – 02:20:47.9083 (1.3 sec.), PyOTE gives .00086 false probability, currently investigating.". My thought - interesting that LiMovie would give noisier reduction. The sky-subtraction done in PyMovie is more sophisticated in guarding against noise, according to Tony George. That may have improved the reduction in PyMovie? What would be more interesting, then, is to average the results from a set of 5 apertures, it might improve S/N. And perhaps try "appsum" in PyOTE. I can't think of other actions which would help judge the reality of the secondary event.
Jan 28: Kirk comments on the multi-aperture data: "I made multiple pymovie runs, but in this one, the five apertures ap00 - ap04 have increasing default mask radii, 2,3.4,5, 6 pixels. From the light curves, it looks to me that If the radius is small, the noise is smaller, but it gets less light, less amplitude. If the radius is large, the amplitude is large, but it picks up more noise from the background. I found the radius with the best false positive is somewhere in the middle, usually 3-4. Too small or too large and it can't find the event. I tried appsum instead of signal, but the results are about the same. I tried normalizing one curve against another but I don't think it gets me anything. Attached are more plots zoomed in, the points from different apertures seem to be roughly on the same curve but at a different amplitude.The filenames indicate the type of graphs."
Bender re-analysis was done using all 5 PyMovie static apertures. The smallest aperture was too noisy to show the event (likely did not include all the starlight), and similar for the largest aperture (too much noise light included?). But the middle 2 apertures shown above, show the event better, and are plotted here in different colors. RN has used the pre-occultation light level to give an un-occulted baslined and a fit to the occulted level; depth of dip agrees in with the primary occultation and predictions. Possible cirrus affects the light curve at far right on these curves. |
Using only the too-big and too-small apertures still shows the secondary dip, but not quite as significant. |
All 5 apertures, this time using "appsum" in PyOTE. Meaning, no sky subtraction is done. The noise is worse, visually, than one sees in the graphs at left. And worsens the significance of the dip. |
Jan 28: A closer look finds a second glitch very short, in the middle of the main event occultation. It does not affect the D,R timings of that event, and there are no glitches around the possible moonlet event 37 seconds after the main event.
"banding" seen during the brief second glitch mid-occultation. Target star was not in any of the "frozen" bands. |
Zoomed in on the primary occultation, showing the effect of this "banding" glitch on the light levels. |
|
The target is not on one of the frozen bands. But one of the tracking stars is, so the tracking aperture freezes for about half a second, between the D and R. The other tracking star doesn't freeze, the field doesn't drift hardly at all for half a second, and the glitch happens solely between the D and R, ending before the R. So the second glitch doesn't affect the D- R timing of the main event and the time stamps are not frozen so there are no time stamp errors from pyote for this second glitch. These glitches are on the tape, occuring during the recording, not on playback or on photometric analysis on playback. They show up when the tape is played back on other camcorders.
DH and DG volunteered to look at Kirk's recording with Tangra. Here's the results, and my comments...
Dave Herald elected to use Tangra without background subtraction, and used Tangra's "Optimal" Extraction option. It By plotting the light curves as their high absolute values, yet including the 0 level on the graph, it suppresses the visibility of the occultation(s). Also, it may be that the video "freeze" events which happened before the primary event, and then a very brief episode during the occultation but before the R, affected the light curves seen here. |
Zoomed in on just the primary event. Since it takes up almost the entire length of the light curve, little can be judged relative to outside-of-event light. I don't know what aperture size he used, and whether it caused some target light to escape over the edges. |
Dave Gault looked at the tape independently using Tangra in standard aperture mode, where sky background subtraction is now done. The video glitches are clear and happen not at the D or R events. The secondary event is also seen. He used AOTA for timings, which is another timing reduction software different than Tangra, PyMovie, and PyOTE.
Tangra light curve, showing primary event and secondary event. Using aperture sky subtraction and not "optimal extraction". |
The level assignments in red are very likely affected by the video freeze that happened during the primary occultation. The glitch, as described earlier, is clearly seen by the light curves and time stamps of the tracking stars and so can be isolated from the events, by the humans involved. |
The secondary event, is also found by AOTA. No video glitches occured except the two near the primary occultation; not near the secondary event. |
I'll note that the PyMovie and Tangra w/ sky subtraction curves show the primary event clearly. It is also obvious that this primary event is seen quite similarly in both my own light curve and in Kirk's independent light curve from ~5 miles away. And, the light loss was quite consistent with the predicted loss of 1.2 magnitudes, and happened at a self-consistent time and also at the time of the prediction. The odds that this primary event was purely a noise or instrumental defect is virtually 0. Yet the Tangra "optimal extraction" light curve w/o sky subtraction, which Dave Herald elected to use, hardly shows the primary event. Noise is significantly higher in terms of S/N vs the rest of the light curve. This does not argue in favor of this choice of reduction, quite the contrary is the reasonable conclusion. When using sky subtraction, Tangra does a similar looking light curve performance as PyMovie did for Kirk and my independent reductions, arguing in its favor.
Dave Gault ran Kirk's data through Tangra using aperture photometry. The vertical scale spans 400 ADU. The Tangra aperture photometry method seems to show cleaner events than using the optimal extraction method shown at right. The total range of photometry points from top to bottom around the primary event is 300 ADU. |
Dave Gault's Tangra run using optimal extraction. The initial impression is that this data occupies a narrower band. But that's an artifact of the scaling. The vertical scale now spans 600 ADU, 50% more than the graph at left. The total range from highest to lowest photometry points around the primary event is 400 ADU, higher than the 300 ADU for the aperture photometry method at left. So, the optimal extraction method seems to add noise to the events.
|
For some reason, "optimal extraction" is sub-optimal for this event. Perhaps in part due to the video glitches? Perhaps aperture size choice in Tangra's parameters by DH? Not known. But the case for the primary event being real and established is too strong to question. If the "optimal extraction" method makes the primary event less clear, that does not support using this method here for drawing conclusions about the primary or secondary events.
This is about all that can be said for this Repsolda event. In response to DH's comments on the IOTA message board... Our purpose in spending time on these reductions is to see whether the indication of a moonlet is at least a significant possibility and therefore should be announced to the asteroid community for a watch on future events. Again, neither Kirk Bender nor I are announcing a "discovery"! Far from it. So please - do NOT attack these data or this notice as any such a claim. Clearly, many light curves along the way show noise and dips of a single point or very few point nature and which do not look out of place within the data and deserve no notice. Bender and I have seen many, and make no moonlet claims. This particular secondary dip does look out of place, and given the long duration of the primary event and the 1.33 sec duration of the secondary event at 4x setting, and the fact that PyOTE finds the event, and that it is not reproduced in ~99.7% of Monte Carlo simulations, argues this it is may well be real and other observers should be alerted to this, for their own planning. It should not be simply dismissed as noise since it is not "proved" and "certain".
There was a time when astronomers dismissed the claim of a secondary occultations, that asteroid gravity was too small and it would be too easy to unbind any moon, or that observers they were simply being too "hopeful". Time and video records and better software have shown that moons around asteroids are real. Many dozens are now known, if not over a hundred. They're extremely valuable in determining the mass, hence density and composition of asteroids and any suggestion that there may be a new moonlet discovery should be communicated to the community so that future occultations by that asteriod will get more priority from the observers. This, to me, seems to completely obvious I'm chagrined that I need to emphasize that here. We can't exclude the possibility that if the secondary occultation is real that it may be due to the primary star being a binary. If so, the depth argues that it's probably a companion star that is comparable in brightness to the primary. But if so, one would expect that the RUWE would be poor. But it's not. And the note in predictions says it's a single star. It would perhaps be worth considering if, assuming it's a binary with comparable stars, whether the star would look out of round on the SDSS chart, or at least show less in the way of sharp diffraction spikes from the mirror support. I'll take a look at that... (to be continued).
