1999 JM8 DATA REDUCTION AND ANALYSIS LOG ======================================== jm8.reduction.log Lance A. M. Benner RDF IMAGE CONVERSION -------------------- A. CBR DATA 1. Determine whether echo is in powers or sigmas 2. Check the tags: iyy imm idd rcsta ephemeris row and col 3. Convert images in powers->sigmas 4. Set up separate directory trees for CBR and GSB data. 5. If necessary, contact Mike Nolan to modify tags/data and resend. B. GSB DATA 1. similar to CBR data, but also compare with CBR for consistency. Compare echo strengths for some of the same runs on each day. ============================================================================= 1999 October 28 ============================================================================= Sent out e-mail to Stefano Mottola, Ellen Howell, Michael Hicks, and Dave Tholen & Rob Whitely to check up on their optical observations of 1999 JM8. Binzel previously replied that he would try a night on it but I don't know if he did. Mottola last mentioned three months ago that he hoped to observe JM8 spectroscopically from Chile this month. I dont' know yet whether he actually observed it. Howell got five nights of spectra at McDonald Observatory in September. She says it's reddish, so the preliminary reduction suggests that the spectra are more consistent with a C-type than with an S-type. Hicks previously reported colors suggesting a flat spectrum, possibly a C-type. He also speculated that it could be a dormant comet nucleus. He claims other inactive comet nuclei have similar colors. Hmm... I don't think we understand these objects well enough for me to believe they're inactive comets, although it's possible. Tholen has lightcurves but I don't know if he did spectroscopy. He should combine his lightcurves with the ones Pravec has assembled from Ondrejov, Hicks, and Krugly. - - - - - - - - - - - - - - - - - - - - 1999 JM8 PAPERS =============== 1. Key results from delay-Doppler imaging. Science or Nature. Benner et al. 2. Detailed results from radar imaging. Icarus. Benner et al. or Hudson et al. Include lightcurves with shape modeling. Perhaps something similar to the Castalia and Toutatis papers by Hudson et al. (1997, 1998). 3. Lightcurves. Pravec et al. If we publish the Science/Nature paper first, offer to include the shape model with the lightcurve paper. 4. Spectroscopy. Howell et al. Include POS orientation of the shape model to to illustrate any rotational variability (a la Eros). It's not clear how Ellen will handle this--whether she plans a paper on JM8 or will include it in a multi-target paper. For the radar papers, I have already outlined a detailed paper. Steve suggested I draft that first and then pare it down to a Nature/Science format. The idea is to go into more detail in a subsequent Icarus paper, as has been done with Geographos, Castalia, and Toutatis. - - - - - - - - - - - - - - - - - - - - Ellen Howell and Michael Hicks have independently claimed that JM8 is most likely a C-type (note that those results are preliminary). Pravec obtained H = 15.2, so using Deff = 3.5 km from Scott's preliminary 2nd generation shape model, which is based on the first 6 days of Goldstone observations only, here's a first-pass at the optical geometric albedo: reason:/data/ast5/1999JM8/analysis < 16 > pvd Enter the absolute magnitude: 15.2 Enter the diameter (km): 3.5 H = 15.200 d = 3.500 pv D (km) 0.119 3.500 pv = 0.12 is near the high end for C-types. Clearly this result could change when an improved 3-D model becomes available using all the radar images. The optical albedo is actually closer to S-types than to C-types. - - - - - - - - - - - - - - - - - - - - Pravec posted preliminary JM8 lightcurve results on his website at: http://sunkl.asu.cas.cz/~ppravec/99jm8.htm Pravec's best-fit period is 6.8 days or 163 hours. This is comparable to the rotation seen in the delay-Doppler images, which between July 24-August 6 was about 7-8 days. It should be noted that that estimate is based on inspection of the images and it doesn't include the effects of sky motion, which was substantial. This "period" could be the rough period about only one of the principal axes. Recall from Scott's 2nd model (6 days of Goldstone images) that he estimates rotation of 3, 19, and -29 deg/day about the principal axes. The delay-Doppler images after the first 6 obtained at Goldstone seem to imply more rapid rotation. Estimated maximum extents: 3.4, 3.7, and 5.2 km. Effective diameter ~ 3.5 km Elongation (max/intermediate axis) = 1.4 - - - - - - - - - - - - - - - - - - - - Estimate the damping timescales to principal axis rotation ========================================================== Harris (1994) gives: tau ~ (P/C)^3/Deff^2 where P is the sidereal rotation period in hours, Deff is the effective diameter in kilometers, and C is a constant that depends on the material properties of the target. Harris gives C = 17+25-10. Apply this to JM8, using Deff = 3.5 km P (d) P (h) tau (y) ----- ----- ------- 6.76 162.2 7 E10 12 288 4 E11 The nominal value, 7e10, is comparable to that estimated for Toutatis using Deff = 2.5 km and P = 130 h. ============================================================================= 1999 October 28 ======================================================================== Hicks e-mailed last night to say that he got BVRI photometry, 0.4-0.9 micron spectroscopy, 0.9-2.5 micron spectroscopy, and 8-12 micron thermal flux measurements. Thus, he may be able to do thermal modeling and provide an estimate of the effective diameter which we can calibrate using our shape model. Depending on how the shape inversion and spin vector estimation go, we may be able to provide POS orientations of the shape that show areas illuminated by the Sun. Another obvious goal is to estimate the mineralogic composition of the surface and to check for heterogeneity. I don't know when Hicks did his observations but it's possible that many were at times different from when Ellen Howell observed. Of course, there's also the photometry so it is looking as if we stand to learn a great deal about 1999 JM8. My guess is that JM8 will become one of the best-studied asteroids (NEAs or MBAs) to date. - - - - - - - - - - - - - - - - - - - - Is 1999 JM8 an inactive comet nucleus? ====================================== Hicks wants to believe that JM8 is an inactive comet nucleus based on its orbital elements and Tisserand parameter: reason:/home/lance < 5 > tisserand Enter the semimajor axis (AU): 2.734 Enter the eccentricity: 0.644 Enter the inclination: 13.69 2.734 0.644 13.690 q = 0.973 Q = 4.495 TISSERAND PARAMETERS Neptune: T = 11.444 Uranus: T = 7.581 Saturn: T = 4.285 Jupiter: T = 2.981 Mars: T = 2.549 Earth: T = 2.824 Venus: T = 3.155 Mercury: T = 4.092 JM8 has a Tisserand parameter (relative to Jupiter) that suggests a Jupiter-family comet, but as Valsecchi et al. (1995) showed, both comets and NEAs can evolve into and out of such orbits so by itself T = 2.98 isn't compelling evidence. The orbit does suggest, but not prove, that JM8 is from the outer main-belt and thus it shouldn't be a surprise if it's an optically (and perhaps radar) dark object. There are other lines of evidence that could suggest a comet: a coma, a tail, association with meteor streams and/or fireballs, and short-term orbital evolution dominated by encounters with Jupiter. It would probably behoove us to take at least a quick look at the orbital evolution beyond the close encounters that Jon Giorgini already checked. As I recall, Jon didn't find *any* encounters within 1.0 AU of Jupiter over 2000 years centered on the present. It would still be useful to plot a, e, i, and distance from Earth, Venus, and Mars and to check for temporary mean-motion and other resonances. ==> It turns out that Horizons can do this: it can output elements at specific epochs in tabular format to facilitate plotting. However, can it output distances from various solar system objects? Useful objects include Earth, the Sun, Venus, Mars, and Jupiter. Using Horizons to compute ephemerides provides the ability to output heliocentric and geocentric distances. So how do we compute the distances relative to other objects? I don't think Horizons has that ability generally available yet. ==> E-mail Jon. ======================================================================== 1999 November 2 ======================================================================== Jon replied that one can do this by selecting the viewing site. Thus, it will be necessary to run Horizons multiple times to generate the tables but it's tractable and rather quick. - - - - - - - - - - - - - - - - - - - - I've been correspondning by e-mail with Ellen Howell and Michael Hicks. We've been comparing preliminary radar results with their preliminary vis-IR-thermal IR results. Ellen wrote today that she gets Deff ~7 km and thus pv ~0.02, which I don't believe. I don't know if her Deff is computed from the radiometric measurements or whether she's just guessing. At any rate, 7 km is wrong: it's too big by a factor of 2 relative to Scott's 2nd pass shape model, which is based on the first six days of Goldstone imaging. I wouldn't be surprised if Deff using all the data increases somewhat but I doubt it will double. By "somewhat" I mean about 0.5-1.0 km. If Howell & Hicks' Deff and pv are based on radiometric measurements, which is possible because Hicks did some, then this illustrates once again how crude the thermal modeling really is. Recall that Scott and Steve found that the Mottola et al. (1997) thermal modeling of 6489 Golevka is seriously in error and that that object does not have the high optical albedo that they claimed. That result is based on Scott's shape modeling. Evidently the thermal modeling doesn't work well in some instances where the asteroid is highly angular, as is the case with Golevka. Hudson's preliminary model of JM8 suggests that object is roughly wedge-shaped, so perhaps that, plus the rotation state and the many simplistic assumptions in the thermal modeling are skewing their results. - - - - - - - - - - - - - - - - - - - - Thoughts about the delay-Doppler images ======================================= 1. The maximum delay extent in many images exceeds 5 km. I would not be surprised if Deff for the shape model increases after we include all the high resolution images (in Scott's most recent model, only the first 6 days at Goldstone were included). 2. We mentioned in the press release that there is a large concavity that does not appear to be an impact crater. If not, then what is it? How else would an NEA get a large, roughly central concavity that appears crudely circular? A. Bifurcation in the shape? There's no obvious evidence of that for JM8. B. Perhaps the feature *is* an impact crater. This could go back to what Asphaug and Greenberg have studied in recent years: large impacts on small objects. The second possibility is too intriguing to ignore: if that feature is an impact crater, it would rank among the largest known relative to an object's diameter and clearly the largest seen on a very small body. Restate that: if it's a crater, JM8 would be the smallest body known with such a large crater. This might be worth pursuing in a collaboration with Erik Asphaug after we publish the initial paper. The bigger picture: if that large feature is an impact crater, then that could be strong evidence that JM8 is not monolithic (i.e., it's a rubble pile). In a sense, JM8 is crudely reminiscent of Mathilde. We don't have any way to estimate the density of the whole object, but I will be very curious to see what the bulk surface density is from the radar albedo. Scott's preliminary modeling includes the July 24 image that has the first evidence for the concavity. The shape model doesn't show an obvious large depression, though. There are also at least three craters roughly 1 km in diameter: the two that are obvious on the Aug 1 image and a third that is prominent near the top (LE) center in the Aug 9 image. The irregular approaching limb on Aug 5 is another possible candidate that is reminiscent of depressions that Greenberg et al. (1995, 1996) proposed are impacts on Gaspra and Ida and that Asphaug et al. (1996) also suggested may be impacts on Ida. 3. Grooves on 1999 JM8 In a nutshell, I'm not convinced that I see any, but there are a few lineaments, especially in the Aug 3 and 4 images when the nearly flat surface was so prominent. We might not have enough resolution to see them even if they exist. 4. What is that arcuate feature visible on the receding trailing edge in images obtained on July 24, August 1, and August 8? Recall the July 31 image: there's a pronounced, straight feature on the receding trailing edge. Perhaps that's what we're seeing on the other days. That feature was quite reflective on July 31 so perhaps there are some relatively flat surface(s) oriented nearly orthogonal to the line of sight that were reflecting. What a complicated object! - - - - - - - - - - - - - - - - - - - - - CW REDUCTION ============ DOY 201 (July 20) ----------------- We did two runs, four hops, 1000 Hz bandwidth, 4096 point FFT using soln 17 I ran the PSD file through tkrdfreduc without calibrating it. The goal is to set and check the tags and check the individual hops for problems. irun is set correctly. The colors look OK. Tsys was set = 16.5 (ch 1), 15.2 (ch 2). The Tsys values appear to be default values--those are the ones that keep popping up during every experiment regardless of what the actual values are. I asked Robert and Joseph to fix that so we record the actual temperatures but that wasn't available during the JM8 observations. The values of Tsys that we measured at the start of the experiment were: Tsys ---- ch 1 15.93 ch 2 16.78 Unfortunately, if one uses rdftags to change Tsys, the same value get tagged onto both channels, so it's necessary to split the uncalibrated rdf file using rdfseparate, open the file with either tkpl and change Tsys, and then joint the files using the cat command. This will probably be necessary for all the cw data. Fortunately there isn't very much of it. It also turns out that the polarizations got switched.==> set OC to channel 1, not 2. We transmitted RCP and it was the colder receiver channel. It's useful to do a calibrated reduction just to check on the polarizations. Then go back and do it again. So the sense (hot/cold) of the temps needs to be switched. I changed Tsys appropriately, joined the files, and continued with the calibrated reduction (blocking into runs). That produced an error message for both runs and with both channels: Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (0.57735) setting rmsc to 0.280056 ( 0) 1.11452e+07 92.74 16.8 686.651 425 4 0.244141 69.632 0.280056 0.00324448 rnb.Calibrate() error: rmsc is not what it should be (0.408248) setting rmsc to 0.280056 ( 1) 1.11452e+07 92.72 16.8 687.229 425 4 0.244141 69.632 0.280056 0.00324012 Frankly, I don't fully understand this. ?? Let's forge ahead for now but come back to this later. file: 99201.runs.tpl My terminal (x-jun) just locked while I was moving the mouse... That was the first time today, but last week that happened multiple times on several days. It was really aggravating. Created and printed file with summed spectra: 99201.sum.tpl This is the file I was working on when the screen locked. I can load it with tkgraph but not with tkpl (it bombs). ?? There's a *prominent* ~30 sigma central dip in OC and a signficant dip in SC, but their centers are offset in Doppler. Strange... We got about 40 looks so the self noise is about 16%. Perhaps that's what we're seeing... Yeah, that's probably it: ~30sigma/160 sigma = 19%. (RTT = 94 sec on Jul 20; 4 hops, 20 sec dwells). The echo is about 2.5 Hz wide. Need to go back into tkpl to get OCxsec and SC/OC. Correction: using 3-sigma levels, the OC echo is about 12 Doppler bins wide or (11)*(0.244 Hz/bin) = 2.7 Hz. Currently: jsnr1 = 509 jsnr2 = 516 Change jsnr1 = 503 jsnr2 = 520 This brackets the echoe well T87 listing ----------- Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 2-oc 02:34:52 02:35:09 02:36:30 0.0 2.29e-03 2.08e+00 ± 6.2e-03 1.8 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 2-sc 02:34:52 02:35:09 02:36:30 0.0 2.17e-03 3.61e-01 ± 5.7e-03 1.7 0.173929 0.176737 0.171124 Summary: OCxsec = 2.1 km^2 SC/OC = 0.17 +/-0.003 Call it 0.17+/-0.01 to be safe. NOTE: REMEMBER THE RMSC REDUCTION PROBLEM! This nominal cross section is double what I got in my preliminary reduction of the DOY 199/200 data. DFREQ OC SNR ----- ------ 0.244 ~160 1.0 282 1.5 324 1.7 329 1.8 329 <== Bingo 1.9 328 2.0 314 2.5 306 3.0 292 DOY 202 (July 21) ----------------- We completed one run on DOY 202. 4 hops, 20 sec dwells, RTT = 88 sec, 1000 Hz bandwidth 4 k FFT to give 0.244 Hz resolution with the PSD file. So we should have about 19-20 looks, or self noise of ~23%. Tsys values are set as before: Ch1 = 15.2, Ch2 = 16.5 Use rdfseparate again and then switch them. reason:/data/ast5/1999JM8/proc/cw < 15 > rdfseparate -i 99202.nocal.rdf -o 99202.nocal.sep Dumping frame 1 to 99202.nocal.sep001.rdf Dumping frame 2 to 99202.nocal.sep002.rdf We measured Ch1 = 17.8 and Ch2 = 19.0 on point. reason:/data/ast5/1999JM8/proc/cw < 16 > cat 99202.nocal.sep001.rdf 99202.nocal.sep002.rdf > 99202.nocal.corrected.rdf Now run this back through the reduction: I get the same error as before: Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (0.57735) setting rmsc to 0.298142 ( 0) 1.11452e+07 83.9 17.8 675.298 425 4 0.244141 61.44 0.298142 0.00249284 We're doing something systematic that rnb.Calibrate doesn't like. Need to dig into this... perhaps ask Keith and/or Mike Thomas. file: 99202.runs.rdf Plotted the spectra: this time I got the polarizations right. Echo is about 10 bins wide or (9)*(0.244) = 2.2 Hz Echo is very strong. dfreq OC SNR ----- ------ 0.24 282 1 366 1.3 383 1.4 383 <== 1.5 381 1.6 376 1.7 374 2 343 T87 listing ----------- Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99202.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-oc 17:41:21 17:41:01 17:42:54 0.0 2.66e-03 2.44e+00 ± 6.0e-03 1.2 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99202.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-sc 17:41:21 17:41:01 17:42:54 0.0 2.49e-03 4.16e-01 ± 6.2e-03 1.5 0.170393 0.172946 0.167843 OC xsec = 0.24 km^2 SC/OC = 0.17+/-0.003 adopt 0.17+/-0.01 again. Cross section and ratio are consistent with results from the previous day. An idea: repeat the reduction using the version of tkrdfreduc on intruder. See if there is any difference in with the error message. DOY 204 (July 23) ----------------- In this case the system temps look OK. Evidently Carl entered the actual values. 2 hops, 4 k FFT, 1000 Hz bandwidth irun is fine. That problem has been solved. I did the calibrated reduction: no rmsc error messages this time. ?? However, something weird did happen with the reduction: there's a strong (> 1000 sigma) spike at the extreme negative frequency. We've seen this before but I don't know the cause. The question is whether or not it will corrupt the cross section. change jsnr1 = 1020, jsnr2 = 1035. bandwidth: 9*(0.244) = 2.2 Hz dfreq OC SNR ----- ------ 0.244 321 1.0 423 1.4 439 <== 1.5 439 1.6 436 1.7 434 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-oc 00:36:44 00:37:14 00:37:59 0.0 1.85e-03 2.03e+00 ± 4.4e-03 1.4 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-sc 00:36:44 00:37:14 00:37:59 0.0 2.01e-03 4.14e-01 ± 4.8e-03 1.4 0.203447 0.205839 0.201056 OCxsec = 2.0 km^2 SC/OC = 0.20+/-0.01 (adopting generous errors again) This ratio is statistically larger in a significant way relative to the results from the previous two days. Something systematic? It might have been the result of lower system temperatures. Or perhaps that side of the asteroid is a bit rougher. DOY 205 (July 24) ----------------- We did two runs with a 4 k FFT 1000 Hz sampling, 2 hops, using solution 21. Tsys for ch 1 is set incorrectly to 7.1 K--it should be 17.1 K. Tsys for ch 2 is fine (17.9 K). reason:/data/ast5/1999JM8/proc/cw < 23 > rdfseparate -i 99205.nocal.rdf -o 99205.nocal.sep Dumping frame 1 to 99205.nocal.sep001.rdf Dumping frame 2 to 99205.nocal.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 24 > cat 99205.nocal.sep001.rdf 99205.nocal.sep002.rdf > 99205.nocal.corrected.rdf Calibrated reduction seemed to go fine: no error messages. However, the e/m values are *very* low... near 0.02... Let's look at the individual hops. ...Actually, just from looking at the two calibrated runs it's obvious that the first one is bad. There are six hops total: the first three look bad (first run). I deleted the three bad hops. file = 99205.nocal.corrected2.rdf. Run it through again... e/m is better, especially for SC. OC still has some low values. file = 99205.runs2.rdf plot: 99205.sum.tpl dfreq OC SNR ----- ------ 0.244 397 1.0 634 1.3 643 1.4 646 1.5 646 <== 1.6 643 2.0 623 13(0.244 Hz/bin) = 3.2 Hz change jsnr1,2 from 1021,1028->1019,1034 file: 99205.runs2.rdf Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99205.runs2.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 2-oc 17:00:38 17:01:08 17:01:53 0.0 1.50e-03 2.51e+00 ± 3.8e-03 1.6 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99205.runs2.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 2-sc 17:00:38 17:01:08 17:01:53 0.0 1.57e-03 5.51e-01 ± 3.6e-03 1.3 0.21987 0.221363 0.218378 OCxsec = 2.5 km^2 SC/OC = 0.22+/-0.01 (again adopting much larger standard errors--almost 10 times larger) The ratio is 0.05 higher on July 24 than it was on July 20 & 21--a difference that is statistically significant. Perhaps we're seeing evidence of heterogeneity. Alternatively, we could be seeing systematic effects. DOY 208 (July 27) ----------------- [See additional notes with the July 28 reduction concerning the July 27 results] I fired away with a quick calibrated reduction to see what would happen. SC e/m is fine; OC e/m has some that are low. I don't understand this. Go back to an uncalibrated file to check the hops and tags. There are two runs, two hops, 0.244 Hz/bin (1000 Hz sampling & 4 k FFT) Tsys: ch1 = 15.4, ch2 = 16.5. tkpl just bombed again when I tried to load an existing template. create isn't printing. Did the daemon die? --> Deal with it tomorrow; for now, print to lexmark. Tsys should be 18.2, 19.5. reason:/data/ast5/1999JM8/proc/cw < 26 > rdfseparate -i 99208.nocal.rdf -o 99208.nocal.sep Dumping frame 1 to 99208.nocal.sep001.rdf Dumping frame 2 to 99208.nocal.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 27 > cat 99208.nocal.sep001.rdf 99208.nocal.sep002.rdf > 99208.nocal.corrected.rdf e/m is similar to the previous day's file: SC values are close to unity; OC values vary between 0.15-1.0 No error messages. It is amazing to see such strong echo power in each OC hop. Wow. May be seeing the sinx/x signature in the echo: rows 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 ---------------------------------------------------------------------------------------------------------------------------------- 1 -0.75 -0.61 2.93 1.00 2.39 12.14 4.57 26.21 95.96161.36427.13167.63188.85286.01118.90129.95 76.53 67.24 2.04 4.75 0.58 rows 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 ---------------------------------------------------------------------------------------------------------------------------------- 1 1.51 0.74 -1.10 1.10 0.30 0.04 2.36 1.55 24.14 20.83 23.27 66.46 47.33 28.88 30.45 23.51 16.92 3.71 1.85 6.41 -1.20 Top row is OC; bottom is SC. So we see echo power in about 14 bins*0.244 Hz/bin = 3.4 Hz dfreq OC SNR ----- ------ 0.244 427 1.0 505 1.5 567 1.8 571 2.0 576 2.2 579 2.3 579 <== 2.5 567 rows jsnr1 jsnr2 -------------------- 1 1021.0 1028.0 1018 1035 <== change to these values. Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 2-oc 01:33:01 01:33:20 01:34:20 0.0 7.45e-04 1.32e+00 ± 2.1e-03 1.9 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 2-sc 01:33:01 01:33:20 01:34:20 0.0 7.98e-04 2.38e-01 ± 2.3e-03 2.0 0.180003 0.181752 0.178256 Wow! OC xsec dropped by nearly a factor of two! The ratio also dropped back to close to its previous value. OC xsec = 1.3 km^2 SC/OC = 0.18+/-0.01 The OCxsec and ratio are consistent with results obtained on July 20, when the images show that a "pointed" end was at the LE. That is, the orientation of JM8 on those two days may have been similar (it's hard to tell from the images because of the SNR and resolution). One obvious question: will the OC xsec and SC/OC be similar on Aug 1 to their values on July 24? Those are two days when the images looked very similar. In retrospect, I should have done some CW observing on August 8, when the orientation was similar to those on July 24 and August 1. We certainly had enough time. I should have analyzed the CW data during the tracks. The lower OCxsec on this day could also be the result of the asteroid's orientation. The images show the pointed end toward the radar, so due to the shape, it might have been naturally "dimmer" similar to what we saw with Geographos and Bacchus at certain phases. That is consistent with the images which were weaker than I expected. Skip ahead a couple of days in light of the results above... DOY 213 (August 1) ------------------ We did two CW runs, 2 hops, 1000 Hz sampling, probably 4 k FFT. (That's what I would have instructed. I was at Arecibo that day and Steve was on the east coast.) rows tsys ------------ 1 15.1 2 15.1 3 15.1 4 15.1 5 15.1 6 15.1 rows tsys ------------ 1 16.1 2 16.1 3 16.1 4 16.1 5 16.1 6 16.1 Randy's log indicates that the temps should be ch1, ch2 = 17.7, 18.6 reason:/data/ast5/1999JM8/proc/cw < 30 > rdfseparate -i 99213.nocal.rdf -o 99213.nocal.sep Dumping frame 1 to 99213.nocal.sep001.rdf Dumping frame 2 to 99213.nocal.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 31 > cat 99213.nocal.sep001.rdf 99213.nocal.sep002.rdf > 99213.nocal.corrected.rdf Individual hops look great. e/m shows same pattern as before: SC is pretty good (close to unity); OC is highly variable between about 0.1 - 1.0 3 file: 99213.runs.rdf Second calibrated spectrum looks odd: did something go wrong? It could just be chi-square noise. change jsnr1, jsnr2 = 1010,1040. That's plenty wide. dfreq OC SNR ----- ------ 0.244 437 1.0 651 2.0 841 2.5 874 3.0 883 3.1 884 <== 3.2 883 3.5 875 21 bins(0.244 Hz/bin) = 5.1 Hz Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99213.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/08/01 2-oc 12:05:13 12:05:14 12:06:14 0.0 6.68e-04 2.12e+00 ± 2.3e-03 2.9 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99213.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/08/01 2-sc 12:05:13 12:05:14 12:06:14 0.0 6.98e-04 6.41e-01 ± 2.3e-03 2.7 0.302561 0.303706 0.301416 OC xsec = 2.1 km^2 <== recall that I got 2.5 km^2 on July 24. My guess is that we're seeing some real OC xsec variations superimposed on systematic effects that could easily be 25-35% (as we saw with 1991 CS). SC/OC = 0.30! Whoa... this is probably systematic. That's a *huge* excursion from previous values. ======================================================================== 1999 November 4 ======================================================================== Back after spending some time working on Mercury CW data...it looks like the subreflector's z-axis is off. DOY 209 (July 28) ----------------- We used the same setup as on other days: 0.244 Hz res'n, 4 k FFT, 1000 Hz sampling. We got part of 3 hops. Tsys ch1 = 15.6, ch2 = 16.7 but should be 15.9, 17.1. Not much of a difference but let's correct anyway. reason:/data/ast5/1999JM8/proc/cw < 20 > rdfseparate -i 99209.nocal.rdf -o 99209.nocal.sep Dumping frame 1 to 99209.nocal.sep001.rdf Dumping frame 2 to 99209.nocal.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 21 > cat 99209.nocal.sep001.rdf 99209.nocal.sep002.rdf > 99209.nocal.corrected.rdf Something went wrong with the reduction:I got sdev = infinity. Echo is very strong. Let's check the hops: OC looks OK... check tags: somehow the transmitter power was set = 0. That's the problem. Easy enough to fix... We had Ptx = 445 kW. That worked. This data has a very low SC/OC ratio. Something wrong with the system? T87 listing: Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-oc 17:14:17 17:14:14 17:15:14 0.0 7.44e-04 4.37e+00 ± 1.8e-03 1.4 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-sc 17:14:17 17:14:14 17:15:14 0.0 8.01e-04 5.60e-01 ± 2.6e-03 2.5 0.128067 0.128656 0.127478 This gave an unbelievably large OC xsec = 4.4 km^2. Note that the ratio is way down relative to the other days. These could be real effects on the surface, but a better guess is that there were systematic problems. One thing that has become apparent is that I should have done more CW observations-- say, even 10 runs per day on the longer tracks would have been useful. I'm checking tags used in the calibration. What about igw, the integer gate width? rows igw ------------ 116777217024.0 According to Keith's description, this is supposed to be in microseconds. If so, then it's huge: 1.2 E5 usec, which is more than one day. Is that right? The problem is that I don't know what the igw really is. I sent e-mail to Steve to ask. The Arecibo system has a parameter rigw which is the sampling rate in usec. So are they related? Unfortunately, I've never paid much attention to igw before. At any rate, the echo occupies 13 Doppler bins at echo powers exceeding 10 sigma, so B = 12(0.244 Hz/bin) = 2.9 Hz dfreq OC SNR ----- ------ 0.244 2005 <== There's a LARGE spike that is much higher than the other elements. 0.4 2567 Yow! 0.5 2071 0.6 2016 1.0 1852 1.5 1827 1.8 1892 2.0 1917 Now we're smoothing the whole spectrum, not just the spike 2.2 1924 2.3 1922 2.5 1911 The spectrum has resolution of 0.244 seconds and there are about 37 seconds of data in it. That's only 9 looks, so self noise is outrageous: ~33%. Nevertheless, the spike is much more than 1/3 larger than other spectral elements (it's more than 1000 sigma), so perhaps we were getting a glint. Compare with the image: Yes, this is plausible--there are two spikes in the spectrum, one slightly on either side of 0 Hz. The really strong one is on the negative side. There are two bright concentrations of pixels and their locations match those in the CW spectrum. So I think we got a couple of regions with a lot of surface area oriented close to normal to the line of sight and thus got whopping echoes. Neat! It also turns out that increasing the frequency resolution dropped the SNR of the spike, so it's clearly a narrow-band feature. Smoothing the frequency resolution to 0.5 Hz increased the SNR somewhat, so the width of the feature exceeds 0.24 Hz. Checking the image...the feature appears to be close to 0.5 Hz wide. Well, well, well. Note that 0.4 Hz maximizes the S/N. This is reminiscent of the spikes Dave Mitchell described in his 5-target MBA paper. This suggests that I take a closer look at the other CW data. I now wish I had obtained CW data on the few days at Goldstone when we didn't get any, especially the last two. (We could, of course, always create CW spectra from the images.) Actually, I just discovered that I was comparing the CW spectrum to images from the wrong day (Jul 27, not Jul 28). The July 28 image is the correct one. It's the image with the "twin peaks" and it's one of the four in the JPL press release. As a note, the July 27 CW spectrum *does* show two spikes that match the distribution of echo power on the LE in the images. The spikes are ~100-250 sigma stronger than adjacent Doppler bins. This raises an interesting question: some of the spikes could lead one to believe that there are central dips, when in fact what we see in the images is relatively small areas with concentrated narrow spikes of echo power. So one has to be careful about misinterpreting central dips as deficits--they might really indicate regions with surface area orthogonal to the line of sight. For July 28, there are two CW spikes and there *is* a central dip on the LE because there are two "peaks," but the spikes are so narrow that What would we have seen in the 1991 CS images? There were hints of glints in the cw data but they didn't repeat on subsequent rotations so I intentionally underinterpreted them. DOY 212 (July 31) ----------------- We did two runs with 0.244 Hz resolution. This time Ptx is set, but the gain is down by ~10%. ?? I wasn't at Goldstone to record the system temps on point, but by this time Joseph and had them back on the log file. The values tagged on the data are 1,2 = 15.3, 16.4. The log file gives Run ch1 ch2 --- --- --- 1 15.3 16.2 2 15.1 16.2 ==> Close enough. Don't change them. e/m values show the same pattern seen before. SC is better than on other days but still not as close to 1 as I'd like. We got two runs with about 80 sec of integration. That's about 19 looks, so self noise is ~ 1/sqrt(19) = 23%. There are two prominent spikes in the cw spectrum. The spectrum, minus the spikes, is asymmetric, which agrees with the delay-Doppler image. The image shows no evidence of bifurcation. Without going into the image data it's not completely obvious where the really strong peak is coming from--it's obviously on the LE. There may be a rather small, almost flat area just positive of 0 Hz that could be the source...by flat I mean there are five adjacent pixels with the same range. The resolution was 0.05 Hz, so with 0.244 Hz resolution the cw spectrum should have just about match-filtered this if that's truly the source of the feature. Let's change the filtering to check... The feature gets stronger upon smoothing to 0.4 Hz. Hmm... Maybe this is coming from a somewhat larger area. There's also a 15-sigma spike at about -4 Hz, which is about 1.5 Hz from the edge of the echo. What is it? I don't recall seeing this in other spectra nor do I see an obviou signature in the image...actually, the image doesn't go over far enough in Doppler to see it. Check the full delay-Doppler array...nothing. What I'm thinking about are possible satellites. Need to pay more attention to the other CW data--if there's a really small companion only one or two Doppler bins wide then it might easily get lost in the noise in the images due to the SNR penalty we suffer. Once again this highlights the need to look at as much of the data as possible while taking it and right afterward. Another thing I noticed is that the background removal isn't ideal--need to increase the estimated bandwidth. The baseline is coming in a bit negative. I checked the whole spectrum--not just the zoomed in view near the echo--and found that there are a number of ~10 sigma spikes, so we're still in the chisquare noise realm. The baseline *is* a couple of sigma negative. The echo is so strong that that's not enough to affect the OC xsec or SC/OC ratio. Perhaps the chi-square noise is affecting the estimated/measured rms during the reduction? One way to test that would be to compare with the CW data obtained during the first track (DOY 199-200) when we got quite a bit of CW data. dfreq SNR ----- ------ 0.244 831 0.4 1063 1.0 903 2.0 1209 2.5 1276 2.8 1294 3.0 1295 3.2 1292 3.5 1278 change jsnr1,2 = 1014,1034. That will include the sinc^2 component, but that's OK since it's dwarfed by the echo. Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99212.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/31 2-oc 17:02:54 17:03:03 17:04:03 0.0 5.66e-04 2.58e+00 ± 1.8e-03 2.6 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99212.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/31 2-sc 17:02:54 17:03:03 17:04:03 0.0 6.06e-04 5.16e-01 ± 2.1e-03 2.8 0.199825 0.200639 0.199011 There are about 17 Doppler bins with SNR > 10 sigma, so (17)*(0.244 Hz/bin) = 4.1 Hz. Glints ------ There are weaker glints in cw spectra from other days. Notably on July 21 and 23--and those glints match well with bright spots on the LE in the images. ======================================================================== 1999 November 8 ======================================================================== I spoke with Keith over the weekend about igw. He said he could dig through some notes about what values I should be getting and he reiterated that it's used in the calibration. His recollection is that typical values are about 125. When I told him the values I'd been getting he said they're clearly wrong. He also suggested I check old calibrated data to see what values we've gotten. My recollection is that I haven't been paying all that much attention to igw until recently. I seem to remember seeing large values in the past but I'll have to check to be sure. - - - - - - - - - - - - - - - - - - - - Continue with the CW reduction... return to the first track, paying particular attention to igw. I'm going to do some experiment to check the effects of igw on the cross sections. DOY 199-200 ----------- We have four PSD files from this track: file bandwidth FFT dfreq runs hops dwell PSD99199-16k.1999JM8 4000 16k 0.244 8 PSD99199-4k.1999JM8 4000 4k 0.978 PSD99199-8k.1999JM8 500 8k 0.061 11 2 30 PSD99199B-8k.1999JM8 1000 8k 0.122 3 4 20 8 runs total in the first two files. Let's start with the last file: PSD99199B-8k.1999JM8 Tsys tag values: ch1 = 15.2 ch2 = 16.5 These are obviously "default" values. According to the electronic log, Tsys was ~20, 21 K for ch1, ch2 during these three runs. I did not note Tsys in my electronic log. It was right about this time when Joseph modified the AC software to record both temperatures. Let's use the average of the temps for the three runs. reason:/data/ast5/1999JM8/proc/cw < 18 > rdfseparate -i 99199B.nocal.rdf -o 99199B.nocal.sep Dumping frame 1 to 99199B.nocal.sep001.rdf Dumping frame 2 to 99199B.nocal.sep002.rdf Average system temps: Ch1 = 20.35, ch2 = 21.23 Run through the calibration...Got some errors: (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (1) setting rmsc to 0.436436 ( 0) 1.11452e+07 97.33 21.23 653.429 425 4 0.12207 57.344 0.436436 0.00407415 rnb.Calibrate() error: rmsc is not what it should be (0.707107) setting rmsc to 0.436436 ( 1) 1.11452e+07 97.32 21.23 652.444 425 4 0.12207 57.344 0.436436 0.00407813 rnb.Calibrate() error: rmsc is not what it should be (1) setting rmsc to 0.471405 ( 2) 1.11452e+07 97.31 21.23 651.022 425 4 0.12207 49.152 0.471405 0.00441215 Again, I don't understand this. The e/m rms is closer to unity on this data than with any of the other JM8 cw data that I've looked at. Nor do I understand why rmsc is being set to the values above. --> Need to e-mail Keith. Arg... Is this related to chi-square noise? There's certainly plenty of that in each spectrum. One way to check would be to repeat the reduction with a much shorter FFT, or compare with other recent data that has lots of looks. Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99199b.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 3-oc 07:12:32 07:12:06 07:14:06 0.0 2.31e-03 1.38e+00 ± 7.6e-03 1.3 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99199b.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 3-sc 07:12:32 07:12:06 07:14:06 0.0 2.41e-03 2.03e-01 ± 7.7e-03 1.3 0.147198 0.152886 0.141519 So I get OC xsec = 1.4 km^2, SC/OC = 0.15+/-0.01 (again adopting generous errors). This is one of the smallest cross sections we have observed for JM8; only July 27 was lower or comparable. dfreq OC SNR ----- ------ 0.122 85 1.0 169 1.2 175 1.3 176 1.4 176 1.5 175 Here's the echo power at the raw 0.122 Hz resolution: rows 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 ---------------------------------------------------------------------------------------------------------------------- 1 2 -0 -0 23 38 62 85 55 64 58 51 50 47 35 16 7 1 1 -0 rows 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 ---------------------------------------------------------------------------------------------------------------------- 1 -0 -1 -1 2 5 7 8 10 9 9 12 6 6 6 2 1 1 -0 1 The echo is 13 bins wide or (12)*(0.122 Hz/bin) = 1.5 Hz, using echo power above the 7-sigma level. Hey--I just had a realization: need to set jsnr1 and 2 correctly with really strong echoes or else the normalization and radar cross section could get messed up because the background removal would be wrong. So if one did a calibrated reduction as I did and found that jsnr1 and 2 were wrong, then you could go back into the uncalibrated file, set them correctly, and then proceed. I found a bug: I changed tsys but rdftags didn't recognize the change. The header information didn't update. Integer Gate Width: DOY 200 --------------------------- Here's what I get for igw: rows igw ------------ 1 67108868096.0 2 67108868096.0 3 67108868096.0 4 67108868096.0 5 67108868096.0 6 67108868096.0 7 67108868096.0 8 67108868096.0 9 67108868096.0 10 67108868096.0 11 67108868096.0 12 67108868096.0 13 67108868096.0 14 67108868096.0 15 67108868096.0 Each row refers to a hop. Steve doesn't know if igw is used at Goldstone or not, but at Arecibo it's the sampling rate. Is igw being used with Goldstone data, as Keith believes, or not? Let's e-mail Robert Frye to ask how this is being set.==> He didn't know what igw was. It doesn't look like it's being set by the VME. Next step: check the reduction source code. Ugh. I repeated the das->rdf conversion. That uses "das2rdf" which sets the tags. Now to find the source code... I haven't found "das2rdf" yet, but I did find: reason:/dev1/rosema/release/src/das/DasFile.cc In it is the following: tags[IGW] = 1.0e6 * (das->points()/tags[DFREQ]); This seems to define igw = (1e6)*(npoints/dfreq). So, for the current file, this would give (1.0e6)*(8192)/(0.12207) = 6.71E10. <== That matches the values I got above. But why? What does it mean? How is it used? So the values of igw are being set according to their definition. It may turn out that this isn't important, but I'd like to understand what's going on. I found das2rdf.cc in the same directory as DasFile.cc, but there was no obvious information about igw. Perhaps the more important question is how is this used? Need to locate where, later in the pipeline, that igw is used. I didn't see any usage of igw in doscreen.cc, blocking.cc, or in rnb.cc. Here's something useful that I found in rnb.cc: /* ------------------------------------------------------------ C a l i b r a t e Calibration involves setting the SDEV tag correctly for each spectrum. SDEV is the kilometer square equivalent of one standard deviation of the noise power, and is calculated as: ( (rtt^4) * tsys ) SDEV = GainConst(observatory) *( ----------------) * dfreq * rmsc ( txgain*rcgain*pt) Where: GainConst(observatory) is a gain constant dependent on wavelength, the area of the telescope, unit conversions, etc. The correct values for these constants are defined in goldstone.h and arecibo.h rtt is the round trip light time in seconds to the target, assigned to the data by the tagging program that reads the value from the ephemeris. tsys is the system temperature in degrees kelvin. This is assigned by the tagging program either by reading a system log file, or by estimating the temperature from a function of antenna pointing. txgain The one way system gain of the transmitter rcgain The one way system gain of the receiver These two values are calculated by the tagging program as a function of antenna pointing and transmit and receive locations. The two values are multiplied together, divided by 10^12, and put in the GAIN tag. pt is the system transmit power, in kilowatts. This value is assigned by the tagging program from a system log. dfreq is the frequency resolution of the fft, and is assigned by the tagging program as a function of setup parameters. rmsc Is the calculated rms noise in the reduced signal spectrum before normalization. rmsc is calculated differently depending on what sort of background removal was done. In early reduction, rmsc was calculated from the number of hops averaged and the total noise power in the baseline. ( n 1 ) ^ 1/2 rmsc = ( --- * ----------- ) ( n-1 tau * dfreq ) Where n is the number of hops averaged. If polynomial background removal is used, (1 hop), then (n/(n-1)) is replaced with 1. tau is the total accumulated integration time, which is the sum of the taus of the individual input spectra. dfreq is as described above. --------------------------------------------------------------- */ I don't see any use of igw whatsoever. Is it obsolete? I did a search on the string "igw" but found nothing. Keith also includes an extensive discussion of background removal but that doesn't involve igw either. Move on to another DOY 199/200 file 99199-8k -------- This file has 0.061 Hz resolution: sampling = 500 Hz, FFT = 8192. I was going for resolution because the bandwidth was narrow. We did 11 runs to improve the chi-sq noise statistics. There were 10 good runs (first was bad and is not included in the PSD file). Unfortunately I didn't record Tsys, but the electronic log got it for OC: 16.5 K, which is also the value in the file. Tsys was stable about that value for all 10 runs. We don't have the SC tsys so use the default value of 15.2, which should be close enough. Gain = 0 for runs 1 and 4. Defaulted to 1.0. Somehow the colors didn't get set correctly--they're the same on both hops for those two runs. ==> Delete those runs in the uncalibrated file. ==> That worked, leaving 8 good runs. !! Something is wrong: the spectrum is rubbish !! There are lots of several thousand sigma spikes. All the runs are bad. That's odd because the VME real-time display looked fine. I tried reducing these data on July 30 and encountered the same problem. It may be necessary to go back to the voltages and pick a different FFT, (different file--perhaps that file is OK). I don't understand what happened. The only hint of trouble during the reduction (other than the problem I found and corrected above) are the large number of outliers. Maybe Keith's cw software has trouble with extreme chisquare noise? Recall that we got only one look/hop. I checked each hop--see the same problem. Maybe this is something wrong with the way the VME writes the data? It would be worth doing a quick test the next time we get a really strong target. I'm going to go on to the first file--the one where we changed the FFT on the fly--and then I'll come back to this one by working with the voltages. 99199-4k -------- I started the JM8 experiment with 4000 Hz sampling and a 4 k FFT. We switched the FFT on the fly during tx between the first and second runs. Evidently we created a new file with the 16 k data to avoid the reduction problems that I had with the 1999 GU3 data two months earlier. We used 4 hops with 20 second dwells, but we actually got parts of two more hops for a total of 6. I did a quick calibrated reduction--the rmsc error appeared again. The system temps are set incorrectly again: ch1,2 = 15.2, 16.5. They should be 16.0, 17.8. reason:/data/ast5/1999JM8/proc/cw < 10 > rdfseparate -i 99199-4k.nocal.rdf -o 99199-4k.nocal.sep Dumping frame 1 to 99199-4k.nocal.sep001.rdf Dumping frame 2 to 99199-4k.nocal.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 11 > cat 99199-4k.nocal.sep001.rdf 99199-4k.nocal.sep002.rdf > 99199-4k.nocal.corrected.rdf Here's the echo power: rows 510 511 512 513 514 515 516 517 518 519 520 ------------------------------------------------ 1 0 1 2 6 52 156 11 2 2 1 1 rows 510 511 512 513 514 515 516 517 518 519 520 ------------------------------------------------ 1 0 -0 0 2 5 23 1 0 0 0 -1 change jsnr1,2->510,517. Most of the echo is in two cells. Recall that dfreq = 0.98 Hz, so we didn't really resolve it in Doppler. Was the echo smearing in Doppler? It shouldn't have been--we had a really good ephemeris (15) based on a 9 year optical arc. Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99199-4k.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 1-oc 21:14:19 21:14:09 21:16:09 0.0 7.16e-03 1.64e+00 ± 1.0e-02 1.9 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99199-4k.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 1-sc 21:14:19 21:14:09 21:16:09 0.0 7.97e-03 2.43e-01 ± 1.0e-02 1.6 0.147665 0.154021 0.141321 OCxsec = 1.6 km^2, SC/OC = 0.15+/-0.01. These results are consistent with those obtained using file 99199b. Perhaps on this day the asteroid was in an "end-on" orientation relative to the line of sight. dfreq OC SNR ----- ------ 0.98 156 1.4 186 1.5 193 1.6 199 1.7 162 This change is a bit weird... 2.0 161 99199-16k --------- We got 6 runs with this setup. We recorded OC tsys but not SC (Joseph fixed that later on the same night). Use the earlier on-point values from above: ch1,2 = 16.0,17.8 K. reason:/data/ast5/1999JM8/proc/cw < 23 > rdfseparate -i 99199-16k.nocal.rdf -o 99199-16k.nocal.sep Dumping frame 1 to 99199-16k.nocal.sep001.rdf Dumping frame 2 to 99199-16k.nocal.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 24 > cat 99199-16k.nocal.sep001.rdf 99199-16k.nocal.sep002.rdf > 99199-16k.nocal.corrected.rdf I've been a bit thick: I keep using Deff = 3.5 km, P = 8 days. But the echo is wider on some days--should use Deff = 5 km. Individual hops look OK: clearly see the echo in each. Minor amounts of noise near the left edge in several hops. Got a bunch of rnb calibrate errors again due to rmsc not matching rmsm. ?? e/m per was close to unity for each hop. Throughout the reduction I have saved the rdfreduc ouput log files. I changed jsnr1,2 -> 2050,2063. There's some sincx^2 in there, but it shouldn't have much of an effect. Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99199-16k.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 8-oc 21:37:56 21:38:16 21:39:30 0.0 1.63e-03 1.73e+00 ± 3.8e-03 1.3 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99199-16k.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 8-sc 21:37:56 21:38:16 21:39:30 0.0 1.82e-03 3.56e-01 ± 4.0e-03 1.2 0.205754 0.208141 0.203369 The ratio is quite a bit higher than with the other data on this date. SCxsec went up. dfreq OC SNR ----- ------ 0.244 252 1.0 441 1.2 453 1.3 453 1.4 451 1.5 446 Here's the echo from a weighted sum of all six runs: rows20502051205220532054205520562057205820592060206120622063 ------------------------------------------------------------ 1 3 3 7 22 179 252 229 222 103 25 7 3 3 -0 rows20502051205220532054205520562057205820592060206120622063 ------------------------------------------------------------ 1 -1 2 -0 2 27 46 47 46 22 3 0 1 1 1 There are 9 bins with echo power exceeding 7 sigma, so (8)*(0.244 Hz/bin) = 2.0 Hz That's wrong: we're seeing (sinx)^2 again, so ignore the two 7-sigma points. That drops the bandwidth to 1.5 Hz. Rats... I accidentally overwrote the *runs.rdf file when I computed the weighted sum. Well, no big deal--I wasn't going to use the individual runs anyway. Can always repeat their reduction later if needed. The OCxsec results show a 20% variation over an interval of about 10 hours. JM8 rotates so slowly that there shouldn't have been that much REAL variation, so we're seeing systematic effects of about 20% (OCxsec between 1.4-1.7 km^2). >> Deal with the 0.061 Hz data tomorrow << ======================================================================== 1999 November 9 & 10 ======================================================================== Return to file 99199-8k ----------------------- There is something wrong with the PSD file, so let's work with the voltages. Here's a synopsis of how to use dofft: reason:/data/ast5/1999JM8/proc/cw < 4 > dofft -h Usage: dofft [-Flrs] [-d diam] [-p period] -f lfft -i ifile -o ofile -x prdxfile -F Flip i's and q's in voltage file -l Log ast_spec output to a file called ast_spec.log -r Fix the hop colors -s Sum all looks in each hop -d diam Diameter, in km -f lfft FFT length -i ifile Input file -o ofile Output file -p period Period, in hours -x prdxfile PRDX file Recall that this file had two hops and 500 Hz sampling. Try 1024-point FFT: reason:/data/ast5/1999JM8/proc/cw < 15 > dofft -d 3.5 -f 1024 -i VOLT99199-8k.1999JM8 -o 99199-8k.nocal.1024.rdf -p 192 -x PRDX.OUT.s15 contents of ast_spec control file: 1024, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199-8k.1999JM8 RDFOUT_1=99199-8k.nocal.1024.1_1.rdf RDFOUT_2=99199-8k.nocal.1024.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 NFS server rhyme not responding still trying NFS server rhyme ok /usr/local/bin/jurg2spec -i 99199-8k.nocal.1024.1.rdf -o 99199-8k.nocal.1024.rdf -x PRDX.OUT.s15 -p 192 -d 3.5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 394 Total SC spectra: 394 Processing data... That produced 394 raw spectra--recall there was nearly a 100 sec RTT with about 10 runs using 2 hops. Yikes. Unfortunately, Ray's software doesn't set irun correctly, so we need to figure it out and set it using rdftags. There are 10 runs. Run Spectra --- ------- 1 1- 40 2 41- 78 3 79-118 4 119-158 5 159-196 6 197-236 7 237-276 8 277-314 9 315-354 10 355-394 This is where things stood on Nov. 9 before we had problems with reason when Richard Zinar installed a patch. file: 99199-8k.nocal.1024.rdf I had just finished setting irun for the hops when I stopped. I rechecked them and they're fine. Other tags: hops alternate between 1 and 0... tsys ch1,2 = 15.2, 16.5 K as usual. 16.5 is very close to the recorded values so let's keep it. ch1 wasn't recorded but it shouldn't be off by more than about a degree, so let's keep it. I ran this file through tkrdfreduc. Output of the reduction looks OK: no errors. e/m values varied quite a bit but I think that's because the spectra had only one look/hop. calibrated file: 99199-8k.1024.rdf I'll change the name later. We have about 40 FFTs/run and there are 10 runs. Good noise statisics. dfreq = 0.5 Hz. I plotted all 10 spectra (both channels) and then aborted part way through plotting SC. That generated an error message that I forgot to save. Now I can't plot any spectra. ==> exit tkpl and restart it. The individual runs look OK, although there's a surprising amount of variability in the echo strengths--for example, the first run has an OC S/N of about 90 but the 3rd run is close to 400. So the voltage files produced usable spectra even though the PSD files have some unknown problem. I summed the spectra and removed the baseline. However, the baseline removal was wrong--it wasn't centered on zero sigma. It turns out that jsnr1 and jsnr2 weren't set correctly so with such a strong echo the removal was skewed. Go back to the file with the runs, reset jsnr1 and 2, and repeat. I made a plot of the weighted sum. Target unknown from file ./results.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 10-oc 02:14:07 00:00:00 02:15:37 0.0 2.00e-03 2.84e+00 ± 3.5e-03 1.5 Target unknown from file ./results.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 10-sc 02:14:07 00:00:00 02:15:37 0.0 2.17e-03 5.60e-01 ± 3.7e-03 1.4 0.197263 0.198598 0.195929 What's the deal? This OC xsec is much larger than what I got with the other CW data from this track. ??? The previous time I compared voltages with PSD files was with 1999 GU3 and I got consistent results. Why is the cross section so much larger with this file? I need to check the OC xsec from at least one other voltage file to see if the results are consistent. Perhaps this file is simply corrupted, or maybe there's something in the tags that I haven't noticed. Perhaps 500 Hz sampling was too slow? Alternatively, there could have been something wrong with the system. Another option: pick a different FFT and repeat the reduction with this file to see if the results are consistent. Let's try that first, using FFT=8192 as I had originally planned. reason:/data/ast5/1999JM8/proc/cw < 32 > dofft -d 3.5 -p 192 -f 8192 -i VOLT99199-8k.1999JM8 -o 99199-8k.8192.nocal.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199-8k.1999JM8 RDFOUT_1=99199-8k.8192.nocal.1_1.rdf RDFOUT_2=99199-8k.8192.nocal.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 NFS server rhyme not responding still trying NFS server rhyme ok /usr/local/bin/jurg2spec -i 99199-8k.8192.nocal.1.rdf -o 99199-8k.8192.nocal.rdf -x PRDX.OUT.s15 -p 192 -d 3.5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 31 Total SC spectra: 31 Processing data... This took quite a bit longer (8 k FFT) than it did when using a 1 k FFT. There were usually 3 spectra/run so I changed irun accordingly and ran the uncalibrated file through tkrdfreduc. I got another rmsc error with the first run. The individual calibrated spectra are badly corrupted. They resemble the results of the PSD file with lots of weird spikes in both polarizations. So there's something wrong with this combination of sampling rate and FFT. How can we tell while observing? Imagine that this had been the only cw data that we got--we could have seriously mislead ourselves. What if the settings on Deff somehow skewed the noise removal...? Let's do a quick repeat of the last FFT but with a larger Deff of about 5 km. reason:/data/ast5/1999JM8/proc/cw < 3 > dofft -d 5.0 -p 192 -f 8192 -i VOLT99199-8k.1999JM8 -o 99199-8k.8192b.nocal.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199-8k.1999JM8 RDFOUT_1=99199-8k.8192b.nocal.1_1.rdf RDFOUT_2=99199-8k.8192b.nocal.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199-8k.8192b.nocal.1.rdf -o 99199-8k.8192b.nocal.rdf -x PRDX.OUT.s15 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 31 Total SC spectra: 31 Processing data... I reset irun again and ran it through tkrdfreduc ==> same result as before. Let's try again with an intermediate FFT of 4096: ======================================================================== 1999 November 11 ======================================================================== Note: I have not been plotting the noise statistics for the CW data thus far in the JM8 reduction. I know that many of the spectra from the PSD files have a rather small number of looks so there will be chi-square noise. I'll go back to this shortly to check. - - - - - - - - - - - - - - - - - - - - Continuing with the 4096-point FFT: reason:/data/ast5/1999JM8/proc/cw < 39 > dofft -d 3.5 -p 192 -f 4096 -i VOLT99199-8k.1999JM8 -o 99199-8k.nocal.4096.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 4096, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199-8k.1999JM8 RDFOUT_1=99199-8k.nocal.4096.1_1.rdf RDFOUT_2=99199-8k.nocal.4096.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199-8k.nocal.4096.1.rdf -o 99199-8k.nocal.4096.rdf -x PRDX.OUT.s15 -p 192 -d 3.5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 88 Total SC spectra: 88 Processing data... Leave Tsys values alone... change irun tags appropriately... file: 99199-8k.nocal.4096.rdf I ran this through tkrdfreduc. No errors. OC e/m values varied by a factor of several; SC values were closer to unity. Here's an example of the final tkrdfreduc output for the SC channel: rnb.Calibrate(): xmit_sta is DSS14 Default value used Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev ( 0) 1.11452e+07 98.6 16.5 673.694 425 2 0.12207 81.92 0.57735 0.00427794 ( 1) 1.11452e+07 98.58 16.5 674.473 425 2 0.12207 65.536 0.447214 0.00330797 ( 2) 1.11452e+07 98.57 16.5 675.069 425 2 0.12207 73.728 0.447214 0.00330331 ( 3) 1.11452e+07 98.56 16.5 675.688 425 2 0.12207 73.728 0.57735 0.00425839 ( 4) 1.11452e+07 98.54 16.5 676.537 425 2 0.12207 65.536 0.447214 0.00329256 ( 5) 1.11452e+07 98.53 16.5 677.178 425 2 0.12207 73.728 0.447214 0.00328772 ( 6) 1.11452e+07 98.52 16.5 677.842 425 2 0.12207 73.728 0.57735 0.00423802 ( 7) 1.11452e+07 98.5 16.5 678.758 425 2 0.12207 65.536 0.447214 0.00327651 ( 8) 1.11452e+07 98.49 16.5 679.443 425 2 0.12207 73.728 0.447214 0.00327149 ( 9) 1.11452e+07 98.48 16.5 680.15 425 2 0.12207 73.728 0.57735 0.00421684 output file, blocked into runs: 99199-8k.4096.rdf I got much better looking spectra for each run, but the drastic difference in SNR in runs 3 and 8 relative to the others still stands out. So these spectra aren't full of gibberish but they do have plenty of chi-square noise since there are only 8-10 looks/run. One obvious question: are those spikes real? On two of the spectra they are at the several hundred sigma level. jsnr1 and 2 were off--only the negative echo edge was in the window. Change jsnr1,2 = 1032,1046. Means the baseline removal might have been off...actually, it looks pretty good. Here's a t87 listing for each run: Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.4096.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-oc 01:44:05 00:00:00 01:45:35 0.0 3.94e-03 1.84e+00 ± 1.2e-02 1.1 2 1 1999/07/19 2-oc 01:47:40 00:00:00 01:48:58 0.0 3.05e-03 3.45e+00 ± 9.8e-03 1.3 3 2 1999/07/19 3-oc 01:50:49 00:00:00 01:52:19 0.0 3.04e-03 7.52e+00 ± 8.2e-03 0.9 4 2 1999/07/19 4-oc 01:54:09 00:00:00 01:55:35 0.0 3.92e-03 3.45e+00 ± 1.1e-02 0.9 5 3 1999/07/19 5-oc 01:57:42 00:00:00 01:58:56 0.0 3.03e-03 2.29e+00 ± 8.9e-03 1.0 6 3 1999/07/19 6-oc 02:00:51 00:00:00 02:02:17 0.0 3.03e-03 3.37e+00 ± 9.6e-03 1.2 7 4 1999/07/19 7-oc 02:04:11 00:00:00 02:05:37 0.0 3.90e-03 3.89e+00 ± 1.1e-02 0.9 8 4 1999/07/19 8-oc 02:07:39 00:00:00 02:08:57 0.0 3.02e-03 3.99e+00 ± 5.6e-03 0.4 9 5 1999/07/19 9-oc 02:10:51 00:00:00 02:12:17 0.0 3.01e-03 4.48e+00 ± 9.2e-03 1.1 10 5 1999/07/19 10-oc 02:14:11 00:00:00 02:15:37 0.0 3.88e-03 4.57e+00 ± 1.0e-02 0.8 Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.4096.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-sc 01:44:05 00:00:00 01:45:35 0.0 4.28e-03 7.25e-01 ± 1.1e-02 0.9 0.394963 0.401674 0.388286 2 1 1999/07/19 2-sc 01:47:40 00:00:00 01:48:58 0.0 3.31e-03 1.04e+00 ± 9.2e-03 1.0 0.301128 0.303941 0.298319 3 2 1999/07/19 3-sc 01:50:49 00:00:00 01:52:19 0.0 3.30e-03 6.69e-01 ± 9.1e-03 0.9 0.0889294 0.0901492 0.0877097 4 2 1999/07/19 4-sc 01:54:09 00:00:00 01:55:35 0.0 4.26e-03 7.46e-01 ± 1.2e-02 1.0 0.215859 0.219413 0.21231 5 3 1999/07/19 5-sc 01:57:42 00:00:00 01:58:56 0.0 3.29e-03 9.03e-01 ± 9.4e-03 1.0 0.394702 0.399075 0.390341 6 3 1999/07/19 6-sc 02:00:51 00:00:00 02:02:17 0.0 3.29e-03 6.88e-01 ± 1.0e-02 1.1 0.204367 0.207392 0.201345 7 4 1999/07/19 7-sc 02:04:11 00:00:00 02:05:37 0.0 4.24e-03 1.00e+00 ± 9.7e-03 0.6 0.258049 0.260653 0.255449 8 4 1999/07/19 8-sc 02:07:39 00:00:00 02:08:57 0.0 3.28e-03 5.03e-01 ± 9.7e-03 1.1 0.126172 0.12861 0.123734 9 5 1999/07/19 9-sc 02:10:51 00:00:00 02:12:17 0.0 3.27e-03 9.09e-01 ± 9.7e-03 1.1 0.203047 0.205247 0.200849 10 5 1999/07/19 10-sc 02:14:11 00:00:00 02:15:37 0.0 4.22e-03 8.66e-01 ± 1.2e-02 1.0 0.189539 0.19225 0.186831 Yikes. The variations in the cross sections and the ratios are enormous. rows irun gain -------------------- 1 1.0 673.7 2 2.0 674.5 3 3.0 675.1 4 4.0 675.7 5 5.0 676.5 6 6.0 677.2 7 7.0 677.8 8 8.0 678.8 9 9.0 679.4 10 10.0 680.1 Those gains are comparable with other results from the same day: file: 99199-4k.runs.rdf rows irun gain -------------------- 1 1.0 691.6 file: 99199-16k.runs.vig.rdf rows irun gain -------------------- 1 3.0 691.0 2 4.0 690.6 3 5.0 690.3 4 6.0 690.0 5 7.0 689.7 6 8.0 689.3 file 99199B.runs.rdf rows irun gain -------------------- 1 1.0 653.4 2 2.0 652.4 3 3.0 651.0 ==> The problem doesn't appear to be with the gains. Perhaps there's something wrong with sampling at only 500 Hz? In the future, be sure to go with at least 1000 Hz sampling. Printing the t87 listing by runs was a pain: hitting the text output "print" button generated an error message stating "pl: A file-type must be specified." So I copied the text into emacs, hit print, and got the same message (I hadn't saved the file yet). Then I saved the file and used enscript: reason:/data/ast5/1999JM8/proc/cw < 7 > enscript -1 -f Courier7 -r 99199-8k.4096.runs.t87 ** ** The data in files PSD99199-8.1999JM8 and VOLT99199-8k.1999JM8 are suspect ** so let's throw it out. ** - - - - - - - - - - - - - - - - - - - - - Return to the CW bandwidths. DOY 201 ------- dfreq = 0.244 Hz I discovered that the background removal may have been wrong--jsnr1,2 were set so that some very strong echo points were outside the window in the file blocked by runs. I didn't notice this before so the summed values are incorrect. Change jsnr1,2 from 509,516->503,520 and then repeat the sum & baseline removal. Resaved into 99201.sum.rdf Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 2-oc 02:34:52 02:35:09 02:36:30 0.0 2.29e-03 2.09e+00 ± 6.3e-03 1.8 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99201.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 2-sc 02:34:52 02:35:09 02:36:30 0.0 2.17e-03 3.64e-01 ± 5.8e-03 1.7 0.174023 0.176824 0.171224 These results didn't change. Perhaps the baseline removal before was OK. Echo power: rows 505 506 507 508 509 510 511 512 513 514 515 516 ---------------------------------------------------- 1 2 4 27 79 115 133 155 123 169 78 19 4 rows 505 506 507 508 509 510 511 512 513 514 515 516 ---------------------------------------------------- 1 -0 2 8 22 29 11 36 24 23 10 2 1 There are 9 points with OC power > 19 sigma, or (8)*(0.244 Hz/bin) = 2.0 Hz. Here's the breakdown into the two runs: # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-oc 02:31:52 02:32:09 02:33:22 0.0 3.24e-03 1.63e+00 ± 8.6e-03 1.7 2 1 1999/07/20 2-oc 02:34:52 02:35:09 02:36:30 0.0 3.24e-03 2.57e+00 ± 8.3e-03 1.6 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99201.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-sc 02:31:52 02:32:09 02:33:22 0.0 3.07e-03 2.81e-01 ± 8.5e-03 1.9 0.172187 0.177469 0.166914 2 1 1999/07/20 2-sc 02:34:52 02:35:09 02:36:30 0.0 3.07e-03 4.73e-01 ± 8.0e-03 1.7 0.184168 0.187332 0.181008 That's A LOT of variability from one run to the next. - - - - - - - - - - DOY 201 ------- 1 run, 0.244 Hz resolution file: 99202.runs.rdf Here's how things look: rows 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 sdev jsnr1 jsnr2 ------------------------------------------------------------------------------------------- 1 1 3 6 36 172 95 192 282 104 21 6 1 1 1 2 1 0.0027 510.0 520.0 rows 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 sdev jsnr1 jsnr2 ------------------------------------------------------------------------------------------- 1 -1 1 2 29 16 37 28 26 26 3 0 0 1 1 1 2 0.0025 510.0 520.0 change jsnr2 -> 521. # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-oc 17:41:21 17:41:01 17:42:54 0.0 2.66e-03 2.45e+00 ± 6.0e-03 1.2 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99202.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-sc 17:41:21 17:41:01 17:42:54 0.0 2.49e-03 4.17e-01 ± 6.2e-03 1.5 0.170421 0.172974 0.167871 Adjusting jsnr2 increased OCxsec slightly, but we'll cover for that by assigning an appropriately large uncertainty. Bandwidth: 6 bins with SNR > 20 sigma, so 5(0.244) = 1.2 Hz, one full Hz smaller than my earlier estimate. - - - - - - - - - - DOY 204 (July 23) ------------------ 1 run, 0.244 Hz resolution. rows1020102110221023102410251026102710281029103010311032103310341035 jsnr1 jsnr2 sdev -------------------------------------------------------------------------------------------- 1 1 0 15 50 214 188 321 101 135 53 9 8 1 4 -0 1 1020.0 1035.0 0.00185 rows1020102110221023102410251026102710281029103010311032103310341035 jsnr1 jsnr2 sdev -------------------------------------------------------------------------------------------- 1 -1 1 3 3 31 42 54 24 33 10 1 2 1 0 2 -1 1020.0 1035.0 0.00201 jsnr1 and 2 are rather wide, so the OCxsec will include sincx^2 effects, but that's small compared with the assigned standard errors of ~25%. Bandwidth: use points with > 10 sigma => (7)*(0.244 Hz/bin) = 1.7 Hz Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-oc 00:36:44 00:37:14 00:37:59 0.0 1.85e-03 2.03e+00 ± 4.4e-03 1.4 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99204.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-sc 00:36:44 00:37:14 00:37:59 0.0 2.01e-03 4.14e-01 ± 4.8e-03 1.4 0.203447 0.205839 0.201056 - - - - - - - - - - DOY 205 (July 24) ------------------ 2 runs, 0.244 Hz resolution. Earlier I found that the first run is bad. 99205.runs2.rdf Good file: has the one good run 99205.runs.rdf Has the two runs: one good, one bad 99205.sum.rdf corrupted ==> I deleted it. reason:/data/ast5/1999JM8/proc/cw < 10 > mv 99205.runs.rdf 99205.badruns.rdf reason:/data/ast5/1999JM8/proc/cw < 11 > mv 99205.runs2.rdf 99205.goodrun.rdf > enscript -1 -f Courier9 -r 99205.t87 <== Use Courier 9 printed in landscape rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 1 2 7 3 8 41 110 141 312 397 323 171 122 19 8 8 0 4 0.0015 1019.0 1034.0 rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 0 3 -0 -1 0 11 16 85 48 91 64 23 6 1 3 1 1 0 0.0016 1019.0 1034.0 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99205.goodrun.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 2-oc 17:00:38 17:01:08 17:01:53 0.0 1.50e-03 2.51e+00 ± 3.8e-03 1.6 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99205.goodrun.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 2-sc 17:00:38 17:01:08 17:01:53 0.0 1.57e-03 5.51e-01 ± 3.6e-03 1.3 0.21987 0.221363 0.218378 bandwidth: (8)*(0.244 Hz/bin) = 2.0 Hz No changes to jsnr1,2 from last time. (I'm making hardcopies of t87 listings and echo points as I go back through the CW data.) - - - - - - - - - - DOY 208 (July 27) ----------------- Here's how things stand with the two runs: rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 2 3 6 5 26 62 103 304 123 82 98 57 48 45 20 1 3 2 0.0011 1021.0 1028.0 2 1 2 12 3 13 75 126 302 116 182 299 110 134 64 74 4 5 0 0.0010 1021.0 1028.0 rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 1 2 1 3 0 22 18 14 28 48 14 13 17 11 0 0 -0 -0 0.0012 1021.0 1028.0 2 1 -0 0 1 3 14 13 19 65 21 27 30 17 13 6 3 10 -1 0.0011 1021.0 1028.0 Change jsnr2 -> 1033. rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 2 3 6 5 26 62 103 304 123 82 98 57 48 45 20 1 3 2 0.0011 1021.0 1033.0 2 1 2 12 3 13 75 126 302 116 182 299 110 134 64 74 4 5 0 0.0010 1021.0 1033.0 rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 1 2 1 3 0 22 18 14 28 48 14 13 17 11 0 0 -0 -0 0.0012 1021.0 1033.0 2 1 -0 0 1 3 14 13 19 65 21 27 30 17 13 6 3 10 -1 0.0011 1021.0 1033.0 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99208.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-oc 01:30:58 01:31:01 01:32:13 0.0 1.10e-03 1.07e+00 ± 2.8e-03 1.6 2 1 1999/07/27 2-oc 01:33:01 01:33:20 01:34:20 0.0 1.01e-03 1.51e+00 ± 2.8e-03 1.9 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99208.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-sc 01:30:58 01:31:01 01:32:13 0.0 1.18e-03 2.26e-01 ± 3.2e-03 1.8 0.21005 0.213089 0.207014 2 1 1999/07/27 2-sc 01:33:01 01:33:20 01:34:20 0.0 1.08e-03 2.51e-01 ± 2.9e-03 1.7 0.16547 0.167397 0.163543 I summed the spectra, removed the baseline with a 1st order polynomial, and then saved the results to 99208.sum.rdf (overwriting the old file). Summed results: rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 1 3 12 5 26 96 162 427 168 189 286 119 130 77 67 2 5 1 0.0007 1021.0 1033.0 rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 1 0 0 2 2 24 21 23 66 47 29 30 24 17 4 2 6 -1 0.0008 1021.0 1033.0 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 2-oc 01:33:01 01:33:20 01:34:20 0.0 7.45e-04 1.31e+00 ± 2.1e-03 1.9 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99208.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 2-sc 01:33:01 01:33:20 01:34:20 0.0 7.98e-04 2.33e-01 ± 2.2e-03 1.9 0.178118 0.179851 0.176387 The OCxsec and SC/OC haven't changed. bandwidth: there are 11 contiguous Doppler cells with S/N > 10 sigma, so (10)*(0.244 Hz/bin) = 2.4 Hz. - - - - - - - - - - - - - - - - - - - - - DOY 209 (July 28) ----------------- 1 run, 0.24 Hz resolution. Should have done at least 3 runs for better statistics. file: 99209.runs.rdf rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 5 12 72 254 571 367 2005 428 410 311 806 373 194 46 6 2 1 1 0.0007 1015.0 1035.0 rows 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 sdev jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 2 4 6 43 81 35 61 94 106 53 45 57 73 21 1 2 3 2 0.0008 1015.0 1035.0 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-oc 17:14:17 17:14:14 17:15:14 0.0 7.44e-04 4.37e+00 ± 1.8e-03 1.4 Target 1999JM8 from file /data/ast5/1999JM8/proc/cw/99209.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-sc 17:14:17 17:14:14 17:15:14 0.0 8.01e-04 5.60e-01 ± 2.6e-03 2.5 0.128067 0.128656 0.127478 bandwidth: there are 13 Doppler bins with echo power > 10 sigma, so (12)*(0.244 Hz/bin) = 2.9 Hz. So my previous estimate was OK. The jsnr1,2 bounds are a bit generous but acceptable. The OC xsection is hard to believe, though, because it dwarfs the cross sections obtained on the other days. However, the bandwidth on this day was the largest to date so it's conceivable that the cross section is valid (this was the "twin peaks" day). I'm going to compare the OCxsections with the maximum delay extents too to check for correlations. However, let's take a closer look at the tags for DOY 209. There are only 9 looks in this spectrum, so the self noise is harsh: 33%. Tsys = 15.9, 17.1... no gross problems there... gain: 658*10^12, so that's an acceptable value. Maybe the bad noise statistics are skewing sdev? Check the noise statistics: clearly chi-squared. I made a plot and printed it. I'll discuss this with Steve tomorrow. Let's try interpolating across the one really big point to see how that affects the cross section (the one point is like a delta function). The point in question has SNR = 2005. Adjacent points have SNR = 367 and 428, so take their average: (367 + 428)/2 = 398 and subtract that from 2005: 2005-398 = 1607 sigma. Radar cross section of the spike: (1607)*(7.44E-4 km^2/sdev) = 1.2 km^2. So even if we interpolate across the spike the OC xec on that day was > 3 km^2; thus, it would still be the largest of any day. As noted above, that's consistent with the bandwidth. If the chi-square noise is a factor in sdev for this spectrum, it will be on many other days. I can always recompute the spectrum using dofft with a coarse FFT to put the echo power into one Doppler cell with much better noise statistics. From my experience with 1999 GU3, however, where I got consistent results regardless of the FFT, perhaps we shouldn't expect much of a change. ==> Check it out: go into the voltage file and try a new FFT = 512 and see what happens. That will provide 1 look every 0.5 seconds for about 100 per run. reason:/data/ast5/1999JM8/proc/cw < 16 > dofft -d 3.5 -p 192 -f 512 -i VOLT99209.1999JM8 -o 99209.nocal.512.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99209.1999JM8 RDFOUT_1=99209.nocal.512.1_1.rdf RDFOUT_2=99209.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99209.nocal.512.1.rdf -o 99209.nocal.512.rdf -x PRDX.OUT.s15 -p 192 -d 3.5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 80 Total SC spectra: 80 Processing data... tsys = 15.6, 16.7. The other file (calibrated) used 15.9 and 17.1, which is close enough that I'm not going to change tsys. trpwr = 0. Change that to: 445 kW file: 99209.nocal.512.rdf Run this through tkrdfreduc...looks OK. file: 99209.512.rdf Here's how things look: rows 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------- 1 1 5 3 3 2 5 11 21 141 1102 215 22 9 5 2 2 128.0 129.0 rows 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------- 1 1 -2 -0 0 0 2 -0 4 22 161 45 4 6 0 0 -0 128.0 129.0 Echo is still very strong but the peak SNR is way down relative to the spectra with 0.244 Hz resolution. Change jsnr1,2 -> 124,134. Note that we still have significant tails due to (sincx)^2. Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-oc 17:14:29 00:00:00 17:15:14 0.0 1.97e-03 3.02e+00 ± 2.7e-03 3.6 Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-sc 17:14:29 00:00:00 17:15:14 0.0 2.11e-03 5.15e-01 ± 3.0e-03 4.1 0.170468 0.171487 0.169449 So the OC xsec changed substantially: from 4.4 km^2 with 4096 point FFT to 3.0 km^2 with a 512 point FFT. Well, well, well... That means I need to do this for the other spectra with only a few looks. Note that this is still the largest OC xsec. The variation relative to the previous day is more than a factor of two. I think a good strategy would be to recalibrate the data using the same short FFT on those days when we sampled at 1 kHz. ======================================================================== 1999 November 18 & 19 ======================================================================== Get noise histograms from DOY 209: 99209.512.rdf Using current values of jsnr1 and jsnr2, the (sincx)^2 response is skewing the noise statistics a bit, but otherwise the noise is much closer to gaussian. I made a figure and put it in the notebook. There are 80 looks. file: 99209.512.noise.tpl loading the file 99209.tpl back into tkpl causes the program to bomb. - - - - - - - - - - Two points: 1. Check the noise statistics for all the reduced PSD files 2. Repeat the JM8 cw reductions using dofft and a coarser FFT A quick check of DOY 212 showed that the background removal with the PSD file was off. That could have resulted because the echoes were so strong and it may have affected the OCxsec. Gotta be more careful... 99212.sum.4096.noise.tpl: bad background removal 99213.sum.4096.noise.tpl: same problem. - - - - - - - - - - - - - - - - - - - - I just noticed that the DOY 209 dofft reduction above used the wrong PRDX file. That shouldn't make much of a difference but let's check to be sure. reason:/data/ast5/1999JM8/proc/cw < 20 > dofft -d 5.0 -p 192 -f 512 -i VOLT99209.1999JM8 -o 99209.nocal.512.new.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99209.1999JM8 RDFOUT_1=99209.nocal.512.new.1_1.rdf RDFOUT_2=99209.nocal.512.new.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99209.nocal.512.new.1.rdf -o 99209.nocal.512.new.rdf -x PRDX.OUT.s23 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 80 Total SC spectra: 80 Processing data... reason:/data/ast5/1999JM8/proc/cw < 21 > Note that I used D = 5.0 km instead of 3.5. change trpwr -> 445. 80 looks Change jsnr1, 2 = 124, 134 rows 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 5 11 21 141 1102 215 22 9 5 2 2 124.0 134.0 rows 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 2 -0 4 22 161 45 4 6 0 0 -0 124.0 134.0 Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.new.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-oc 17:14:29 00:00:00 17:15:14 0.0 1.97e-03 3.02e+00 ± 2.7e-03 3.6 Target unknown from file /data/ast5/1999JM8/proc/cw/99209.512.new.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-sc 17:14:29 00:00:00 17:15:14 0.0 2.11e-03 5.15e-01 ± 3.0e-03 4.1 0.170468 0.171487 0.169449 No change, as expected. DOY 212 ======= Use dofft with FFT = 512 reason:/data/ast5/1999JM8/proc/cw < 22 > dofft -d 5.0 -p 192 -f 512 -i VOLT99212.1999JM8 -o 99212.nocal.512.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99212.1999JM8 RDFOUT_1=99212.nocal.512.1_1.rdf RDFOUT_2=99212.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99212.nocal.512.1.rdf -o 99212.nocal.512.rdf -x PRDX.OUT.s23 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 180 Total SC spectra: 180 Processing data... reason:/data/ast5/1999JM8/proc/cw < 23 > tags look OK... One minor tag issue of concern: posfr = -1 but the spectra have seemed OK. According to Keith's tag description posfr = -1 is supposed to mean that freq increases from right to left. Also, all the irun values equal one ==> everything will get summed into one spectrum (there are two runs). That's fine. run it through the calibration... file: 99212.512.rdf There are 180 looks. Noise statistics should be excellent. change jsnr1,2 = 124, 134. That's wide enough to include (sincx)^2 effects, but they don't contribute much because the powers are so low. I set jsnr1 and 2 to include them so as not to skew the noise histograms. Target unknown from file /data/ast5/1999JM8/proc/cw/99212.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/31 1-oc 17:01:12 00:00:00 17:04:03 0.0 1.52e-03 1.94e+00 ± 2.3e-03 4.5 Target unknown from file /data/ast5/1999JM8/proc/cw/99212.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/31 1-sc 17:01:12 00:00:00 17:04:03 0.0 1.63e-03 4.25e-01 ± 2.5e-03 4.6 0.219443 0.220766 0.21812 OC xsec = 1.9 km^2 SC/OC = 0.22 +/- 0.01 Previously I got OCxsec = 2.6 km^2. and SC/OC =0.20. DOY 213 ======= reason:/data/ast5/1999JM8/proc/cw < 9 > dofft -d 5.0 -p 192 -f 512 -i VOLT99213.1999JM8 -o 99213.nocal.512.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99213.1999JM8 RDFOUT_1=99213.nocal.512.1_1.rdf RDFOUT_2=99213.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99213.nocal.512.1.rdf -o 99213.nocal.512.rdf -x PRDX.OUT.s23 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 192 Total SC spectra: 192 Processing data... reason:/data/ast5/1999JM8/proc/cw < 10 > Tsys ch1,2 = 15.1, 16.1 K. For this pass, let's leave these alone and check for significant differences relative to previous values. all the irun values = 1, but that's fine since I was going to sum anyway. 192 looks. The usual (sincx)^2 effect is present. jsnr1,2 = 128,129. Change to 124,134 An alternative would be to smooth optimally in freq and then read the echo power from the peak point and multiply it by sdev. rows 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 jsnr1 jsnr2 ----------------------------------------------------------------------------------------------------------------------------- 1 1 -0 3 4 5 5 12 23 189 767 108 27 12 5 3 3 3 -1 1 1 1 124.0 134.0 rows 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 jsnr1 jsnr2 ----------------------------------------------------------------------------------------------------------------------------- 1 1 0 -1 -0 1 1 4 6 46 165 23 1 1 3 1 3 -0 0 -0 2 0 124.0 134.0 Target unknown from file /data/ast5/1999JM8/proc/cw/99213.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/08/01 1-oc 12:03:22 00:00:00 12:06:16 0.0 1.39e-03 1.61e+00 ± 2.0e-03 4.1 Target unknown from file /data/ast5/1999JM8/proc/cw/99213.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/08/01 1-sc 12:03:22 00:00:00 12:06:16 0.0 1.48e-03 3.73e-01 ± 2.2e-03 4.2 0.232503 0.233877 0.23113 OCxsec = 1.6 km^2 SC/OC = 0.23+/-0.01 Well, well, well... Recall that SC/OC before (0.24 Hz res'n) was 0.30 and that OCxsec was 2.6 km^2. Yikes... DOY 208 (July 27) ================= reason:/data/ast5/1999JM8/proc/cw < 10 > dofft -d 5 -p 192 -f 512 -i VOLT99208.1999JM8 -o 99208.nocal.512.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99208.1999JM8 RDFOUT_1=99208.nocal.512.1_1.rdf RDFOUT_2=99208.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99208.nocal.512.1.rdf -o 99208.nocal.512.rdf -x PRDX.OUT.s21 -p 192 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 216 Total SC spectra: 216 Processing data... reason:/data/ast5/1999JM8/proc/cw < 11 > Tsys: ch1,2 = 15.4, 16.5. Leave as is--difference is at the ~10% level, which is less than the standard errors we'll adopt. irun = 1 => put all the hops into one sum. The rest of the reduction was uneventful... rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 sdev ----------------------------------------------------------------------------------- 1 3 0 2 7 19 383 131 9 2 3 4 126.0 132.0 0.00161 rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 sdev ----------------------------------------------------------------------------------- 1 1 -1 0 1 5 68 18 2 -1 -2 0 126.0 132.0 0.00173 Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-oc 01:31:16 00:00:00 01:34:22 0.0 1.61e-03 8.89e-01 ± 2.2e-03 3.6 Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-sc 01:31:16 00:00:00 01:34:22 0.0 1.73e-03 1.62e-01 ± 2.3e-03 3.5 0.181996 0.18462 0.179373 What??? 0.89 km^2? What makes that hard to believe is the value of 3.0 km^2 on the next day. Then again...on DOY 208 the most pointed end was oriented toward the radar, so it's conceivable that there was less projected area to reflect. Geographos comes to mind, but even that object had OCxsec variations of only a factor of two, not three. Something wrong with the DOY 209 data? Tsys could be a factor: the values I used before were 18.2 and 19.5, which are about 3 K warmer than the tags. That's a difference of almost 20%, so let's split the file into 2 polarizations, change Tsys, combine them, and then repeat the reduction of the nocal file. reason:/data/ast5/1999JM8/proc/cw < 17 > rdfseparate -i 99208.nocal.512.rdf -o 99208.nocal.512.sep Dumping frame 1 to 99208.nocal.512.sep001.rdf Dumping frame 2 to 99208.nocal.512.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 18 > cat 99208.nocal.512.sep001.rdf 99208.nocal.512.sep002.rdf > 99208.nocal.512.corrected.rdf Here's the result: rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 sdev ----------------------------------------------------------------------------------- 1 3 0 2 7 19 383 131 9 2 3 4 126.0 132.0 0.00190 rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 sdev ----------------------------------------------------------------------------------- 1 1 -1 0 1 5 68 18 2 -1 -2 0 126.0 132.0 0.00204 Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-oc 01:31:16 00:00:00 01:34:22 0.0 1.90e-03 1.05e+00 ± 2.6e-03 3.6 Target unknown from file /data/ast5/1999JM8/proc/cw/99208.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-sc 01:31:16 00:00:00 01:34:22 0.0 2.04e-03 1.91e-01 ± 2.7e-03 3.5 0.181193 0.183806 0.178583 OCxsec = 1.1 km^2, SC/OC = 0.18. Value I recorded from 0.244 Hz spectrum was 1.3 km^2. I spoke with Steve: he thinks I'm spending too much time on this relative to what we can get out of it due to the bad calibration of the Goldstone system. So go with our best estimates, and when it comes time to hand everything to Scott, let him know the standard errors and my best estimate of what was really going on. If there were bad days, flag them. So: Wrap up the OCxsecs using short FFTs and then move on. ======================================================================== 1999 November 21 ======================================================================== Continuing with reducing the CW data with short FFTs... DOY 205 (July 24) ================= reason:/data/ast5/1999JM8/proc/cw < 12 > dofft -d 5 -p 192 -f 512 -i VOLT99205.1999JM8 -o 99205.nocal.512.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99205.1999JM8 RDFOUT_1=99205.nocal.512.1_1.rdf RDFOUT_2=99205.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99205.nocal.512.1.rdf -o 99205.nocal.512.rdf -x PRDX.OUT.s21 -p 192 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 236 Total SC spectra: 236 Processing data... reason:/data/ast5/1999JM8/proc/cw < 13 > Tsys: ch1,2 = 7.1, 17.9 ch1 should be 17.1, not 7.1. reason:/data/ast5/1999JM8/proc/cw < 14 > rdfseparate -i 99205.nocal.512.rdf -o 99205.nocal.512.sep Dumping frame 1 to 99205.nocal.512.sep001.rdf Dumping frame 2 to 99205.nocal.512.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 15 > reason:/data/ast5/1999JM8/proc/cw < 15 > cat 99205.nocal.512.sep001.rdf 99205.nocal.512.sep002.rdf > 99205.nocal.512.corrected.rdf tags look OK, but I'm still puzzled that posfr = -1. Ran this through tkrdfreduc: 99205.512.rdf No obvious problems with the calibration. 236 looks. change jsnr1,2 from 128,129->126,132: rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 5 3 3 13 21 838 141 14 5 3 4 126.0 132.0 rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 -1 0 2 2 7 125 26 8 2 1 0 126.0 132.0 Target unknown from file /data/ast5/1999JM8/proc/cw/99205.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 1-oc 16:58:26 00:00:00 17:01:53 0.0 2.69e-03 2.78e+00 ± 3.3e-03 2.9 Target unknown from file /data/ast5/1999JM8/proc/cw/99205.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 1-sc 16:58:26 00:00:00 17:01:53 0.0 2.81e-03 4.80e-01 ± 3.8e-03 3.5 0.172968 0.174337 0.171599 OCxsec is LARGER with FFT=512 than before: previous result was 2.5 km^2 Ratio has dropped from 0.22 -> 0.18 This spectrum has more positive noise points than I expected given the number of looks. Some are due to sincx^2, but what about the rest? It doesn't look as if the background removal is bad... Nor is this an issue of the number of histogram bins (30 in most cases). DOY 204 (July 23) ================= reason:/data/ast5/1999JM8/proc/cw < 16 > dofft -d 5 -p 192 -f 512 -i VOLT99204.1999JM8 -o 99204.nocal.512.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99204.1999JM8 RDFOUT_1=99204.nocal.512.1_1.rdf RDFOUT_2=99204.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99204.nocal.512.1.rdf -o 99204.nocal.512.rdf -x PRDX.OUT.s21 -p 192 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 132 Total SC spectra: 132 Processing data... reason:/data/ast5/1999JM8/proc/cw < 17 > Tsys: ch1,2 = 15.1, 16.4. These are the actual temps at the start, so they're OK. The remainder of the reduction looks OK. 132 looks rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 0 1 2 5 361 26 7 3 0 2 126.0 132.0 rows 124 125 126 127 128 129 130 131 132 133 134 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 -1 0 0 1 58 4 1 -1 1 0 126.0 132.0 Target unknown from file /data/ast5/1999JM8/proc/cw/99204.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-oc 00:36:50 00:00:00 00:38:01 0.0 5.22e-03 2.11e+00 ± 5.8e-03 2.4 Target unknown from file /data/ast5/1999JM8/proc/cw/99204.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-sc 00:36:50 00:00:00 00:38:01 0.0 5.67e-03 3.64e-01 ± 6.3e-03 2.4 0.172219 0.175225 0.169215 OCxsec = 2.1 km^2, SC/OC = 0.17. Previous values: 2.0 km^2, 0.20 The noise statistics are puzzling: there seem to be far fewer SC points than OC. ?? Is there something wrong with the filter? In both plots I used bins = 30. I've had tkpl hang twice while I've been trying to figure out this problem. Both times I entered '1' for the spectrum number instead of zero. Recall that the noise plotting filter counts from zero instead of 1. When I enter 1 I've gotten an error message that jsnr1 must be less than jsnr2, which, of course, it is. Here's what happened when I tried running this from the command line: reason:/data/ast5/1999JM8/proc/cw < 34 > rdfnoisehist -i 99204.512.rdf -o junk -f 1 -a -n 3 rdfnoisehist: unrecognized option `-o' Usage: rdfnoisehist -i infile -o outfile [-f frame] [-r r_start -R r_end]|[-s index [-s index...]]|[-a] [-n nbins] [-h] -i infile specifies the name of the input file, a '-' implies the use of stdin -f frame Use data from the specified frame only -r r_start Set the start of a range of spectra to plot. -R r_end Set the end of a range of spectra to plot. -s index Plot a single spectrum. May be used more than once on the command line to specify a non-contiguous set of spectra. -a Plot every spectrum. -n bins Use this number of bins for counting data -h help reason:/data/ast5/1999JM8/proc/cw < 35 > ==> I added this to a list of software problems that I'm going to send to Keith and Mike Thomas. DOY 202 (July 21) ================= reason:/data/ast5/1999JM8/proc/cw < 20 > dofft -d 5.0 -p 192 -f 512 -i VOLT99202.1999JM8 -o 99202.nocal.512.rdf -x PRDX.OUT.s19 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99202.1999JM8 RDFOUT_1=99202.nocal.512.1_1.rdf RDFOUT_2=99202.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99202.nocal.512.1.rdf -o 99202.nocal.512.rdf -x PRDX.OUT.s19 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 140 Total SC spectra: 140 Processing data... reason:/data/ast5/1999JM8/proc/cw < 21 > 4 hops this time, not 2 From above: "We measured Ch1 = 17.8 and Ch2 = 19.0 on point." Use rdfseparate again to change Tsys: reason:/data/ast5/1999JM8/proc/cw < 21 > rdfseparate -i 99202.nocal.512.rdf -o 99202.nocal.512.sep Dumping frame 1 to 99202.nocal.512.sep001.rdf Dumping frame 2 to 99202.nocal.512.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 22 > reason:/data/ast5/1999JM8/proc/cw < 22 > cat 99202.nocal.512.sep001.rdf 99202.nocal.512.sep002.rdf > 99202.nocal.512.corrected.rdf run this the rest of the way through... Got the calibration error again: rnb.removeBackground() status: Normalizing spectrum 0 with rmsc of 0.166667 rnb.Calibrate(): xmit_sta is DSS14 Default value used Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (0.166667) setting rmsc to 0.09759 ( 0) 1.11452e+07 83.9 19 675.569 425 4 1.95312 71.68 0.09759 0.00696483 All Finished! :^) 140 looks. This is where things stand before changing jsnr1 and 2: rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 0 4 5 11 180 100 11 3 3 -0 64.0 65.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 -0 -0 0 2 42 18 2 -0 0 1 64.0 65.0 This might have affected background removal. Change jsnr1,2 = 62,69. There's still some (sincx)^2 in the spectrum. rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 0 4 5 11 180 100 11 3 3 -0 62.0 69.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 -0 -0 0 2 42 18 2 -0 0 1 62.0 69.0 Target unknown from file /data/ast5/1999JM8/proc/cw/99202.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-oc 17:41:37 00:00:00 17:42:56 0.0 6.52e-03 2.07e+00 ± 1.0e-02 4.6 Target unknown from file /data/ast5/1999JM8/proc/cw/99202.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-sc 17:41:37 00:00:00 17:42:56 0.0 6.96e-03 4.46e-01 ± 9.9e-03 3.9 0.21545 0.220329 0.210582 The new radar cross section has changed from 2.5 to 2.1 km ^2 and the ratio has changed from 0.17 to 0.22. the noise histograms are again confusing: there seem to be too many points between -1 and +1 sigma relative to the gaussian fit. Is something wrong with the way the gaussians are computed? Is there something obvious that I don't understand? ======================================================================== 1999 November 23 ======================================================================== Take a break from the dofft reductions to estimate the delay-Doppler dispersions in the Goldstone images. I'm tabulating the results on the Goldstone master log. The July 24 image is the first that shows the obvious "gouge." After pondering that a bit, my best explanation is still that it's an impact crater that is not obviously circular due to its large size relative to the size of the asteroid. It also turns out that the concavity is somewhat visible in the July 23 image. In retrospect, I should have used higher delay-Doppler resolution on both July 23 and 24. The July 27 image is the one that shows a prominent pointed end on the LE. I've vignetted the image, but is there actually more weak echo present? I don't see any other, more distant points in the full array. July 28: This is the "twin peaks" image. I opened the full array in Transform and adjusted the stretch to highlight points weaker than sigma. To my surprise, there's a collection of points at negative frequencies that look like they've been aliased. They're very weak--less than 2 sigma--and they seem to trace the LE of one of the peaks. Perhaps this is just coincidental. Another issue: double check the normalization by experimenting with the exclusion zone used by acunorm. July 31: there is more echo power in this image than I had noticed before. Specifically, the delay extent on the approaching limb is somewhat deeper and there's clearly a large crater rotating into view. Again, weak echo power at about the 1-sigma level are very common, so I need to check the normalization. The July 31 image has changed my interpretation of the possible large "crater;" that is, the unexplained concavity. If one considers both the July 31 and Aug 1 images, then it appears that the concavity could be caused by a prominent ridge. It's clear that there is echo power in the July 31 image corresponding to the dark regions in the Aug 1 image. What else other than a crater could the concavity be? A topo depression among blocks of a rubble pile... Using the Aug 2 Arecibo image, the concavity has a visible range extent of about 2.4 km. If Scott's preliminary effective diameter of 3.5 km is close to correct, then this feature is about 70% the diameter. The echoes on July 31 and Aug 1 were deep enough that they could have wrapped in delay, but I don't see evidence for it in the Goldstone images (however, the Aug 1 Arecibo image indicates that the Aug 1 Goldstone image *should* have wrapped--the echoes weren't strong enough to see it). August 1: when I adjust the stretch to bring out weak points there's another weak aliased image at negative frequencies. Ask Steve about this... Problem with the imaging system? Software? ==> Check other days to see if it's there. Echoes need to be very strong to detect this. At any rate, the distal arc of points that is obvious in the Arecibo image on this day is also present in the Goldstone image. Presence of "ghost" images -------------------------- Date ghost? ---- ------ Jul 24 No Jul 27 No Jul 28 Yes Jul 31 No Aug 1 Yes Aug 7 No Aug 8 No DELAY-DOPPLER DISPERSIONS ========================= Includes pixels with echo power above the 2-sigma level. To compute the dispersion in km or Hz, I assumed 1 pixel is at the COM and multiplied the others by the resoution. VISIBLE DELAY DISPERSION BANDWIDTH DOY/Date SETUP (gates) (km) (bins) (Hz) -------- ----- ---------------- ------------ 201/Jul 20 1.0 us x 0.1 Hz 20 2.85 19 1.8 202/Jul 21 1.0 us x 0.1 Hz 19 2.70 17 1.6 204/Jul 23 0.5 us x 0.075 Hz 35 2.55 20 1.43 205/Jul 24 0.5 us x 0.075 Hz 46 3.38 23 1.65 include the distal arc ==> 58 4.28 <--same--> 208/Jul 27 0.25 us x 0.05 Hz 88 3.26 49 2.40 209/Jul 28 0.25 us x 0.05 Hz 105 3.90 54 2.65 212/Jul 31 0.125 us x 0.05 Hz 185 3.45 68 3.35 213/Aug 1 0.125 us x 0.05 Hz 223 4.16 62 3.05 219/Aug 7 0.25 us x 0.075 Hz 72 2.66 43 3.15 220/Aug 8 0.25 us x 0.075 Hz 89 3.30 46 3.38 Notes: 1. For July 24, two sets of numbers are listed for the delay dispersion due to the arc of weak points seen on that day that are seen at much higher S/N on other days when the asteroid was in a similar orientation. The arcuate points are all below 2 sigma. 2. July 27: Trailing edge is difficult to define. I didn't use contiguous 2-sigma points in this case. Instead, I visually integrated the TE from the receding limb along the back and picked a plausible point as my best estimate. 3. July 28: Points on the TE are weak--many are less than 2 sigma--but they're contiguous so I'm counting them. I'm using a visual estimate again of the TE as I described above. 4. July 31: See notes 2 and 3. 5. Aug 1: Range extent includes weak distal arc - - - - - - - - - - - - - - - - - - - Return to the Goldstone CW data. DOY 201 (July 20) ================= reason:/data/ast5/1999JM8/proc/cw < 35 > dofft -d 5.0 -p 192 -f 512 -i VOLT99201.1999JM8 -o 99201.nocal.512.rdf -x PRDX.OUT.s17 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99201.1999JM8 RDFOUT_1=99201.nocal.512.1_1.rdf RDFOUT_2=99201.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99201.nocal.512.1.rdf -o 99201.nocal.512.rdf -x PRDX.OUT.s17 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 308 Total SC spectra: 308 Processing data... reason:/data/ast5/1999JM8/proc/cw < 36 > 4 hops, more than 300 looks. Yow. Tsys: ch1,2 = 15.2, 16.5 K. From before the temps should be: Tsys ---- ch 1 15.93 ch 2 16.78 reason:/data/ast5/1999JM8/proc/cw < 38 > rdfseparate -i 99201.nocal.512.rdf -o 99201.nocal.512.sep Dumping frame 1 to 99201.nocal.512.sep001.rdf Dumping frame 2 to 99201.nocal.512.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 39 > cat 99201.nocal.512.sep001.rdf 99201.nocal.512.sep002.rdf > 99201.nocal.512.corrected.rdf Got the rnb calibrate error again: rnb.removeBackground() status: Normalizing spectrum 0 with rmsc of 0.166667 rnb.Calibrate(): xmit_sta is DSS14 Default value used Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (0.166667) setting rmsc to 0.09759 ( 0) 1.11452e+07 83.9 19 675.569 425 4 1.95312 71.68 0.09759 0.00696483 Because irun = 1 for each look, and because I didn't change that even though we did two runs, everything got blocked into a file. 99201.512.rdf Rats. I just realized that I was working with the DOY 202 file, not 201 (in tkpl, that is). Specifically, I re-calibrated the DOY 202 file, but I set Tsys in the DOY 201 files. Repeat the calibration: Still get the calibration error (as before): rnb.Calibrate(): xmit_sta is DSS14 Default value used Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (0.111803) setting rmsc to 0.0657952 ( 0) 1.11452e+07 92.73 16.78 687.355 425 4 1.95312 157.696 0.0657952 0.00608281 All Finished! :^) I found a tkpl bug: If you have a file open and you attempt to open it again, say, accidentally, then tkpl produces error messages if you try to use that file. Polarizations are set correctly. 308 looks. Wow. rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 sdev ----------------------------------------------------------------------------------- 1 2 1 2 7 58 221 8 3 2 0 1 64.0 65.0 0.0058 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 sdev ----------------------------------------------------------------------------------- 1 1 1 0 2 12 38 2 0 1 0 0 64.0 65.0 0.0061 In this case, jsnr1 and 2 are set well. The bandwidth closely matches what I saw in the image: 1.6 Hz. The 0.24 Hz CW echoes have a bandwidth of 2.0 Hz. The modest difference could easily be attributable to the weakness of the delay-Doppler images given that we got less than two complete runs. If we ignore the 7 and 8 sigma points on the edges of the echo, the difference will be at most only about 15%. Hmm... That's more than I'd like. Compute the OC xsec: (0.0058)*(58+221) = 1.6 km^2. If I include the points on the side, the answer is 1.7 km^2. Adopt the first estimate. Target unknown from file /data/ast5/1999JM8/proc/cw/99201.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-oc 02:31:56 00:00:00 02:36:32 0.0 5.77e-03 1.61e+00 ± 7.0e-03 2.9 Target unknown from file /data/ast5/1999JM8/proc/cw/99201.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-sc 02:31:56 00:00:00 02:36:32 0.0 6.08e-03 3.03e-01 ± 7.7e-03 3.1 0.187552 0.19238 0.18273 OCxsec = 1.6 km^2, SC/OC = 0.19. Using the 0.244 Hz data, I got OCxsec = 2.1 km^2 and SC/OC = 0.17. enscript -1 -f Courier9 -r 99201.512.t87 I'm having more trouble with rdfnoisehist--it doesn't seem to be using as many bins as I'm specifying. If I don't tell it how many bins to use, the SC histogram defaults to far more bins than the OC histogram. In either case, there seems to be an excess of points with echo powers near zero sigma relative to the gaussian. Conclusion: rdfnoisehist isn't reliable. Still to do: Apply dofft to some of the data from the first track to get 1.95 Hz resolution. Use either file 99199B (1000 Hz sampling, 3 runs, and four hops), or file 99199-16k (4000 Hz sampling, 4 hops, 6 runs). 99199-16k would be better because we should get twice as many looks. Check the tags in the Goldstone rdf files Verify the acunorm normalization Verify that Mike Nolan's rdf conversion worked. Jean-Luc's images are a mess. ======================================================================== 1999 November 24 & 29 ======================================================================== Most important rdf image file tags: year, iday, dtime, baudlen, bins, freqs, bw, fres, incoh_sums, coh_sums, nacums The time-related tags are the ones that concern me the most due to the power dip that reset the clock on the VAX. Check the year tags on the rdf files: reason:/data/ast5/1999JM8/proc/rng < 17 > grep "year" *.rdf jm20108.nrm.rdf:i year 1992 jm20203.nrm.rdf:i year 1992 jm20403.nrm.rdf:i year 1992 jm20511.nrm.1.rdf:i year 1992 jm20511.nrm.rdf:i year 1992 jm20511.nrm1.rdf:i year 1992 jm20511.nrm2.rdf:i year 1992 jm20511.nrm3.rdf:i year 1992 jm20803.nrm.rdf:i year 1992 jm20903.nrm.rdf:i year 1992 jm21205.nrm.rdf:i year 1992 jm21305.nrm.rdf:i year 1992 jm21903.nrm.rdf:i year 1992 jm22003.nrm.rdf:i year 1992 jm22004.nrm.rdf:i year 1992 jm22005.nrm.rdf:i year 1992 jm22006.nrm.rdf:i year 1992 These are files that have already been normalized. What about the raw files? Recall that the VAX crash due to the power dip reset the clock to 1992. ranging files in /ast5/1999JM8/raw/: DOY year tag --- -------- 201 1999 202 1999 except for 202_rng/jm20202.rdf, which is a cold sky 204 1999 205 1999 208 1999 209 1999 212 1999 213 1999 219 1999 220 1999 DOY iday --- ---- 201 201 202 202 204 204 205 205 208 208 209 209 212 212 213 213 219 219 220 220 ==> iday tags are fine. file baudlen fres bw bins freqs incoh_sums coh_sums ---- ------- ---- --- ---- ----- ---------- -------- jm20103 10 6.152 393.7 127 64 64 2 OK (not setup requested) jm20107 11 2.237 143.2 127 64 9 5 OK jm20108 1.0 0.100 6.4 127 64 2 1230 OK jm20203 1.0 0.100 25.6 255 256 1 153 OK jm20403 0.5 0.075 19.2 255 256 1 409 OK (log switched coh_sums/incoh_sums) jm20505 10 2.461 157.5 127 64 10 5 OK jm20508 11 2.237 143.2 127 64 9 5 OK jm20511 0.5 0.075 19.2 255 256 1 409 OK jm20803 0.25 0.050 12.8 255 256 1 1230 OK jm20903 0.25 0.050 12.8 255 256 1 1230 OK jm21203 0.125 0.050 12.8 255 256 1 2450 no electronic log jm21204 0.125 0.050 12.8 255 256 1 2450 no electronic log jm21303 0.125 0.050 12.8 255 256 1 2450 no electronic log jm21304 0.125 0.050 12.8 255 256 1 2450 no electronic log jm21903 0.25 0.075 19.2 255 log? jm22003 0.25 0.075 19.2 255 256 2 817 OK jm22004 0.25 0.075 19.2 255 256 2 817 OK jm22005 0.25 0.075 19.2 255 256 2 817 OK jm22006 0.25 0.075 19.2 255 256 2 817 OK checked: all of them file dtime ---- ----- jm20103 dtime > 86400 => subtract 86400 from each value (see below) jm20107 dtime > 86400 => subtract 86400 from each value (see below) jm20108 dtime > 86400 => subtract 86400 from each value (see below) jm20203 OK jm20403 dtime > 86400 ==> subtract 86400 from each value (see below) jm20505 OK jm20508 OK jm20511 OK jm20803 dtime > 86400 ==> subtract 86400 from each value (see below) jm20903 OK jm21203 OK jm21204 OK jm21303 OK jm21304 OK jm21903 OK jm22003 OK jm22004 OK jm22005 OK jm22006 OK On several days I combined multiple rdf files into one and then summed and normalized the resulting file. For example, jm21305.rdf. dtime values for jm20803.rdf: reason:/data/ast5/1999JM8/raw < 52 > grep "dtime" 208_rng/*rdf 208_rng/jm20801.rdf:d dtime 5907.000000 208_rng/jm20801.rdf:d dtime 5926.000000 208_rng/jm20801.rdf:d dtime 5947.000000 208_rng/jm20802.rdf:d dtime 92673.000000 208_rng/jm20802.rdf:d dtime 92692.000000 208_rng/jm20803.rdf:d dtime 93028.000000 208_rng/jm20803.rdf:d dtime 93048.000000 208_rng/jm20803.rdf:d dtime 93160.000000 208_rng/jm20803.rdf:d dtime 93293.000000 208_rng/jm20803.rdf:d dtime 93313.000000 208_rng/jm20803.rdf:d dtime 93424.000000 208_rng/jm20803.rdf:d dtime 93550.000000 208_rng/jm20803.rdf:d dtime 93678.000000 208_rng/jm20803.rdf:d dtime 93811.000000 208_rng/jm20803.rdf:d dtime 93934.000000 208_rng/jm20803.rdf:d dtime 94066.000000 208_rng/jm20803.rdf:d dtime 94086.000000 208_rng/jm20803.rdf:d dtime 94197.000000 208_rng/jm20803.rdf:d dtime 94331.000000 208_rng/jm20803.rdf:d dtime 94464.000000 208_rng/jm20803.rdf:d dtime 94597.000000 208_rng/jm20803.rdf:d dtime 94729.000000 208_rng/jm20803.rdf:d dtime 94863.000000 208_rng/jm20803.rdf:d dtime 94996.000000 208_rng/jm20803.rdf:d dtime 95129.000000 208_rng/jm20803.rdf:d dtime 95262.000000 208_rng/jm20803.rdf:d dtime 95393.000000 208_rng/jm20803.rdf:d dtime 95521.000000 208_rng/jm20803.rdf:d dtime 95653.000000 208_rng/jm20803.rdf:d dtime 95779.000000 208_rng/jm20803.rdf:d dtime 95912.000000 208_rng/jm20803.rdf:d dtime 96040.000000 208_rng/jm20803.rdf:d dtime 96166.000000 208_rng/jm20803.rdf:d dtime 96300.000000 208_rng/jm20803.rdf:d dtime 96432.000000 208_rng/jm20803.rdf:d dtime 96564.000000 208_rng/jm20803.rdf:d dtime 96584.000000 208_rng/jm20803.rdf:d dtime 96696.000000 208_rng/jm20803.rdf:d dtime 96828.000000 old value new value --------- --------- 93028.000000 6628 93048.000000 6648 93160.000000 6760 93293.000000 6893 93313.000000 6913 93424.000000 7024 93550.000000 7150 93678.000000 7278 93811.000000 7411 93934.000000 7534 94066.000000 7666 94086.000000 7686 94197.000000 7797 94331.000000 7931 94464.000000 8064 94597.000000 8197 94729.000000 8329 94863.000000 8463 94996.000000 8596 95129.000000 8729 95262.000000 8862 95393.000000 8993 95521.000000 9121 95653.000000 9253 95779.000000 9379 95912.000000 9512 96040.000000 9640 96166.000000 9766 96300.000000 9900 96432.000000 10032 96564.000000 10164 96584.000000 10184 96696.000000 10296 96828.000000 10428 I computed these by hand with a calculator. reason:/data/ast5/1999JM8/raw/208_rng < 60 > grep "dtime" jm20803.rdf d dtime 6628.000000 d dtime 6648.000000 d dtime 6760.000000 d dtime 6893.000000 d dtime 6913.000000 d dtime 7024.000000 d dtime 7150.000000 d dtime 7278.000000 d dtime 7411.000000 d dtime 7534.000000 d dtime 7666.000000 d dtime 7686.000000 d dtime 7797.000000 d dtime 7931.000000 d dtime 8064.000000 d dtime 8197.000000 d dtime 8329.000000 d dtime 8463.000000 d dtime 8596.000000 d dtime 8729.000000 d dtime 8862.000000 d dtime 8993.000000 d dtime 9121.000000 d dtime 9353.000000 WRONG: 9253 --> corrected d dtime 9379.000000 d dtime 9512.000000 d dtime 9640.000000 d dtime 9766.000000 d dtime 9900.000000 d dtime 10032.000000 d dtime 10164.000000 d dtime 10184.000000 d dtime 10296.000000 d dtime 10428.000000 jm20403.rdf: dtime values are also > 86400. This time let's do it right: write a short Perl script that will parse the *dtime file, subtract 86400, and then output the results. I'll scan through the rdf file using emacs and replace the numbers by hand, and then I'll double check them by grepping again afterward. script: /data/ast5/1999JM8/raw/204_rng/jm8dtimeproc 0 89613.0 3213.0 1 89627.0 3227.0 2 89640.0 3240.0 3 89653.0 3253.0 4 89776.0 3376.0 5 89789.0 3389.0 6 89803.0 3403.0 7 89816.0 3416.0 8 89933.0 3533.0 9 89946.0 3546.0 10 89960.0 3560.0 11 89973.0 3573.0 12 90097.0 3697.0 13 90110.0 3710.0 14 90123.0 3723.0 15 90137.0 3737.0 16 90357.0 3957.0 17 90371.0 3971.0 18 90384.0 3984.0 19 90398.0 3998.0 20 90520.0 4120.0 21 90534.0 4134.0 22 90547.0 4147.0 23 90561.0 4161.0 24 90681.0 4281.0 25 90694.0 4294.0 26 90708.0 4308.0 27 90721.0 4321.0 28 90842.0 4442.0 29 90855.0 4455.0 30 90868.0 4468.0 31 90882.0 4482.0 32 91006.0 4606.0 33 91019.0 4619.0 34 91032.0 4632.0 35 91045.0 4645.0 36 91163.0 4763.0 37 91176.0 4776.0 38 91189.0 4789.0 39 91203.0 4803.0 40 91320.0 4920.0 41 91333.0 4933.0 42 91347.0 4947.0 43 91360.0 4960.0 44 91483.0 5083.0 45 91496.0 5096.0 46 91510.0 5110.0 47 91523.0 5123.0 48 91646.0 5246.0 49 91659.0 5259.0 50 91672.0 5272.0 51 91686.0 5286.0 52 91807.0 5407.0 53 91820.0 5420.0 54 91833.0 5433.0 55 91847.0 5447.0 56 91969.0 5569.0 57 91983.0 5583.0 58 91996.0 5596.0 59 92010.0 5610.0 60 92128.0 5728.0 61 92142.0 5742.0 62 92155.0 5755.0 63 92169.0 5769.0 64 92287.0 5887.0 65 92300.0 5900.0 66 92313.0 5913.0 67 92326.0 5926.0 I modified the original file and verified that the dtime values are now correct. I also used the Perl script to check the jm20803 dtime values that I computed earlier: they're OK. DOY 201: Same problem on this day as on the DOY 205 and 208. This includes the 10 us and 11 us coarse resolution ranging files. Use the Perl script to fix all three files. jm20103: done & checked jm20107: " jm20108: " ======================================================================== 1999 November 30 & December 1 ======================================================================== dofft on the DOY 201 cw voltage data I don't see the 16k VOLT file on /data/ast5/1999JM8/raw/199_cw/. Perhaps it was a very large file and I removed it? No... I don't think that a voltage file exists--either there was a bug with the VME when we switched FFTs on the fly or we forgot to tell the VME to record voltages. (Of course, the PSD file exists, but it doesn't offer what I want.) Use file VOLT99199B-8k.1999JM8 instead: 3 runs, 1000 Hz sampling, four hops. Use a 512 point FFT to get 1.95 Hz resolution. The resulting spectrum will have a lot of looks and good noise statistics. Got OSOD seek errors. ==> I had compressed all the PRDX files. Oops... Try it again... reason:/data/ast5/1999JM8/proc/cw < 27 > dofft -d 5.0 -p 192 -f 512 -i VOLT99199B-8k.1999JM8 -o 99199B.nocal.512.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 512, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199B-8k.1999JM8 RDFOUT_1=99199B.nocal.512.1_1.rdf RDFOUT_2=99199B.nocal.512.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199B.nocal.512.1.rdf -o 99199B.nocal.512.rdf -x PRDX.OUT.s15 -p 192 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 484 Total SC spectra: 484 Processing data... reason:/data/ast5/1999JM8/proc/cw < 28 > Check the tags in tkpl: 484 looks. irun = 1 ==> Sum all the looks into one spectrum. Tsys: ch1,2 = 15.2, 16.5 K. I didn't record system temps in my electronic log for that part of the track. Fortunately Randy recorded them right after the track ended and at elevation = 25 deg: Ch1, 2 = 20.2, 21.3 K. <== Use those values. reason:/data/ast5/1999JM8/proc/cw < 30 > rdfseparate -i 99199B.nocal.512.rdf -o 99199B.nocal.512.sep Dumping frame 1 to 99199B.nocal.512.sep001.rdf Dumping frame 2 to 99199B.nocal.512.sep002.rdf reason:/data/ast5/1999JM8/proc/cw < 31 > reason:/data/ast5/1999JM8/proc/cw < 31 > cat 99199B.nocal.512.sep001.rdf 99199B.nocal.512.sep002.rdf > 99199B.nocal.512.corrected.rdf reason:/data/ast5/1999JM8/proc/cw < 32 > Other tags look OK. run through the rest of the reduction pipeline. Got another rnb.Calibrate error: rnb.Calibrate(): xmit_sta is DSS14 Default value used Using Observatory Gain Constant: 1.11452e+07 (num) Gain Const rtt tsys gain pt nfreq dfreq tau rmsc sdev rnb.Calibrate() error: rmsc is not what it should be (0.096225) setting rmsc to 0.0524864 ( 0) 1.11452e+07 97.32 21.3 650.692 425 4 1.95312 247.808 0.0524864 0.00789396 All Finished! :^) e/m values are mostly close to unity. Saw only a few less than 0.8 and none less than 0.6. file: 99199B.512.rdf Bins containing echo power and jsnr1 and 2: rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 -0 1 0 1 3 15 130 4 2 1 0 64.0 65.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 1 1 1 1 2 19 -0 1 -0 0 64.0 65.0 jsnr1 and 2 aren't set correctly. expand to jsnr1,2 = 64, 67. rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 -0 1 0 1 3 15 130 4 2 1 0 64.0 67.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 --------------------------------------------------------------------------- 1 1 1 1 1 1 2 19 -0 1 -0 0 64.0 67.0 Target unknown from file /data/ast5/1999JM8/proc/cw/99199B.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-oc 07:06:05 00:00:00 07:14:08 0.0 7.49e-03 1.14e+00 ± 8.7e-03 2.7 Target unknown from file /data/ast5/1999JM8/proc/cw/99199B.512.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-sc 07:06:05 00:00:00 07:14:08 0.0 7.89e-03 1.72e-01 ± 8.9e-03 2.5 0.150434 0.15835 0.142535 This radar cross section is the lowest that I got on any of the days. SC/OC is consistent with my earlier results. plot: 99199B.512.tpl (note that the data are actually from DOY 200, not 199. The track crossed dates.) - - - - - - - - - - Verify the normalization of the images -------------------------------------- If the normalization is OK, it will be necessary to either fix the date and dtime tags on many of the files or else repeat the reduction. Nearly three months ago I printed the C source code for acunorm.c. The comments are rather cryptic and it isn't obvious what the exclusion zone really is. The question is, does the software ignore the points containing echo power to compute the noise statistics that are then used to scale the data? That is the only logical way to do it. This boils down to: what is the exclusion zone? Is it an area that will be used to compute noise statistics or is it the region with the echo that will NOT be used to compute noise statistics? When I asked Keith previously (while working on Bacchus) he said it doesn't matter what l t r b are except that they need to have some value. He then said that they exist for targets like Geographos that occupy a significant portion of the delay-Doppler array. For weak and small targets like Bacchus, it won't matter how the exclusion zone is defined--either definition above will give results that are about the same. It's different for JM8. On several days the JM8 images occupied nearly 200 range gates and close to 25% of the delay-Doppler array, so we need to understand what acunorm is doing to get the correct normalization. Keith's description puzzles me: "The left edge of a box of pixels to ignore during normalization" Perhaps the brief description of the code explains it: "for normalizing r_images with a specified exclusion zone" That suggests to me that the zone is used to compute the noise statistics and then used to normalize the entire image. That agrees with what I'm starting to remember from a discussion with Keith--that the exclusion zone shouldn't include the image. This makes sense and it matches the approach Mike Nolan and Jean-Luc Margot said they use. 1. Try to figure out the code. The fact that it's in C makes this challenging because C is a compact language and I'm not very familiar with it. 2. Experiment with some images and compare the results with calculations done by hand. This will be more time-consuming but it should remove all doubt. think:/data/lance/1999JM8 < 49 > acunorm -h Usage: acunorm [-h][-?][-g] -i infile -o outfile -l left -t top -r right -b bottom -i infile Specifies the RDF input image file -o outfile Specifies the RDF output image file -l left The left edge of a box of pixels to ignore during normalization -t top The top edge of a box of pixels to ignore during normalization -r right The right edge of a box of pixels to ignore during normalization -b bottom The lbottom edge of a box of pixels to ignore during normalization -g Goldstone may deliver a bad gate 0 that disrupts normalization. Invoking acunorm with -g causes gate 0 to be interpolated before normalization.. -q Invoking acunorm with -q makes it run quietly. ftp jm21204.rdf -> think (acunorm isn't available on rhyme/reason). Set the exclusion zone so 1. Echo is in the exclusion zone 2. Echo is not in exclusion zone and compare results. 1. Echo in the exclusion zone ----------------------------- Use the existing Spyglass Transform file to identify where the echo is. l = 183 t = 67 r = 248 b = 245 (All counting from zero) think:/data/lance/1999JM8/Goldstone < 65 > grep "dtime" jm21204.rdf | wc 24 72 840 think:/data/lance/1999JM8/Goldstone < 66 > group_rdf jm21204.rdf jm21204.grp.rdf 1 24 think:/data/lance/1999JM8/Goldstone < 67 > sum_rdf jm21204.grp.rdf jm21204.sum.rdf think:/data/lance/1999JM8/Goldstone < 68 > acunorm -i jm21204.sum.rdf -o jm21204.nrm.rdf -l 183 -t 67 -r 248 -b 245 Image 0 Mean 1246181874.027481 sdev 254076758.659842 count 53710 think:/data/lance/1999JM8/Goldstone < 69 > rdf2spy jm21204.nrm.rdf jm21204.nrm.spy Doing the normalization this way puts the peak SNR = 53 in bin 215, gate 78. I can't compare this directly with the earlier normalization because that used jm21203 and jm21204 combined, not just jm21204. Get jm21205 (the combined file) and do a direct comparison. The peak SNR/pixel = 69.5 (file jm21205) in gate, bin = 68, 204. This image may have delay smear. Return to that later. The previous normalization had peak SNR the same pixel but the value is 28.4. Clearly the normalizations are different, but which is correct? The total number of possible points is 255x256 = 65280. Using l t r b above the number being used is 53710 or about 82%. Zone is 65 cols x 178 rows = 11570 pixels, to the number in and out of the exclusion zone match. Given that Keith's variable sumcount counts only the values used to compute the mean and standard deviation, it looks like the exclusion zone bounds the echo, not the region for the normalization. Thus, everything BUT the exclusion zone is used to compute the noise statistics. So this is the correct answer. This also means that the statistics in the VAX real-time display use all the points and do not attempt to remove the echo. So my results for the Bacchus paper were wrong in a subtle way: the exclusion zone should have encompassed the echo. Fortunately those echoes were weak enough and occupied so few pixels that it doesn't matter. ==> Go back to all the Goldstone JM8 images and correct the normalization. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I backed up the reduction log and all other files in /data/ast5/1999JM8/analysis/, all the *t87 files and *tpl (CW) files, the masterlog, and the electronic logs onto think:/data/lance/1999JM8/results_backup/ This is the first JM8 backup that I've done for at least two months. It's my intention to use think as a backup for key files on a regular basis and to use cdroms for more general backups less often. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DELAY DRIFT ==> Not obvious. See rotation instead =========== ** DELAY DRIFT: CHECK THE DOPPLER CORRECTIONS ON THE CW DATA TO ESTIMATE DRIFT ** SOME OF THE IMAGING TRACKS MAY BE LONG ENOUGH THAT WE'LL HAVE TO CORRECT ** FOR THIS. Check for it on the tracks longer than one hour. The solution 23 tracks (DOY 209, 212, and 213) are susceptible: DOY delta-t (h) --- ----------- 209 1.52 212 2.51 213 3.43 These are long enough to check for delay drift in the images by summing looks at the beginning and end and comparing the leading edges. Then compare the results with those expected from estimated CW COM Doppler corrections. DOY 212 ------- I summed and normalized the first and final ten frames from each day. There's a not-so-subtle double image in the first ten frames. It looks like we changed the txoffset in range in mid stream in the file. This is the track when I was flying to Puerto Rico. The switch probably happened in the first 2-3 runs. ==> Randy's log indicates they added a -100 gate offset after the 2nd run (2nd record). ==> Ignore the first two frames There may even be subtle rotation between the two images from the beginning and end of the track. The LE may have moved up (toward the radar) by one gate. I summed and normalized the first and last twenty frames. The second image is modestly stronger but otherwise any differences are so subtle that I don't see obvious evidence for a difference. think:/data/lance/1999JM8/Goldstone < 101 > source jm8proc Image 0 Mean 1235109079.945803 sdev 266915282.840177 count 53287 Image 0 Mean 1245754753.101957 sdev 270634500.282239 count 53287 There seems to be at least one gate of delay drift between these images. For example, the (gate,bin) = (67,204) = 1.9 in jm21205.nrm1.spy and = 28.1 in jm21205.nrm2.spy. The echo clearly moved toward the radar by about one gate. Could this instead be rotation? There may be subtle differences in the LE on the receding limb too--to my eye, it looks like there's some rotation. ==> YES. I compared points in the same row (85) in the two images and found that the right "shoulder" is steeper in the 2nd image. Perhaps the drift I mentioned before isn't drift at all but is instead rotation. If the rotation about one axis is at a period of close to 8 days, then over a span of about 2 hours there should be ~4 deg of rotation. That's consistent with what I see. The actual time difference between the mid-epochs of the two images is 1.8 hours. The amount of rotation is rather modest, so to prepare images for Scott I'm going to provide one that's sum of all the images from this day, and a set of ~3 images spanning narrower intervals. Scott can work with either format-- putting everything into one file boosts the SNR but introduces smear. Should we have expected delay drift? The Doppler correction from the 0.244 Hz res'n spectra appears to be less than 1 Hz. If the correction had been as much as 1 Hz, the delay drift should have been (1.8 h)*(0.42 us/h) = 0.8 us or about 6 1/8 us range gates. Evidently the ephemeris on this day was very good. Based on the slight rotation on DOY 212, we could see even more in the DOY 213 data that covered about an hour more time. DOY 213 ------- I was in Arecibo on this day too. I combined files jm21303 and jm21304 -> jm21305.rdf The first ~5 frames had range offsets that are less than the remaining frames, so ignore the first five frames. think:/data/lance/1999JM8/Goldstone < 105 > grep "dtime" jm21305.rdf | wc 102 306 3570 l = 171 t = 26 r = 238 b = 225 <== Means the distal arc is not in the exclusion zone Normalize the first and last 20 frames. Normalizing the images on think is very slow. think:/data/lance/1999JM8/Goldstone < 107 > source jm8proc Image 0 Mean 569419037.508229 sdev 124092230.611249 count 51947 Image 0 Mean 561548785.654302 sdev 122347950.927305 count 51947 There's clearly rotation: it's obvious if one selects the same row or column in both images (in Transform) and compares the images. For example, the apex shifts from 27,199 -> 29,202. The rotation is easier to see than in the DOY 212 images. The two images have the same number of looks but the second image is clearly not as strong. The power levels were consistent (we have a plot). Perhaps there was some other system problem, like pointing? Tsys? It's hard to believe that such a small rotation could so obviously change the echo powers. Delay drift? At most the CW echo is offset by a fraction of 1 Hz, but since the target may be somewhat asymmetric, we don't know what the drift rate should be. I don't think we can pinpoint this until we do the modeling. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PREPARE SUMMED, NORMALIZED, AND VIGNETTED IMAGES FOR SCOTT ========================================================== DOY 213 (Aug 1) --------------- There are 102 frames (looks) total. Prepare one summed and properly normalized and vignetted image from the whole track and a sequence of several images spanning narrow time intervals. To keep things simple, I'm going to vignette ALL the images so to retain only positive frequencies. Doppler frequency will increase from right to left. think:/home/lance < 44 > comvin -h Usage: comvin infile outfile xSize Ysize xcen ycen For example, xSize Ysize xcen ycen = 40 60 53 91 means 40 cols x 60 rows, centered on col 53, row 91. Does comvin count from one or zero? Do a test to find out...one I'm doing the image processing on think: most of the rdf image software was never converted to Solaris. DOY 212 (Jul 31) ---------------- There are 72 frames total, 70 at the same range offset. Make one summed image and a three-panel sequence. Each panel will have ~23 frames. Here's the script: # Sum, normalize, and vignette all the frames with the same range offset # The vignetting preserves 1/2 of the image at positive Doppler # frequencies and zero Hz is on the extreme right. group_rdf jm21205.rdf jm21205.grp.rdf 3 72 sum_rdf jm21205.grp.rdf jm21205.sum.rdf acunorm -i jm21205.sum.rdf -o jm21205.nrm.rdf -l 182 -t 66 -r 249 -b 245 comvin jm21205.nrm.rdf jm21205.nrm.vig.rdf 128 255 193 127 rdf2spy jm21205.nrm.vig.rdf jm21205.nrm.vig.spy rm *grp* rm *sum* # ---------------------------------------------------------- # Group 1 group_rdf jm21205.rdf jm21205.grp1.rdf 3 25 sum_rdf jm21205.grp1.rdf jm21205.sum1.rdf acunorm -i jm21205.sum1.rdf -o jm21205.nrm1.rdf -l 182 -t 66 -r 249 -b 245 comvin jm21205.nrm1.rdf jm21205.nrm1.vig.rdf 128 255 193 127 rdf2spy jm21205.nrm1.vig.rdf jm21205.nrm1.vig.spy rm *grp* rm *sum* # Group 2 group_rdf jm21205.rdf jm21205.grp2.rdf 26 48 sum_rdf jm21205.grp2.rdf jm21205.sum2.rdf acunorm -i jm21205.sum2.rdf -o jm21205.nrm2.rdf -l 182 -t 66 -r 249 -b 245 comvin jm21205.nrm2.rdf jm21205.nrm2.vig.rdf 128 255 193 127 rdf2spy jm21205.nrm2.vig.rdf jm21205.nrm2.vig.spy rm *grp* rm *sum* # Group 3 group_rdf jm21205.rdf jm21205.grp3.rdf 49 72 sum_rdf jm21205.grp3.rdf jm21205.sum3.rdf acunorm -i jm21205.sum3.rdf -o jm21205.nrm3.rdf -l 182 -t 66 -r 249 -b 245 comvin jm21205.nrm3.rdf jm21205.nrm3.vig.rdf 128 255 193 127 rdf2spy jm21205.nrm3.vig.rdf jm21205.nrm3.vig.spy rm *grp* rm *sum* think:/data/lance/1999JM8/Goldstone < 69 > source jm8proc Image 0 Mean 1237806329.919117 sdev 147442627.877106 count 53287 Comvin using 193.000000,127.000000 as center Image 0 Mean 1234995920.828420 sdev 255113546.363758 count 53287 Comvin using 193.000000,127.000000 as center Image 0 Mean 1232369500.020943 sdev 256884778.125134 count 53287 Comvin using 193.000000,127.000000 as center Image 0 Mean 1245709938.640794 sdev 253603645.097016 count 53287 Comvin using 193.000000,127.000000 as center I'm putting the images for Scott into a directory labelled: think:/data/lance/1999JM8/Goldstone/images_for_scott/ I checked all the DOY 212 and 213 Spyglass Transform files to verify that they're OK. ======================================================================== 1999 December 2 ======================================================================== DOY 219 (Aug 7) --------------- This was a short track: the images span just under 45 minutes. Group into one image. The first 4 looks have a different range offset relative to the other 28, so ignore the first 4 looks. To be really fancy I could vignette the first four looks in such a way to align them with the others, but it hardly seems worth it. think:/data/lance/1999JM8/Goldstone < 48 > source jm8proc Image 0 Mean 585689477.274767 sdev 84628174.180943 count 59556 Comvin using 193.000000,127.000000 as center It turns out that the previously reduced image from this day has sufficiently low SNR that my earlier incorrect quick pass at the exclusion zone still produced the right peak SNR. Something I hadn't noticed before is the elliptical feature on the approaching limb. It's about 2/3 of the way down from the LE. It might be the crater that is so prominent near the top center of the images on the next day. The DOY 220 images resemble those obtained on July 24 and August 1, so does the DOY 219 image resemble the one obtained on DOY 212? Well, it's not a great match... there seems to have been some rotation about more than one axis. The "shoulder" at negative freqs (relative to the COM) crudely resembles the one in the DOY 212 images. I tried printing the ascii array of data points using: enscript -1 -f Courier2 -r filename.spy but even with a fontsize of 2 I couldn't get all the columns in. Surprisingly, enscript did not wrap the lines, which would have been fine. Later on I'll go back and run comvin to cut the number of columns and then print the points that include the echo but with more of the positive points truncated. DOY 220 (Aug 8) --------------- This was the longest track from which we have images: more than 7 hours. I noticed rotation in the images while we were observing. We got a total of 726 looks in four files. --> Split the images into a sequence. SNR has dropped relative to DOY 212 and 213 so experiment with trade-off between durations and SNR. I took another look at images I reduced earlier. Using Spyglass Transform, I adjusted the stretch from -2.5->5 sigma to bring out weaker features. To my surprise, the large concavity is more obvious than I thought earlier and definitely easier to discern than on other days. Frankly, it looks more like a crater on this day than on any of the others. The rim of the concavity seems quite angular. Using file jm22003, the extent of the concavity is about 40 1/4 usec range gates or (40)(37.5 m) = 1.5 km. This is the largest concavity on the surface that I have been able to identify. The "distal arc" is more of a line on this day. Obviously it's a topographic high... hard to say much more. There appear to be 5 concavities in the DOY 220 images: the big one; one near the top center-right; another elliptical in shape to the lower left; a small one between the previous two just described; and possibly a fifth near the LE just left of center. The fifth resembles other craters viewed obliquely, but it could also be a chance alignment of ridges or other topography. First pass: cat the final two files (5, which has only 32 looks, and 6, which has 180) into one file, and then sum all the looks in the resulting three files into three images. That might not work: the files are too big to port to think...I need to clear some space on think:/data/lance/. The JM8 data takes up the most space, but I've also got a lot from 1992 SK and 3908 Nyx. 169 Meg total, 117 Meg of 1999JM8 files (69%). Start by getting rid of the mega Goldstone JM8 files from other days. That means that I'll need to ftp them from reason again if I want to manipulate them. I moved the files for Scott over to reason and deleted the ones I've already worked with. That liberated about 60 meg. I deleted all the Arecibo rdf files (which are on reason) and transferred the Arecibo spy files to reason. Onward... jm22003.rdf: This file is huge: 65 meg--processing is slow. think:/data/lance/1999JM8/Goldstone < 168 > source jm8proc Image 0 Mean 186499098.319827 sdev 13119291.414020 count 59232 Comvin using 193.000000,127.000000 as center I made a new plot, applied a stretch that saturates the image at 17% of the maximum (71 sigma), and stretched it horizontally to search for detail. The big concavity looks more like a crater in this image than in any of the others to date. That could be an artifact of the vertical exaggeration, or it could be real. What is the concavity? The most obvious answer is that it's an impact crater. Or...if JM8 is a pile of loosely-bound blocks, perhaps the concavity is the spot where several blocks join but don't fit well. Either situation argues for internal porosity. If it's a crater, then, combined with the several other ~1 km-sized craters we see, this raises the intriguing possibility that JM8 may be a mini-Mathilde. Steve finally agreed that this is an interesting and plausible possibility. Other explanations that don't seem plausible: 1. volcanism 2. sinkhole 3. tectonic feature 4. glacial cirque 5. sea-floor spreading 6. whole-body expansion (a la a freezing icy satellite) 7. cometary outgassing? What do those features look like? Do we know? Check the literature on comet Halley--Giotto results. 8. distortion of the surface due to planetary tides 9. junction region of a bifurated object Subdivide the image into 3 panels, each about 0.8 h long: think:/data/lance/1999JM8/Goldstone < 182 > source jm8proc Image 0 Mean 87289852.887831 sdev 9653231.513768 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 200897816.644381 sdev 24198046.749648 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 270299977.041599 sdev 29506246.783075 count 59232 Comvin using 193.000000,127.000000 as center This took about 5 minutes. jm22004.rdf think:/data/lance/1999JM8/Goldstone < 195 > source jm8proc Image 0 Mean 269234868.289843 sdev 16590789.443759 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 267339492.537007 sdev 28479085.528556 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 267899223.397083 sdev 28369639.702338 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 272465888.397623 sdev 29055437.890165 count 59232 Comvin using 193.000000,127.000000 as center jm22005 & jm22006: I catted them together to form jm22007.rdf. think:/data/lance/1999JM8/Goldstone < 209 > source jm8proc Image 0 Mean 297582765.505673 sdev 20478915.368859 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 278220900.941923 sdev 33123374.173496 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 295584395.263371 sdev 35262054.907755 count 59232 Comvin using 193.000000,127.000000 as center Image 0 Mean 319248145.726364 sdev 38060094.833201 count 59232 Comvin using 193.000000,127.000000 as center Next: the other 6 days - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I reorganized reason:/data/ast5/1999JM8/proc/cw/ I put the files from the most recent calibration into ../new_cw_files/ and moved all the previous files into ../old_cw_files/ The new files have a frequency resolution of 1.95 Hz and include noise histograms (that are probably wrong due to a bug in rdfnoisehist). The old files include earlier calibrations that have extensive chi-square noise statistics due to the much finer frequency resolution. ======================================================================== 1999 December 3 Mars Polar Lander arrives ======================================================================== DOY 209 (July 28) ----------------- The file is jm20903.rdf. It has 43 frames that span about 1.5 hours. Let's prepare one image of everything and a two-panel subset spanning 0.7-0.8 h each. think:/data/lance/1999JM8/Goldstone < 48 > source jm8proc Image 0 Mean 142113542.784520 sdev 21715175.634440 count 55142 Comvin using 193.000000,127.000000 as center Image 0 Mean 142510628.089224 sdev 30289748.576637 count 55142 Comvin using 193.000000,127.000000 as center Image 0 Mean 141697548.645896 sdev 31210486.168429 count 55142 Comvin using 193.000000,127.000000 as center The new normalization boosted the peak SNR/pixel by more than a factor of three. Evidently I could have gone to 1/8 us that day. Need to do correct normalizations right after the tracks to help make those decisions. DOY 208 (July 27) ----------------- We got only 34 looks. The images span only one hour so I'm not going to split them. think:/data/lance/1999JM8/Goldstone < 57 > source jm8proc Image 0 Mean 131343580.681973 sdev 22466375.001997 count 57580 Comvin using 193.000000,127.000000 as center Peak SNR/pixel = 33, which is similar to the previous estimate. DOY 205 (July 24) ----------------- We got 49 looks spanning 2.0 h. Prepare one summed image and two spanning about 1 hour each. I already checked the images divided into three parts back in July to look for rotational changes but I didn't see any. We probably don't have the resolution in these images. Peak SNR/pixel is 149. Should have used a finer baud. We could have run with 1/4 us or maybe even 1/8 us. *** 2000 JANUARY 3: THIS IS WRONG--THERE ARE 49 RUNS AND 191 FRAMES. *** MOST OF THE DATA HASN'T BEEN INCLUDED. See the entry for 2000 January 3 DOY 204 (July 23) ----------------- There are 68 frames that span only 0.75 hours: make one image. The first 16 frames used no range offset; the other frames used an offset of +25 usec. 16/68 = 24% of the total, which is not insignificant. Let's vignette the first 16 frames so as to align them with the others and then sum them. We need to move the center point by 25 usec or 50 gates (0.5 us/gate). Try this on the first 16 frames to see if comvin will work correctly. I modified comvin as follows: #comvin jm20403.nrm.rdf jm20403.nrm.vig.rdf 128 255 193 127 comvin jm20403.nrm.rdf jm20403.nrm.vig.rdf 128 255 193 77 That put the LE in gate 33 (counting from zero). Fortunately, Keith's comvin software is smart enough to wrap in range and Doppler. That matches the LE in the other frames, so full speed ahead. Here's the script: group_rdf jm20403.rdf jm20403.grp1.rdf 1 16 comvin jm20403.grp1.rdf jm20403.grp1.shift.rdf 256 255 193 77 group_rdf jm20403.rdf jm20403.grp2.rdf 17 68 cat jm20403.grp1.shift.rdf jm20403.grp2.rdf > jm20403.grp.rdf sum_rdf jm20403.grp.rdf jm20403.sum.rdf acunorm -i jm20403.sum.rdf -o jm20403.nrm.rdf -l 166 -t 29 -r 205 -b 79 comvin jm20403.nrm.rdf jm20403.nrm.vig.rdf 128 255 193 127 rdf2spy jm20403.nrm.vig.rdf jm20403.nrm.vig.spy rm *grp* rm *sum* This worked: the images are registered. Peak SNR = 61 vs. 52 with the normalization I did in July. ==> Onward. How good was the ephemeris on this day? The 0.244 Hz cw spectrum has its center at about +0.2 Hz and the bandwidth is about 2.4 Hz. Given that we don't know the shape, that small offset is too low to be an issue. DOY 202 (July 21) ----------------- There are 112 frames, 14 of which have no range offset. I'm going to reduce those first to see how strong they are and then decide whether or not to register them with the others. I should have been more aggressive and gone with finer resolution. These echoes are strong--we probably could have run with 0.25 us. Yow! There's a lot of echo power! ==> register with the other images. The track was only about 45 minutes long -> one image. I forgot that we inserted a Doppler offset too--try it again. No, the Doppler offset of +5 Hz was the same. This is another ghost image, probably caused by problems with i and q. There's quite a bit of echo power in the ghost image--some of the points exceed 20 sigma. This is by far the strongest ghost image I've seen in the data. We didn't notice this during the track because we zoomed in the real-time display to see the echo. The ghost echo isn't strong enough to have a significant effect (i.e. more than several sigma) on the normalization so I'm going to ignore it. The images span only 45 minutes->1 image. The peak SNR is about 180. There are several other points with echo strengths in excess of 100 sigma. I wish I had gone with at least 0.5 usec; 0.25 usec would have been even better. This is frustrating. Next time... DOY 201 (July 20) ----------------- 9 frames, SNR is low enough that a new normalization isn't really needed, but let's do it anyway to get things right and to have consistency in the vignetting of all the rdf files for Scott. This is the only day that I used a 127-element code. Here's the script: # jm20108: sum into one file group_rdf jm20108.rdf jm20108.grp.rdf 1 9 sum_rdf jm20108.grp.rdf jm20108.sum.rdf acunorm -i jm20108.sum.rdf -o jm20108.nrm.rdf -l 40 -t 35 -r 63 -b 89 comvin jm20108.nrm.rdf jm20108.nrm.vig.rdf 32 127 49 63 #rdf2spy jm20108.nrm.rdf jm20108.nrm.spy rdf2spy jm20108.nrm.vig.rdf jm20108.nrm.vig.spy rm *grp* rm *sum* think:/data/lance/1999JM8/Goldstone < 84 > source jm8proc Image 0 Mean 94086779.130410 sdev 23086656.889027 count 6886 Comvin using 49.000000,63.000000 as center ======================================================================== 1999 December 6 ======================================================================== I'm finally back to working on the Arecibo images of JM8. I realized that we have only one copy of the Caltech Baseband Recorder (CBR) data, so I copied everything from the cdrom Mike Nolan sent onto rhyme and tried to burn more CDs. I managed to burn one, but one of the OC files on the first day (Aug 1) seems to be corrupted. None of the other three cds that I burned were readable by the cdrom drives in either rhyme or reason. Steve contacted Richard Zinar about getting a new cd rom burner. So right now we have 1 cd from Nolan, 1 of our own that may be corrupted, and all the files on rhyme:/cdmaster/cdroot2/ I'm going to leave the files on /cdmaster for a while because there isn't enough space on /data/ast5/ to load all of them. Right now there is a separate file for OC and SC from each run. ======================================================================== 1999 December 13 ======================================================================== Disk space is an issue: /dev/dsk/c0t2d0s1 2118718 1013448 893400 54% /data/ast1 /dev/dsk/c0t2d0s3 2118718 1570295 336553 83% /data/ast2 rhyme:/cdmaster 1968608 1393312 378432 79% /cdmaster rhyme:/data/ast3 2077232 1613848 255664 87% /data/ast3 rhyme:/data/ast4 2077232 1490952 378560 80% /data/ast4 rhyme:/data/ast5 2077232 1696536 172976 91% /data/ast5 rhyme:/data/ast6 2082712 1449488 424952 78% /data/ast6 Recall that the CBR data is on /cdmaster/cdroot2/. Le't put all the CBR data onto /ast1 and then link it to /data/ast5/arecibo/ and then clear the files off of /cdmaster/cdroot2/...Except that I don't have write permission on /ast1. Sent Steve email asking him to change the write permission. ==> Steve cleared some space on /ast6, but it's still not enough. We can get rid of 1999 FN19, which has been backed up multiple times. Actually, let's toss the 1999 FN19 voltage files and leave everything else alone--that will release about 180 meg on top of the ~400 M Steve already made available. Here's the available space: rhyme:/data/ast6 2082712 1249520 624920 67% /data/ast6 I put all the files into: /data/ast6/1999JM8_arecibo/ and created links in /data/ast5/1999JM8/raw/. Meanwhile, let's forge ahead by checking tags on the DOY 216 (Aug 4) files. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CHECK CBR DATA TAGS =================== DOY 216 (Aug 4) --------------- Here are the files: reason:/data/ast5/1999JM8/arecibo/raw/216_rng_cbr < 52 > ls run* run19990804132600.rdf run19990804133032.rdf run19990804133504.rdf run19990804132600.sc.rdf run19990804133032.sc.rdf run19990804133504.sc.rdf run19990804132816.rdf run19990804133248.rdf run19990804132816.sc.rdf run19990804133248.sc.rdf Example of the tags from the first OC file (run19990804132600.rdf): Header: c Type Float i Height 800 # Number of range rows in image i Width 300 # Number of Doppler columns in image i Size 4 c Machine SPARC c Format RDF_Image . Tail: c DATA_TYPE PWR i freqs 18308 # Transform length i CHANS 1 i FRAMES 1 i bins 65535 # Before vignetting i IDAY 216 # Day Of Year (UTC) d DTIME 48360 # Receive start time (UTC seconds) i CODE_LEN 65535 f BW 152.590218966964 # Of original unvignetted image (Hz) f FRES 0.00833461978189667 # (Hz) f BAUDLEN 0.1 # in microseconds f INT_TIME 60 # Total receive time (seconds) i YEAR 1999 f EPH_ROW 401.33 # row in which ephemeris range lies. f EPH_COL 199.90739 # column in which ephemeris Doppler lies # 0.0 is the center of the first pixel for above. f LOOPTIME 10.1 # Closed-loop time included in EPH_ROW c EPHEMERIS /share/olda/Ephm/1999jm8.PRDX.OUT.s23 . reason:/data/ast5/1999JM8/arecibo/raw/216_rng_cbr < 55 > cat Readme.1999aug04 1999 aug 04 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 29700-30499 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies 400-699 were kept (zero-based), out of 9154 *2=18308=.00833461978189666908 Hz/px The "unvig" files kept frequencies -1000-999, to show the sign. runs were 60 s long images were scaled to sigmas using range bins 0..49 to compute mean and sigma. Mike Nolan vignetted the image from the original 65535-code array. Verify that there are 800 rows x 300 columns using rdf2spy on think: YES The echo powers are rather strange: it's common to see ~50 sigma pixels adjacent to much weaker pixels. Perhaps this is a consequence of zero- extension? The units of the pixels are apparently sigmas. YES, even though his tag says they're powers. (10 MHz)*(65535) = 0.006554 1/0.006554 = 152.59 Hz (1 accumulation) 152.59/18308 DFT = 0.008335 Hz/bin ==> CORRECT grep on the tags to verify the values. Compute dtime, eph_col, eph_row below. TAG expect get --- ------ --- height 800 800 width 300 300 freqs 18308 18308 bins 65535 65535 iday 216 216 code_len 65535 65535 bw 152.59 152.59 fres 0.0083 0.0083 baudlen 0.1 0.1 int_time 60 60 year 1999 1999 eph_row 401.33 variable--was it drifting? Wrong? See below. eph_col 199.91 199.91 looptime 10.1 10.1 ephemeris 23 23 Others to check: dtime. Double check eph_row, eph_col, and freqs Mike zero-extended the files once and then applied a discrete Fourier Transform. EPH_ROW: reason:/cdmaster/cdroot2/1999aug04 < 82 > grep "EPH_ROW " *rdf run19990804132600.rdf:f EPH_ROW 401.33 # row in which ephemeris range lies. run19990804132600.sc.rdf:f EPH_ROW 401.33 # row in which ephemeris range lies. run19990804132816.rdf:f EPH_ROW 400.53 # row in which ephemeris range lies. run19990804132816.sc.rdf:f EPH_ROW 400.53 # row in which ephemeris range lies. run19990804133032.rdf:f EPH_ROW 401.21 # row in which ephemeris range lies. run19990804133032.sc.rdf:f EPH_ROW 401.21 # row in which ephemeris range lies. run19990804133248.rdf:f EPH_ROW 401.14 # row in which ephemeris range lies. run19990804133248.sc.rdf:f EPH_ROW 401.14 # row in which ephemeris range lies. run19990804133504.rdf:f EPH_ROW 401.12 # row in which ephemeris range lies. run19990804133504.sc.rdf:f EPH_ROW 401.12 # row in which ephemeris range lies. What's going on? Did Mike try to correct for delay drift? EPH_ROW is variable on the other days too--something related to when we turned on the CBR? Tape destriping? Something wrong with the decoding? CLT? Mike's comment indicates that the CLT was involved... My memory of this is vague: ASK Mike. Clearly the time it takes to get the signal from the platform down to the control room is part of it... Something about the way that eph_delay is computed... Mike and Phil were working on this. In any case, eph_row refers to the vignetted file, not the original array. EPH_COL What was the offset? We did transmit Dopplers due to the CBR. Nolan retained zero based bins 400-699; the ephemeris column (bin) is 199.91, or 599.91 relative to zero. (599.91)*(0.008335 Hz/bin) = +5.0 Hz, which is reasonable. Unfortunately, nobody recorded the offset in the notes for this setup. DTIME run19990804132600.rdf:d DTIME 48360 # Receive start time (UTC seconds) run19990804132600.sc.rdf:d DTIME 48360 # Receive start time (UTC seconds) run19990804132816.rdf:d DTIME 48496 # Receive start time (UTC seconds) run19990804132816.sc.rdf:d DTIME 48496 # Receive start time (UTC seconds) run19990804133032.rdf:d DTIME 48632 # Receive start time (UTC seconds) run19990804133032.sc.rdf:d DTIME 48632 # Receive start time (UTC seconds) run19990804133248.rdf:d DTIME 48768 # Receive start time (UTC seconds) run19990804133248.sc.rdf:d DTIME 48768 # Receive start time (UTC seconds) run19990804133504.rdf:d DTIME 48904 # Receive start time (UTC seconds) run19990804133504.sc.rdf:d DTIME 48904 # Receive start time (UTC seconds) dtime time OK? 48360 13:26:00 yes: Mike already converted this to UTC! 48496 13:28:16 yes 48632 133032 yes 48768 133248 yes 48904 133504 yes ==> dtime values are OK. Fourier Transform length ------------------------ I don't understand how to determine how much to pad the data or how to determine what the transform length will be. For this day a 16 k transform would have given comparable results in terms of frequency resolution. OK--Here's what Mike did: the RTT was 60 seconds. We want to match one look/run, so nlooks = int_time/(1/fres) = 1 What's fres? fres = bw/fft = 1/60 sec = 0.0167 Hz. With a 60 second RTT that's the finest frequency resolution we could get without zero-extending and it would require using an FFT that is NOT in the form of 2^N. Since the bandwidth = 152.59 Hz = fres*FFT, FFT would be 9154 as Mike mentions. Using an 8192 FFT, which IS in the form 2^N, the finest frequency resolution that the unextended data can provide is 0.019 Hz. So what Mike did was to zero extend the data once--that is, to double the effective integration time by padding the data with zeros, and then he FFTed the modified file. That doubled the FFT length from 9154->18308 as advertised. According to Numerical Recipes, FFTs need to be divisible by two into integers but they do not need to be in the form of 2^N, although that format makes computation MUCH faster. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 213 (Aug 1) =============== reason:/data/ast5/1999JM8/arecibo/raw/213_rng_cbr < 253 > cat Readme.1999aug01 1999 aug 01 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 28500-30499 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies -150,149 were kept (zero-based), out of 7780*2=15560=0.009806569 Hz/px There was no transmit offset on this day, and the frequencies are reversed from other days (didn't use the PDC, and used a low-side LO on the 260-30) runs were 51 s long images were scaled to sigmas using range bins 0..49 to compute mean and sigma. The CBR was restarted in the middle, so there are two sets of data. So no offset in freq ==> eph_col should = 150 using the *vignetted* file. There are 35 runs. PDC = Planetary Down Converter 260-30 = 260 - 30 MHz mixer TAG expect get --- ------ --- height 2000 2000 width 300 300 freqs 15560 15560 bins 65535 65535 iday 213 213 code_len 65535 65535 bw 152.59 152.59 fres 0.0098 0.0098 baudlen 0.1 0.1 int_time 51 51 year 1999 1999 eph_row variable eph_col 150 150 (See below) looptime 10.1 10.1 ephemeris 21 21 dtime Mike's comment indicates these are in UTC: UTC run19990801125104.sc.rdf:d DTIME 46264 12:51:04 run19990801125302.sc.rdf:d DTIME 46382 12 53 02 run19990801125500.sc.rdf:d DTIME 46500 12 55 00 run19990801125658.sc.rdf:d DTIME 46618 12 56 58 run19990801125856.sc.rdf:d DTIME 46736 12 58 56 run19990801130054.sc.rdf:d DTIME 46854 13 00 54 run19990801130252.sc.rdf:d DTIME 46972 13 02 52 run19990801130450.sc.rdf:d DTIME 47090 13 04 50 run19990801130648.sc.rdf:d DTIME 47208 13 06 48 run19990801130846.sc.rdf:d DTIME 47326 13 08 46 run19990801131044.sc.rdf:d DTIME 47444 13 10 44 ...gap of four runs... run19990801132601.sc.rdf:d DTIME 48361 13 26 01 run19990801132759.sc.rdf:d DTIME 48479 13 27 59 run19990801132957.sc.rdf:d DTIME 48597 13 29 57 run19990801133155.sc.rdf:d DTIME 48715 13 31 55 run19990801133353.sc.rdf:d DTIME 48833 13 33 53 run19990801133551.sc.rdf:d DTIME 48951 13 35 51 run19990801133749.sc.rdf:d DTIME 49069 13 37 49 run19990801133947.sc.rdf:d DTIME 49187 13 39 47 run19990801134145.sc.rdf:d DTIME 49305 13 41 45 run19990801134343.sc.rdf:d DTIME 49423 13 43 43 run19990801134541.sc.rdf:d DTIME 49541 13 45 41 run19990801134739.sc.rdf:d DTIME 49659 13 47 39 run19990801134937.sc.rdf:d DTIME 49777 13 49 37 run19990801135135.sc.rdf:d DTIME 49895 13 51 35 run19990801135333.sc.rdf:d DTIME 50013 13 53 33 The dtime values all check out OK. eph_row ------- These values bounce around somewhat but otherwise steadily increase from 1533->1548. Let's ask Mike. This got a lot better later in the week--there was much less variation. Registering these images will be a pain. eph_col ------- Mike counted eph_col from zero using the *vignetted* image, not from the unvignetted original. ======================================================================== 1999 December 14 ======================================================================== DOY 214 (AUG 2) =============== reason:/data/ast5/1999JM8/arecibo/raw/214_rng_cbr < 18 > cat Readme.1999aug02 1999 aug 02 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 29500-30999 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies -650,-351 were kept (zero-based), out of 8086*2=16172=0.009435458 Hz/px The "unvig" files kept frequencies -1000-999, to show the sign. runs were 53 s long images were scaled to sigmas using range bins 0..49 to compute mean and sigma. TAG expect get --- ------ --- Height 1500 1500 Width 300 300 freqs 16172 16172 bins 65535 65535 IDAY 214 214 CODE_LEN 65535 65535 BW 152.59 152.59 FRES 0.0094 0.0094 BAUDLEN 0.1 0.1 INT_TIME 53 53 YEAR 1999 1999 EPH_ROW variable EPH_COL 178.92 178.92 See below. LOOPTIME 10.1 10.1 EPHEMERIS 23 23 FFT === 8086*2 = 16172 checks out. (1/53)/2 = 0.0094 which matches Mike's result. EPH_ROW ======= This is variable again and it increases as a function of time. I hope the situation in the GSB data is better. EPH_COL ======= Mike retained bins -650 -> -351. i.e., 300 Doppler bins. The center relative to the unvignetted file is -500. So the center bin of the *vignetted* file is 150, but that's not the ephemeris Doppler: Mike states it's 178.92. Shouldn't it be 150? Evidently there was a tx offset... (78 bins)*(0.0094 Hz/bin) = 0.74 Hz? The log sheet says the offset was +5 Hz. The setup file also indicates +5 Hz. What's going on? I would expect: (+5 Hz)/(0.0094 Hz/bin) = +529.9 bins. OK...Now I understand. With the +5 Hz offset and counting from zero, not one, that would put the ephemeris col at 29 bins relative to original bin -500 or +29 relative to bin 150 in the vigentted file. The echo is clearly offset to the right in the image--so bin 179 seems to be near the middle, although not dead-on. DTIME ===== UTC run19990802130204.sc.rdf:d DTIME 46924 13:02:04 run19990802130406.sc.rdf:d DTIME 47046 13 04 06 run19990802130608.sc.rdf:d DTIME 47168 13 06 08 run19990802130810.sc.rdf:d DTIME 47290 13 08 10 run19990802131012.sc.rdf:d DTIME 47412 13 10 12 run19990802131214.sc.rdf:d DTIME 47534 13 12 14 run19990802131416.sc.rdf:d DTIME 47656 13 14 16 run19990802131618.sc.rdf:d DTIME 47778 13 16 18 run19990802131820.sc.rdf:d DTIME 47900 13 18 20 run19990802132022.sc.rdf:d DTIME 48022 13 20 22 run19990802132224.sc.rdf:d DTIME 48144 13 22 24 run19990802132426.sc.rdf:d DTIME 48266 13 24 26 run19990802132628.sc.rdf:d DTIME 48388 13 26 28 run19990802132830.sc.rdf:d DTIME 48510 13 28 30 run19990802133032.sc.rdf:d DTIME 48632 13 30 32 run19990802133234.sc.rdf:d DTIME 48754 13 32 34 run19990802133436.sc.rdf:d DTIME 48876 13 34 36 run19990802133638.sc.rdf:d DTIME 48998 13 36 38 run19990802133840.sc.rdf:d DTIME 49120 13 38 40 run19990802134042.sc.rdf:d DTIME 49242 13 40 42 run19990802134244.sc.rdf:d DTIME 49364 13 42 44 run19990802134446.sc.rdf:d DTIME 49486 13 44 46 run19990802134648.sc.rdf:d DTIME 49608 13 46 48 run19990802134850.sc.rdf:d DTIME 49730 13 48 50 run19990802135052.sc.rdf:d DTIME 49852 13 50 52 run19990802135254.sc.rdf:d DTIME 49974 13 52 54 run19990802135456.sc.rdf:d DTIME 50096 13 54 56 run19990802135658.sc.rdf:d DTIME 50218 13 56 58 These values are all correct. The first file has not been normalized! Check a few others...I checked three more, scattered throughout the total number of files. They aren't normalized. ==> No big deal--just use acunorm. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 214 (Aug 3) =============== reason:/data/ast6/1999JM8_arecibo/1999aug03 < 15 > cat Readme.1999aug03 1999 aug 03 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 29700-30499 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies 400-699 were kept (zero-based), out of 8544 *2=17090=0.008929671 Hz/px The "unvig" files kept frequencies -1000-999, to show the sign. runs were 56 s long images were scaled to sigmas using range bins 0..49 to compute mean and sigma. ==> THE IMAGES ARE *NOT* NORMALIZED! <== TAG expect get --- ------ --- Height 800 800 Width 300 300 freqs 17090 17090 bins 65535 65535 IDAY 215 215 CODE_LEN 65535 65535 BW 152.59 152.59 FRES 0.0089 0.0089 BAUDLEN 0.1 0.1 INT_TIME 56 56 YEAR 1999 1999 EPH_ROW variable EPH_COL 160.0 160.0 LOOPTIME 10.1 10.1 EPHEMERIS 23 23 fres looks OK. EPH_ROW ======= This varies by less than two range gates. Much better than on Aug 1 and 2. EPH_COL ======= The setup file indicates we used a +5 Hz txoffset. So the center freq in the unvignetted file should be: #bins = (+5 Hz)/(0.008930 Hz/bin) = 560 bins Mike retained bins 400-699 (zero-based), so the midpoint is (400 + 699)/2 = 549.5 or about 550. So the eph col should be at about +10 bins relative to that. In the vignetted frame, expect eph_col at about 160. ==> That's where it is. DTIME ===== UTC run19990803124312.sc.rdf:d DTIME 45792 12:43:12 run19990803124520.sc.rdf:d DTIME 45920 12 45 20 run19990803124728.sc.rdf:d DTIME 46048 12 47 28 run19990803124936.sc.rdf:d DTIME 46176 12 49 36 run19990803125144.sc.rdf:d DTIME 46304 12 51 44 run19990803125352.sc.rdf:d DTIME 46432 12 53 52 run19990803125600.sc.rdf:d DTIME 46560 12 56 00 run19990803125808.sc.rdf:d DTIME 46688 12 58 08 run19990803130016.sc.rdf:d DTIME 46816 13 00 16 run19990803130224.sc.rdf:d DTIME 46944 13 02 24 run19990803130432.sc.rdf:d DTIME 47072 13 04 32 run19990803130640.sc.rdf:d DTIME 47200 13 06 40 run19990803130848.sc.rdf:d DTIME 47328 13 08 48 run19990803131056.sc.rdf:d DTIME 47456 13 10 56 run19990803131304.sc.rdf:d DTIME 47584 13 13 04 run19990803131512.sc.rdf:d DTIME 47712 13 15 12 run19990803131720.sc.rdf:d DTIME 47840 13 17 20 run19990803131928.sc.rdf:d DTIME 47968 13 19 28 run19990803132136.sc.rdf:d DTIME 48096 13 21 36 run19990803132344.sc.rdf:d DTIME 48224 13 23 44 run19990803132552.sc.rdf:d DTIME 48352 13 25 52 run19990803132800.sc.rdf:d DTIME 48480 13 28 00 run19990803133008.sc.rdf:d DTIME 48608 13 30 08 run19990803133216.sc.rdf:d DTIME 48736 13 32 16 run19990803133424.sc.rdf:d DTIME 48864 13 34 24 run19990803133632.sc.rdf:d DTIME 48992 13 36 32 run19990803133840.sc.rdf:d DTIME 49120 13 38 40 run19990803134048.sc.rdf:d DTIME 49248 13 40 48 run19990803134256.sc.rdf:d DTIME 49376 13 42 56 run19990803134504.sc.rdf:d DTIME 49504 13 45 04 run19990803134900.sc.rdf:d DTIME 49740 13 49 00 dtime values are OK. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 217 (Aug 5) =============== reason:/data/ast6/1999JM8_arecibo/1999aug05 < 65 > cat Readme.1999aug05 1999 aug 05 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 29700-30499 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies 500-799 were kept (zero-based), out of 9764*2=19528=.007813919 Hz/bin. The "unvig" files kept frequencies -1000 -999, to show the sign. runs were 64s long. THESE IMAGES ARE NOT NORMALIZED TAG expect get --- ------ --- Height 800 800 Width 300 300 freqs 19528 19528 bins 65535 65535 IDAY 217 217 CODE_LEN 65535 65535 BW 152.59 152.59 FRES 0.0078 0.0078 BAUDLEN 0.1 0.1 INT_TIME 64 64 YEAR 1999 1999 EPH_ROW VARIABLE: see below EPH_COL 139.88 139.88 LOOPTIME 10.1 10.1 EPHEMERIS 26 26 FRES ==== 1/(64*2) = 0.00781 Hz/bin which agrees with what Mike got. EPH_ROW ======= The value again varies within a few tenths of a gate around row 401. We won't have to worry about registering the looks in these data. EPH_COL ======= There are 300 bins: 500-799 (zero based). The logfile (which is included as part of the setup file) indicates that TXoff = +5 Hz. #bins = (+5 Hz)/(0.007814 Hz/bin) = 639.9 bins in the unvignetted file. 640-500 = 140 = eph_col in the vignetted file--matches Mike's result. DTIME ===== UTC run19990805115814.sc.rdf:d DTIME 43094 11:58:14 run19990805120038.sc.rdf:d DTIME 43238 12 00 38 run19990805120302.sc.rdf:d DTIME 43382 12 03 02 run19990805120526.sc.rdf:d DTIME 43526 12 05 26 run19990805120750.sc.rdf:d DTIME 43670 12 07 50 run19990805121014.sc.rdf:d DTIME 43814 12 10 14 run19990805121238.sc.rdf:d DTIME 43958 12 12 38 run19990805121502.sc.rdf:d DTIME 44102 12 15 02 run19990805121726.sc.rdf:d DTIME 44246 12 17 26 run19990805121950.sc.rdf:d DTIME 44390 12 19 50 run19990805122214.sc.rdf:d DTIME 44534 12 22 14 run19990805122438.sc.rdf:d DTIME 44678 12 24 38 run19990805122702.sc.rdf:d DTIME 44822 12 27 02 run19990805122926.sc.rdf:d DTIME 44966 12 29 26 run19990805123150.sc.rdf:d DTIME 45110 12 31 50 run19990805123414.sc.rdf:d DTIME 45254 12 34 14 run19990805123638.sc.rdf:d DTIME 45398 12 36 38 run19990805123902.sc.rdf:d DTIME 45542 12 39 02 run19990805124126.sc.rdf:d DTIME 45686 12 41 26 run19990805124350.sc.rdf:d DTIME 45830 12 43 50 run19990805124614.sc.rdf:d DTIME 45974 12 46 14 run19990805124838.sc.rdf:d DTIME 46118 12 48 38 run19990805125102.sc.rdf:d DTIME 46262 12 51 02 run19990805125326.sc.rdf:d DTIME 46406 12 53 26 run19990805125550.sc.rdf:d DTIME 46550 12 55 50 run19990805125814.sc.rdf:d DTIME 46694 12 58 14 run19990805130038.sc.rdf:d DTIME 46838 13 00 38 run19990805130302.sc.rdf:d DTIME 46982 13 03 02 run19990805130526.sc.rdf:d DTIME 47126 13 05 26 run19990805130750.sc.rdf:d DTIME 47270 13 07 50 run19990805131014.sc.rdf:d DTIME 47414 13 10 14 run19990805131238.sc.rdf:d DTIME 47558 13 12 38 run19990805131502.sc.rdf:d DTIME 47702 13 15 02 run19990805131726.sc.rdf:d DTIME 47846 13 17 26 run19990805131950.sc.rdf:d DTIME 47990 13 19 50 dtime values are OK. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 218 (Aug 6) =============== reason:/data/ast6/1999JM8_arecibo/1999aug06 < 80 > cat Readme.1999aug06 1999 aug 06 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 29700-30499 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies 500-899 were kept (zero-based), out of 10375 *2=20750=0.007353745 Hz/px The "unvig" files kept frequencies -1000-999, to show the sign. runs were 68 s long images were scaled to sigmas using range bins 0..49 to compute mean and sigma. THESE IMAGES ARE NOT NORMALIZED TAG expect get --- ------ --- Height 800 800 Width 400 400 freqs 20750 20750 bins 65535 65535 IDAY 218 218 CODE_LEN 65535 65535 BW 152.59 152.59 FRES 0.0074 0.0074 BAUDLEN 0.1 0.1 INT_TIME 68 68 YEAR 1999 1999 EPH_ROW VARIABLE: see below EPH_COL 180 180 LOOPTIME 10.1 10.1 EPHEMERIS 26 26 FRES ==== (1/[68*2]) = 0.00735 Hz which is what Mike used. EPH_ROW ======= EPH_ROW varies by about +/- 0.3 gates. EPH_COL ======= Mike kept freqs 500-899 (zero based). The logfile indicates that we used txoff = +5 Hz. #bins = (5 Hz)/(0.00735) = 680.3 bins which is eph_col in the unvignetted file. In the vignetted file, eph_col = 680.3 - 500 = 180.3 Mike got 180, so they're consistent. DTIME ===== UTC run19990806123350.sc.rdf:d DTIME 45230 12:33:50 run19990806123622.sc.rdf:d DTIME 45382 12 36 22 run19990806123854.sc.rdf:d DTIME 45534 12 38 54 run19990806124126.sc.rdf:d DTIME 45686 12 41 26 run19990806124358.sc.rdf:d DTIME 45838 12 43 58 run19990806124630.sc.rdf:d DTIME 45990 12 46 30 run19990806124902.sc.rdf:d DTIME 46142 12 49 02 run19990806125134.sc.rdf:d DTIME 46294 12 51 34 run19990806125406.sc.rdf:d DTIME 46446 12 54 06 run19990806125638.sc.rdf:d DTIME 46598 12 56 38 run19990806125910.sc.rdf:d DTIME 46750 12 59 10 run19990806130142.sc.rdf:d DTIME 46902 13 01 42 run19990806130414.sc.rdf:d DTIME 47054 13 04 14 run19990806130646.sc.rdf:d DTIME 47206 13 06 46 The last file doesn't have any data--the asteroid was out of the beam. I deleted that file from /data/ast6/1999JM8_arecibo/1999aug06/ reason:/data/ast6/1999JM8_arecibo/1999aug06 < 86 > rm run*130646* rm: run19990806130646.rdf: override protection 444 (yes/no)? yes rm: run19990806130646.sc.rdf: override protection 444 (yes/no)? yes Note: I used the SC files out of convenience with the display. Duh... I just realized that the filenames Mike used include rcsta. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 221 (Aug 9) =============== reason:/data/ast6/1999JM8_arecibo/1999aug09 < 106 > cat Readme.1999aug09 1999 aug 09 1999 JM8 These files were take from CBR data 2-bit sampled at 10 MHz. The files ending in sc are the same-sense data, the unlabeled ones are opposite-sense. The data were decoded (using an idl procedure and fftw 2.2.1). The .lags files contain the decoded data containing lags 29700-30499 (zero-based). The images are full-run ffts, zero-filled once. fft frequencies 600-999 were kept (zero-based), out of 12664*2=25328=.00602456644689530233 Hz/bin. The last run was longer: fft length 12816*2=25632 = .00595311403585222446 Hz/bin The "unvig" files kept frequencies -1000-999, to show the sign. runs were 83s long, except for the last one 84s THESE DATA ARE NOT NORMALIZED There are 26 good runs, 25 with the same frequency resolution. Due to the difference in resolution, let's ignore the last run. reason:/data/ast6/1999JM8_arecibo/1999aug09 < 125 > rm *120226* rm: run19990809120226.rdf: override protection 444 (yes/no)? yes rm: run19990809120226.sc.rdf: override protection 444 (yes/no)? yes TAG expect get --- ------ --- Height 800 800 Width 400 400 freqs 25328 25328 bins 65535 65535 IDAY 221 221 CODE_LEN 65535 65535 BW 152.59 152.59 FRES 0.0060 0.0060 BAUDLEN 0.1 0.1 INT_TIME 83 83 YEAR 1999 1999 EPH_ROW 401 401 EPH_COL 230 230 LOOPTIME 10.1 10.1 EPHEMERIS 26 26 FRES ==== 1/[83*2] = 0.0060 Hz EPH_COL ======= Mike retained 600-999. txoff = +5 Hz, so #bins = (5 Hz)/(0.0060246 Hz/bin) = 830 bins in the unvignetted image. In the vignetted image eph_col should = 830-600 = 230 which agrees with what Mike got. EPH_ROW ======= eph_row varies by +/- about 0.3 gates, centered on #401 (counting from zero). DTIME ===== run19990809104635.sc.rdf:d DTIME 38795 10:46:35 run19990809104937.sc.rdf:d DTIME 38977 10 49 37 run19990809105239.sc.rdf:d DTIME 39159 10 52 39 run19990809105541.sc.rdf:d DTIME 39341 10 55 41 run19990809105843.sc.rdf:d DTIME 39523 10 58 43 run19990809110145.sc.rdf:d DTIME 39705 11 01 45 run19990809110447.sc.rdf:d DTIME 39887 11 04 47 run19990809110749.sc.rdf:d DTIME 40069 11 07 49 run19990809111051.sc.rdf:d DTIME 40251 11 10 51 run19990809111353.sc.rdf:d DTIME 40433 11 13 53 run19990809111655.sc.rdf:d DTIME 40615 11 16 55 run19990809111957.sc.rdf:d DTIME 40797 11 19 57 run19990809112259.sc.rdf:d DTIME 40979 11 22 59 run19990809112601.sc.rdf:d DTIME 41161 11 26 01 run19990809112903.sc.rdf:d DTIME 41343 11 29 03 run19990809113205.sc.rdf:d DTIME 41525 11 32 05 run19990809113507.sc.rdf:d DTIME 41707 11 35 07 run19990809113809.sc.rdf:d DTIME 41889 11 38 09 run19990809114111.sc.rdf:d DTIME 42071 11 41 11 run19990809114413.sc.rdf:d DTIME 42253 11 44 13 run19990809114715.sc.rdf:d DTIME 42435 11 47 15 run19990809115017.sc.rdf:d DTIME 42617 11 50 17 run19990809115319.sc.rdf:d DTIME 42799 11 53 19 run19990809115621.sc.rdf:d DTIME 42981 11 56 21 run19990809115923.sc.rdf:d DTIME 43163 11 59 23 These values are all OK. =========================================================== GROUP THE CBR FILES INTO ONE FILE/DAY AND NORMALIZE THEM -------------------------------------------------------- The key point here is eph_row: it varied by up to 10 gates on some days, but less than one gate at the end of the eperiment. eph_row DOY variation --- --------- 213 1533-1548 214 579-611 Registration will be a nuisance 215 +/- 0.5 216 0.4 217 0.5 218 0.3 221 0.3 The final five days are easy: just cat, sum, and normalize. The first two days will require more work. Here are eph_row for DOY 213 and 214: 1999aug01/run19990801125104.sc.rdf:f EPH_ROW 1533.12 # row in which ephemeris range lies. 1999aug01/run19990801125302.sc.rdf:f EPH_ROW 1533.99 # row in which ephemeris range lies. 1999aug01/run19990801125500.sc.rdf:f EPH_ROW 1533.99 # row in which ephemeris range lies. 1999aug01/run19990801125658.sc.rdf:f EPH_ROW 1533.6 # row in which ephemeris range lies. 1999aug01/run19990801125856.sc.rdf:f EPH_ROW 1535.35 # row in which ephemeris range lies. 1999aug01/run19990801130054.sc.rdf:f EPH_ROW 1535.31 # row in which ephemeris range lies. 1999aug01/run19990801130252.sc.rdf:f EPH_ROW 1534.57 # row in which ephemeris range lies. 1999aug01/run19990801130450.sc.rdf:f EPH_ROW 1535.98 # row in which ephemeris range lies. 1999aug01/run19990801130648.sc.rdf:f EPH_ROW 1535.62 # row in which ephemeris range lies. 1999aug01/run19990801130846.sc.rdf:f EPH_ROW 1535.51 # row in which ephemeris range lies. 1999aug01/run19990801131044.sc.rdf:f EPH_ROW 1536.62 # row in which ephemeris range lies. 1999aug01/run19990801132601.sc.rdf:f EPH_ROW 1540.65 # row in which ephemeris range lies. 1999aug01/run19990801132759.sc.rdf:f EPH_ROW 1542.37 # row in which ephemeris range lies. 1999aug01/run19990801132957.sc.rdf:f EPH_ROW 1542.32 # row in which ephemeris range lies. 1999aug01/run19990801133155.sc.rdf:f EPH_ROW 1543.44 # row in which ephemeris range lies. 1999aug01/run19990801133353.sc.rdf:f EPH_ROW 1541.58 # row in which ephemeris range lies. 1999aug01/run19990801133551.sc.rdf:f EPH_ROW 1542.84 # row in which ephemeris range lies. 1999aug01/run19990801133749.sc.rdf:f EPH_ROW 1544.08 # row in which ephemeris range lies. 1999aug01/run19990801133947.sc.rdf:f EPH_ROW 1545.37 # row in which ephemeris range lies. 1999aug01/run19990801134145.sc.rdf:f EPH_ROW 1543.57 # row in which ephemeris range lies. 1999aug01/run19990801134343.sc.rdf:f EPH_ROW 1544.73 # row in which ephemeris range lies. 1999aug01/run19990801134541.sc.rdf:f EPH_ROW 1544.79 # row in which ephemeris range lies. 1999aug01/run19990801134739.sc.rdf:f EPH_ROW 1545.71 # row in which ephemeris range lies. 1999aug01/run19990801134937.sc.rdf:f EPH_ROW 1547.46 # row in which ephemeris range lies. 1999aug01/run19990801135135.sc.rdf:f EPH_ROW 1547.02 # row in which ephemeris range lies. 1999aug01/run19990801135333.sc.rdf:f EPH_ROW 1548.3 # row in which ephemeris range lies. 1999aug02/run19990802130204.sc.rdf:f EPH_ROW 578.87 # row in which ephemeris range lies. 1999aug02/run19990802130406.sc.rdf:f EPH_ROW 580.21 # row in which ephemeris range lies. 1999aug02/run19990802130608.sc.rdf:f EPH_ROW 581.16 # row in which ephemeris range lies. 1999aug02/run19990802130810.sc.rdf:f EPH_ROW 581.86 # row in which ephemeris range lies. 1999aug02/run19990802131012.sc.rdf:f EPH_ROW 584.18 # row in which ephemeris range lies. 1999aug02/run19990802131214.sc.rdf:f EPH_ROW 585.14 # row in which ephemeris range lies. 1999aug02/run19990802131416.sc.rdf:f EPH_ROW 584.63 # row in which ephemeris range lies. 1999aug02/run19990802131618.sc.rdf:f EPH_ROW 585.73 # row in which ephemeris range lies. 1999aug02/run19990802131820.sc.rdf:f EPH_ROW 588.35 # row in which ephemeris range lies. 1999aug02/run19990802132022.sc.rdf:f EPH_ROW 589.44 # row in which ephemeris range lies. 1999aug02/run19990802132224.sc.rdf:f EPH_ROW 590.01 # row in which ephemeris range lies. 1999aug02/run19990802132426.sc.rdf:f EPH_ROW 591.01 # row in which ephemeris range lies. 1999aug02/run19990802132628.sc.rdf:f EPH_ROW 593.35 # row in which ephemeris range lies. 1999aug02/run19990802132830.sc.rdf:f EPH_ROW 594.07 # row in which ephemeris range lies. 1999aug02/run19990802133032.sc.rdf:f EPH_ROW 595.09 # row in which ephemeris range lies. 1999aug02/run19990802133234.sc.rdf:f EPH_ROW 596.31 # row in which ephemeris range lies. 1999aug02/run19990802133436.sc.rdf:f EPH_ROW 596.73 # row in which ephemeris range lies. 1999aug02/run19990802133638.sc.rdf:f EPH_ROW 598.3 # row in which ephemeris range lies. 1999aug02/run19990802133840.sc.rdf:f EPH_ROW 598.96 # row in which ephemeris range lies. 1999aug02/run19990802134042.sc.rdf:f EPH_ROW 599.65 # row in which ephemeris range lies. 1999aug02/run19990802134244.sc.rdf:f EPH_ROW 602.31 # row in which ephemeris range lies. 1999aug02/run19990802134446.sc.rdf:f EPH_ROW 603.9 # row in which ephemeris range lies. 1999aug02/run19990802134648.sc.rdf:f EPH_ROW 605.33 # row in which ephemeris range lies. 1999aug02/run19990802134850.sc.rdf:f EPH_ROW 607.48 # row in which ephemeris range lies. 1999aug02/run19990802135052.sc.rdf:f EPH_ROW 608.4 # row in which ephemeris range lies. 1999aug02/run19990802135254.sc.rdf:f EPH_ROW 608.98 # row in which ephemeris range lies. 1999aug02/run19990802135456.sc.rdf:f EPH_ROW 610.06 # row in which ephemeris range lies. 1999aug02/run19990802135658.sc.rdf:f EPH_ROW 610.71 # row in which ephemeris range lies. GROUP THE IMAGES INTO ONE FILE/DAY ================================== Start with the easiest day with the fewest runs: Aug 4 DOY 216 (Aug 4) --------------- 5 runs, each 952 k = 4.8 Meg. reason:/data/ast6/1999JM8_arecibo/1999aug04 < 26 > du -ks *rdf 952 run19990804132600.rdf 952 run19990804132600.sc.rdf 952 run19990804132816.rdf 952 run19990804132816.sc.rdf 952 run19990804133032.rdf 952 run19990804133032.sc.rdf 952 run19990804133248.rdf 952 run19990804133248.sc.rdf 952 run19990804133504.rdf 952 run19990804133504.sc.rdf cat run19990804132600.rdf run19990804133248.rdf run19990804133032.rdf run19990804132816.rdf run19990804133504.rdf > jm8.cbr.990804.rdf cat run19990804132600.sc.rdf run19990804133248.sc.rdf run19990804133032.sc.rdf run19990804132816.sc.rdf run19990804133504.sc.rdf > jm8.cbr.990804.sc.rdf Now delete the individual files to recover space...done DOY 218 (Aug 6) --------------- OC: cat run19990806123350.rdf run19990806123622.rdf run19990806123854.rdf run19990806124126.rdf run19990806124358.rdf run19990806124630.rdf run19990806124902.rdf run19990806125134.rdf run19990806125406.rdf run19990806125638.rdf run19990806125910.rdf run19990806130142.rdf run19990806130414.rdf > jm8.990806.cbr.rdf SC: cat run19990806123350.sc.rdf run19990806123622.sc.rdf run19990806123854.sc.rdf run19990806124126.sc.rdf run19990806124358.sc.rdf run19990806124630.sc.rdf run19990806124902.sc.rdf run19990806125134.sc.rdf run19990806125406.sc.rdf run19990806125638.sc.rdf run19990806125910.sc.rdf run19990806130142.sc.rdf run19990806130414.sc.rdf > jm8.990806.cbr.sc.rdf All my xterm windows vanished when I deleted the run*rdf files... ?? DOY 221 (Aug 9) --------------- OC cat run19990809104635.rdf run19990809104937.rdf run19990809105239.rdf run19990809105541.rdf run19990809105843.rdf run19990809110145.rdf run19990809110447.rdf run19990809110749.rdf run19990809111051.rdf run19990809111353.rdf run19990809111655.rdf run19990809111957.rdf run19990809112259.rdf run19990809112601.rdf run19990809112903.rdf run19990809113205.rdf run19990809113507.rdf run19990809113809.rdf run19990809114111.rdf run19990809114413.rdf run19990809114715.rdf run19990809115017.rdf run19990809115319.rdf run19990809115621.rdf run19990809115923.rdf > jm8.990809.cbr.rdf SC cat run19990809104635.sc.rdf run19990809104937.sc.rdf run19990809105239.sc.rdf run19990809105541.sc.rdf run19990809105843.sc.rdf run19990809110145.sc.rdf run19990809110447.sc.rdf run19990809110749.sc.rdf run19990809111051.sc.rdf run19990809111353.sc.rdf run19990809111655.sc.rdf run19990809111957.sc.rdf run19990809112259.sc.rdf run19990809112601.sc.rdf run19990809112903.sc.rdf run19990809113205.sc.rdf run19990809113507.sc.rdf run19990809113809.sc.rdf run19990809114111.sc.rdf run19990809114413.sc.rdf run19990809114715.sc.rdf run19990809115017.sc.rdf run19990809115319.sc.rdf run19990809115621.sc.rdf run19990809115923.sc.rdf > jm8.990809.cbr.sc.rdf DOY 213 (Aug 01) ---------------- OC cat run19990801125104.rdf run19990801130846.rdf run19990801133947.rdf run19990801125302.rdf run19990801131044.rdf run19990801134145.rdf run19990801125500.rdf run19990801132601.rdf run19990801134343.rdf run19990801125658.rdf run19990801132759.rdf run19990801134541.rdf run19990801125856.rdf run19990801132957.rdf run19990801134739.rdf run19990801130054.rdf run19990801133155.rdf run19990801134937.rdf run19990801130252.rdf run19990801133353.rdf run19990801135135.rdf run19990801130450.rdf run19990801133551.rdf run19990801135333.rdf run19990801130648.rdf run19990801133749.rdf > jm8.990801.cbr.rdf SC cat run19990801125104.sc.rdf run19990801130846.sc.rdf run19990801133947.sc.rdf run19990801125302.sc.rdf run19990801131044.sc.rdf run19990801134145.sc.rdf run19990801125500.sc.rdf run19990801132601.sc.rdf run19990801134343.sc.rdf run19990801125658.sc.rdf run19990801132759.sc.rdf run19990801134541.sc.rdf run19990801125856.sc.rdf run19990801132957.sc.rdf run19990801134739.sc.rdf run19990801130054.sc.rdf run19990801133155.sc.rdf run19990801134937.sc.rdf run19990801130252.sc.rdf run19990801133353.sc.rdf run19990801135135.sc.rdf run19990801130450.sc.rdf run19990801133551.sc.rdf run19990801135333.sc.rdf run19990801130648.sc.rdf run19990801133749.sc.rdf > jm8.990801.cbr.sc.rdf DOY 214 (Aug 02) ---------------- OC cat run19990802130204.rdf run19990802133032.rdf run19990802130406.rdf run19990802133234.rdf run19990802130608.rdf run19990802133436.rdf run19990802130810.rdf run19990802133638.rdf run19990802131012.rdf run19990802133840.rdf run19990802131214.rdf run19990802134042.rdf run19990802131416.rdf run19990802134244.rdf run19990802131618.rdf run19990802134446.rdf run19990802131820.rdf run19990802134648.rdf run19990802132022.rdf run19990802134850.rdf run19990802132224.rdf run19990802135052.rdf run19990802132426.rdf run19990802135254.rdf run19990802132628.rdf run19990802135456.rdf run19990802132830.rdf run19990802135658.rdf > jm8.990802.cbr.rdf SC cat run19990802130204.sc.rdf run19990802133032.sc.rdf run19990802130406.sc.rdf run19990802133234.sc.rdf run19990802130608.sc.rdf run19990802133436.sc.rdf run19990802130810.sc.rdf run19990802133638.sc.rdf run19990802131012.sc.rdf run19990802133840.sc.rdf run19990802131214.sc.rdf run19990802134042.sc.rdf run19990802131416.sc.rdf run19990802134244.sc.rdf run19990802131618.sc.rdf run19990802134446.sc.rdf run19990802131820.sc.rdf run19990802134648.sc.rdf run19990802132022.sc.rdf run19990802134850.sc.rdf run19990802132224.sc.rdf run19990802135052.sc.rdf run19990802132426.sc.rdf run19990802135254.sc.rdf run19990802132628.sc.rdf run19990802135456.sc.rdf run19990802132830.sc.rdf run19990802135658.sc.rdf > jm8.990802.cbr.sc.rdf I screwed this up: I accidentally deleted the *sc.rdf files before I had catted them all. Get the others off the CDrom. ======================================================================== 1999 December 15 ======================================================================== I recopied the original rdf files from the cdrom and catted everything together. Richard Zinar is updating software on think to make it y2k compliant so I may need to use intruder to sum and normalize the images. DOY 215 (Aug 03) ---------------- OC cat run19990803124312.rdf run19990803124520.rdf run19990803124728.rdf run19990803124936.rdf run19990803125144.rdf run19990803125352.rdf run19990803125600.rdf run19990803125808.rdf run19990803130016.rdf run19990803130224.rdf run19990803130432.rdf run19990803130640.rdf run19990803130848.rdf run19990803131056.rdf run19990803131304.rdf run19990803131512.rdf run19990803131720.rdf run19990803131928.rdf run19990803132136.rdf run19990803132344.rdf run19990803132552.rdf run19990803132800.rdf run19990803133008.rdf run19990803133216.rdf run19990803133424.rdf run19990803133632.rdf run19990803133840.rdf run19990803134048.rdf run19990803134256.rdf run19990803134504.rdf run19990803134900.rdf > jm8.990803.cbr.rdf SC cat run19990803124312.sc.rdf run19990803124520.sc.rdf run19990803124728.sc.rdf run19990803124936.sc.rdf run19990803125144.sc.rdf run19990803125352.sc.rdf run19990803125600.sc.rdf run19990803125808.sc.rdf run19990803130016.sc.rdf run19990803130224.sc.rdf run19990803130432.sc.rdf run19990803130640.sc.rdf run19990803130848.sc.rdf run19990803131056.sc.rdf run19990803131304.sc.rdf run19990803131512.sc.rdf run19990803131720.sc.rdf run19990803131928.sc.rdf run19990803132136.sc.rdf run19990803132344.sc.rdf run19990803132552.sc.rdf run19990803132800.sc.rdf run19990803133008.sc.rdf run19990803133216.sc.rdf run19990803133424.sc.rdf run19990803133632.sc.rdf run19990803133840.sc.rdf run19990803134048.sc.rdf run19990803134256.sc.rdf run19990803134504.sc.rdf run19990803134900.sc.rdf > jm8.990803.cbr.sc.rdf DOY 217 (Aug 05) ---------------- OC cat run19990805115814.rdf run19990805120038.rdf run19990805120302.rdf run19990805120526.rdf run19990805120750.rdf run19990805121014.rdf run19990805121238.rdf run19990805121502.rdf run19990805121726.rdf run19990805121950.rdf run19990805122214.rdf run19990805122438.rdf run19990805122702.rdf run19990805122926.rdf run19990805123150.rdf run19990805123414.rdf run19990805123638.rdf run19990805123902.rdf run19990805124126.rdf run19990805124350.rdf run19990805124614.rdf run19990805124838.rdf run19990805125102.rdf run19990805125326.rdf run19990805125550.rdf run19990805125814.rdf run19990805130038.rdf run19990805130302.rdf run19990805130526.rdf run19990805130750.rdf run19990805131014.rdf run19990805131238.rdf run19990805131502.rdf run19990805131726.rdf run19990805131950.rdf > jm8.990805.cbr.rdf SC cat run19990805115814.sc.rdf run19990805120038.sc.rdf run19990805120302.sc.rdf run19990805120526.sc.rdf run19990805120750.sc.rdf run19990805121014.sc.rdf run19990805121238.sc.rdf run19990805121502.sc.rdf run19990805121726.sc.rdf run19990805121950.sc.rdf run19990805122214.sc.rdf run19990805122438.sc.rdf run19990805122702.sc.rdf run19990805122926.sc.rdf run19990805123150.sc.rdf run19990805123414.sc.rdf run19990805123638.sc.rdf run19990805123902.sc.rdf run19990805124126.sc.rdf run19990805124350.sc.rdf run19990805124614.sc.rdf run19990805124838.sc.rdf run19990805125102.sc.rdf run19990805125326.sc.rdf run19990805125550.sc.rdf run19990805125814.sc.rdf run19990805130038.sc.rdf run19990805130302.sc.rdf run19990805130526.sc.rdf run19990805130750.sc.rdf run19990805131014.sc.rdf run19990805131238.sc.rdf run19990805131502.sc.rdf run19990805131726.sc.rdf run19990805131950.sc.rdf > jm8.990805.cbr.sc.rdf 15:04--I entered "ls" and my xterm vanished again. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Richard Zinar forgot to check on the size of think's system hard drive and discovered, after he'd wiped the old system, that the new one wouldn't fit: the drive is too small. So that means we probably won't have access to think or create until Richard gets a new, larger drive tomorrow morning. Why didn't he think to check that before he wiped the drive? He even mentioned that he'd encountered this problem before (although several years ago). Thus, in order to do any rdf image processing, I need to use intruder, which uses old versions of some of the software. What a pain. All this came about because Richard is installing a somewhat newer system 4.4.x onto think in order to make it Y2k compliant. When I asked him what might fail if we didn't do the patch he couldn't answer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Let's do the processing on intruder:/export/data0/rosema/1999JM8/proc Start with Aug 4 first because that's the file on that date is the smallest: it's only 4.7 Meg. Be sure to check the year tag on the normalized files. Also need to use rdf2spy to locate where the echo is in each image in order to set the boundary of the exclusion zone. Unfortunately, my master script is on think too...but fortunately I copied part of it into my log above. # reason:/data/ast5/1999JM8/arecibo/proc/rng/jm8.ao.proc # # Lance A. M. Benner # Created: 1999 December 15 # Modified:1999 December 15 # # This script is designed to be run on intruder.gdscc.nasa.gov, which # has an older version of acunorm than the one available on # think.jpl.nasa.gov. # Sum, normalize, and vignette all the frames with the same range offset # 1999 Aug 04 (DOY 216) group_rdf jm8.cbr.990804.rdf jm8.cbr.990804.grp.rdf 1 5 sum_rdf jm8.cbr.990804.grp.rdf jm8.cbr.990804.sum.rdf acunorm jm8.cbr.990804.sum.rdf jm8.cbr.990804.nrm.rdf 182 66 249 245 rdf2spy jm8.cbr.990804.nrm.rdf jm8.cbr.990804.nrm.spy #rm *grp* #rm *sum* I'm editing this on reason and then ftping it to intruder. lance@intruder:/tmp_mnt/home/lance [17] source jm8.ao.proc Image 0 Mean 0.262777 sdev 1.892277 count 228007 Recall that image registration is no problem from DOY 215 onward. It's a drag on DOY 213 and 214 because eph_row varied. I ftped the *spy file back to JPL, displayed it to set l t r b, and then repeated the reduction with the corrrect exclusion zone. Here's the modified script: # 1999 Aug 04 (DOY 216) # Sum, normalize, and vignette all the frames with the same range offset # l t r b = 127 268 265 619 define a rectangle that encloses the echo group_rdf jm8.cbr.990804.rdf jm8.cbr.990804.grp.rdf 1 5 sum_rdf jm8.cbr.990804.grp.rdf jm8.cbr.990804.sum.rdf acunorm jm8.cbr.990804.sum.rdf jm8.cbr.990804.nrm.rdf 127 268 265 619 rdf2spy jm8.cbr.990804.nrm.rdf jm8.cbr.990804.nrm.spy rm *grp* rm *sum* lance@intruder:/tmp_mnt/home/lance [24] source jm8.ao.proc Image 0 Mean -0.000953 sdev 0.445475 count 191562 Put these files in: reason:/data/ast5/1999JM8/arecibo/proc/rng/images_for_scott/ Setting the exclusion zone properly boosted the max SNR/pxl by about a factor of 5. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 215 (Aug 03) ---------------- This file has 31 looks and it's large: 30 Meg. It's taking a long time to ftp to intruder. This is going to take a long time to normalize too. Here's the script: # 1999 Aug 03 (DOY 215) # Sum, normalize, and vignette all the frames with the same range offset # l t r b = 83 267 204 602 define a rectangle that encloses the echo group_rdf jm8.990803.cbr.rdf jm8.990803.cbr.grp.rdf 1 31 sum_rdf jm8.990803.cbr.grp.rdf jm8.990803.cbr.sum.rdf acunorm jm8.990803.cbr.sum.rdf jm8.990803.cbr.nrm.rdf 83 267 204 602 rdf2spy jm8.990803.cbr.nrm.rdf jm8.990803.cbr.nrm.spy rm *grp* rm *sum* lance@intruder:/tmp_mnt/home/lance [13] source jm8.ao.proc Image 0 Mean 4128162991.929171 sdev 742742338.457548 count 199465 Actually, normalization took only a couple of minutes. The peak SNR/pixel exceeds 1000! Image appears to be slightly smeared--possibly due to the eph_row problem--recall that it varied by +/- 0.5 gates on this day. There may be some subtle rotational smear too. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 217 (Aug 05) ---------------- file: jm8.990805.cbr.rdf reason:/data/ast6/1999JM8_arecibo/1999aug05 < 5 > grep "DTIME " *sc.rdf | wc 35 315 1925 # 1999 Aug 05 (DOY 217) # Sum, normalize, and vignette all the frames with the same range offset # l t r b = 83 267 204 602 define a rectangle that encloses the echo group_rdf jm8.990805.cbr.rdf jm8.990805.cbr.grp.rdf 1 35 sum_rdf jm8.990805.cbr.grp.rdf jm8.990805.cbr.sum.rdf acunorm jm8.990805.cbr.sum.rdf jm8.990805.cbr.nrm.rdf 62 201 208 562 rdf2spy jm8.990805.cbr.nrm.rdf jm8.990805.cbr.nrm.spy rm *grp* rm *sum* lance@intruder:/tmp_mnt/home/lance [22] source jm8.ao.proc Image 0 Mean 4716134380.761113 sdev 796180194.267568 count 187294 This is the really nice image that "looks like an asteroid." It's one of the four included in the press release. The craters are much more obvious than in the press release image--we'll be able to count them better than I expected. There's a hint of range smear again. The peak SNR/pixel is about 670. Wow. In retrospect, Mike Nolan was right to zero-extend once. This image requires using a logarithmic stretch to view THE DOPPLER SENSE IS THE REVERSE OF JEAN-LUC'S IMAGES - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 218 (Aug 06) ---------------- There are 13 looks. #group_rdf jm8.990806.cbr.rdf jm8.990806.cbr.grp.rdf 1 13 #sum_rdf jm8.990806.cbr.grp.rdf jm8.990806.cbr.sum.rdf #acunorm jm8.990806.cbr.sum.rdf jm8.990806.cbr.nrm.rdf 93 130 241 559 #rdf2spy jm8.990806.cbr.nrm.rdf jm8.990806.cbr.nrm.spy #rm *grp* #rm *sum* lance@intruder:/tmp_mnt/home/lance [33] source jm8.ao.proc Image 0 Mean 6322496629.808723 sdev 1754605261.528195 count 256508 Peak SNR/pixel is about 210. See many craters--should be able to match them with craters seen on other days. Not as many as on Aug 5, though. We have only about 1/3 the number of looks and the target was farther away--not as much detail, despite the marginally higher freq resn. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 221 (Aug 09) ---------------- There are 25 looks. # 1999 Aug 09 (DOY 221) # Sum, normalize, and vignette all the frames with the same range offset # l t r b = 83 267 204 602 define a rectangle that encloses the echo group_rdf jm8.990809.cbr.rdf jm8.990809.cbr.grp.rdf 1 25 sum_rdf jm8.990809.cbr.grp.rdf jm8.990809.cbr.sum.rdf acunorm jm8.990809.cbr.sum.rdf jm8.990809.cbr.nrm.rdf 132 196 315 571 rdf2spy jm8.990809.cbr.nrm.rdf jm8.990809.cbr.nrm.spy rm *grp* rm *sum* This image has more detail than the one from the Golevka box. The prominent concavity just below the LE looks like a crater that has had its sides truncated by subsequent impacts. There appears to be a topographic high near the center of the concavity-- but I doubt it's a central peak--I don't think we'd get those with such small craters on such a small object. More likely it's something on the "other" hemisphere that is superimposed. NEAT! ======================================================================== 1999 December 16 & 17 ======================================================================== DOY 213 (Aug 01) ---------------- Due to the drift in eph_row, summing this image will require a bit of effort. In effect, this is the same as removing delay drift, as I did with the Bacchus images. reason:/data/ast6/1999JM8_arecibo/1999aug01 < 23 > grep "EPH_ROW " *sc.rdf f EPH_ROW 1533.12 # row in which ephemeris range lies. f EPH_ROW 1535.51 # row in which ephemeris range lies. f EPH_ROW 1545.37 # row in which ephemeris range lies. f EPH_ROW 1533.99 # row in which ephemeris range lies. f EPH_ROW 1536.62 # row in which ephemeris range lies. f EPH_ROW 1543.57 # row in which ephemeris range lies. f EPH_ROW 1533.99 # row in which ephemeris range lies. f EPH_ROW 1540.65 # row in which ephemeris range lies. f EPH_ROW 1544.73 # row in which ephemeris range lies. f EPH_ROW 1533.6 # row in which ephemeris range lies. f EPH_ROW 1542.37 # row in which ephemeris range lies. f EPH_ROW 1544.79 # row in which ephemeris range lies. f EPH_ROW 1535.35 # row in which ephemeris range lies. f EPH_ROW 1542.32 # row in which ephemeris range lies. f EPH_ROW 1545.71 # row in which ephemeris range lies. f EPH_ROW 1535.31 # row in which ephemeris range lies. f EPH_ROW 1543.44 # row in which ephemeris range lies. f EPH_ROW 1547.46 # row in which ephemeris range lies. f EPH_ROW 1534.57 # row in which ephemeris range lies. f EPH_ROW 1541.58 # row in which ephemeris range lies. f EPH_ROW 1547.02 # row in which ephemeris range lies. f EPH_ROW 1535.98 # row in which ephemeris range lies. f EPH_ROW 1542.84 # row in which ephemeris range lies. f EPH_ROW 1548.3 # row in which ephemeris range lies. f EPH_ROW 1535.62 # row in which ephemeris range lies. f EPH_ROW 1544.08 # row in which ephemeris range lies. The mean is 1540.30 and the maximum excursions are + 8 and -7.2 gates Use comvin to center the echoes at some value and then add a tag to the data file indicating what I did. Use the mean value of 1540 as the standard. Note that we can shift only in increments of whole gates, so adopt appropriate rounding up rules. Let's tabulate the change for each frame to remove all ambiguity: shift by frame difference n gates ----- ---------- -------- 1 EPH_ROW 1533.12 6.9 +7 2 EPH_ROW 1535.51 4.49 +4 3 EPH_ROW 1545.37 -5.4 -5 4 EPH_ROW 1533.99 6.0 +6 5 EPH_ROW 1536.62 3.4 +3 6 EPH_ROW 1543.57 -3.6 -4 7 EPH_ROW 1533.99 6.0 +6 8 EPH_ROW 1540.65 -0.7 -1 9 EPH_ROW 1544.73 -4.7 -5 10 EPH_ROW 1533.6 6.4 +6 11 EPH_ROW 1542.37 -2.4 -2 12 EPH_ROW 1544.79 -4.79 -5 13 EPH_ROW 1535.35 4.65 +5 14 EPH_ROW 1542.32 -2.3 -2 15 EPH_ROW 1545.71 -5.7 -6 16 EPH_ROW 1535.31 4.7 +5 17 EPH_ROW 1543.44 -3.4 -3 18 EPH_ROW 1547.46 -7.46 -7 19 EPH_ROW 1534.57 5.4 +5 20 EPH_ROW 1541.58 -1.6 -2 21 EPH_ROW 1547.02 -7.0 -7 22 EPH_ROW 1535.98 4.0 +4 23 EPH_ROW 1542.84 -2.84 -3 24 EPH_ROW 1548.3 -8.3 -8 25 EPH_ROW 1535.62 4.38 +4 26 EPH_ROW 1544.08 -4.1 -4 This is a huge rdf file--it's taking a long time to transfer to intruder for processing (rdf software on think isn't available yet due to the patches Richard is installing). The file is about 62 Meg. Yikes! I wish Mike Nolan had vignetted it more tightly (each frame is 300 Doppler bins x 2000 range gates). The file took about 20 minutes to ftp. I'm testing comvin on just two frames to start and then I'll go on to the rest. lance@intruder:/tmp_mnt/home/lance [11] source jm8.ao.proc Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Image 0 Mean 0.096044 sdev 1.851726 count 537000 Image 0 Mean 0.107165 sdev 2.017557 count 537000 the comvin output puzzles me. The center values don't seem to be right. ?? The *spy files are each 3.5 Meg. eek... net connections today are slow. Here's the first attempt: group_rdf jm8.990801.cbr.rdf jm8.990801.cbr.grp1.rdf 1 1 group_rdf jm8.990801.cbr.rdf jm8.990801.cbr.grp2.rdf 2 2 comvin jm8.990801.cbr.grp1.rdf jm8.990801.cbr.grp1.vig.rdf 300 2000 150 1547 comvin jm8.990801.cbr.grp2.rdf jm8.990801.cbr.grp2.vig.rdf 300 2000 150 1544 #sum_rdf jm8.990801.cbr.grp.rdf jm8.990801.cbr.sum.rdf acunorm jm8.990801.cbr.grp1.vig.rdf jm8.990801.cbr.nrm1.rdf 132 196 315 571 acunorm jm8.990801.cbr.grp2.vig.rdf jm8.990801.cbr.nrm2.rdf 132 196 315 571 rdf2spy jm8.990801.cbr.nrm1.rdf jm8.990801.cbr.nrm1.spy rdf2spy jm8.990801.cbr.nrm2.rdf jm8.990801.cbr.nrm2.spy This didn't do what I expected: the echoes are near the bottom of the frame and they're partially wrapped in range (i.e. the distal arc appears at the top of the frame). The LE in the two images seems to differ by a few gates. Should have tried this with the frames showing the most offset to really isolate it. frame LE (using ~10 sigma points as a threshold) ----- ------------------------------------------ 1 1747 (zero based) 2 1749 (zero based) 1 1747 24 1760 OK, I'm not doing this right. Rats. Yes: eph_row may be ~1540, but that's not where the images are centered. It would make more sense to move the center point relative to the middle row of the image, not relative to row 1540. Richard got think working again so let's do all this there. think:/data doesn't have enough space, so do this on /public/protected/lance/1999JM8/ instead. Back up a bit: do the image reduction on think without using comvin. It's possible that the software on intruder couldn't handle such large numbers of rows and columns. Think is running even more slowly than intruder. Current value New value 1 825 (zero based) 832 24 838 (zero based) 830 So adjusting the center gate using comvin should get the LE registered to within a couple of gates. So this won't be perfect but it'll be tolerable. One unsettling question: what if Mike Nolan didn't compute eph_row correctly? We might not be able to tell except by doing checks like this one and looking for gross discrepancies. Onward... 1 818 24 846 The signs above are reversed. Do it again one more time... (this is taking about 10 minutes to work with two frames). So once I get this going, I should work on intruder for Aug 2==> ftp the file to intruder NOW. 1 832 24 830 Bingo. The script took about 20 minutes to run. DOY 214 (Aug 02) ---------------- Modify the DOY 213 script and run it on intruder. I already ftped the file over. There are 28 runs. Mean: 594.65. Round up to 595. diff shift by ---- -------- 1 EPH_ROW 578.87 16.1 -16 2 EPH_ROW 595.09 -0.1 0 3 EPH_ROW 580.21 14.8 -15 4 EPH_ROW 596.31 -1.3 +1 5 EPH_ROW 581.16 13.8 -14 6 EPH_ROW 596.73 -1.7 +2 7 EPH_ROW 581.86 13.1 -13 8 EPH_ROW 598.3 -3.3 +3 9 EPH_ROW 584.18 10.8 -11 10 EPH_ROW 598.96 -4.0 +4 11 EPH_ROW 585.14 9.9 -10 12 EPH_ROW 599.65 -4.7 +5 13 EPH_ROW 584.63 10.4 -10 14 EPH_ROW 602.31 -7.3 +7 15 EPH_ROW 585.73 9.3 -9 16 EPH_ROW 603.9 -8.9 +9 17 EPH_ROW 588.35 6.7 -7 18 EPH_ROW 605.33 -10.3 +10 19 EPH_ROW 589.44 5.6 -6 20 EPH_ROW 607.48 -12.48 +12 21 EPH_ROW 590.01 5.0 -5 22 EPH_ROW 608.4 -13.4 +13 23 EPH_ROW 591.01 4.0 -4 24 EPH_ROW 608.98 -14.0 +14 25 EPH_ROW 593.35 1.7 -2 26 EPH_ROW 610.06 -15.1 +15 27 EPH_ROW 594.07 0.9 +1 28 EPH_ROW 610.71 -15.7 +16 This took about 15 minutes to run on intruder--modestly faster than on think. Here's the script (Note: there are bugs! I didn't realize that when I ran this): group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp1.rdf 1 1 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp2.rdf 2 2 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp3.rdf 3 3 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp4.rdf 4 4 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp5.rdf 5 5 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp6.rdf 6 6 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp7.rdf 7 7 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp8.rdf 8 8 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp9.rdf 9 9 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp10.rdf 10 10 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp11.rdf 11 11 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp12.rdf 12 12 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp13.rdf 13 13 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp14.rdf 14 14 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp15.rdf 15 15 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp16.rdf 16 16 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp17.rdf 17 17 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp18.rdf 18 18 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp19.rdf 19 19 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp20.rdf 20 20 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp21.rdf 21 21 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp22.rdf 22 22 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp23.rdf 23 23 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp24.rdf 24 24 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp25.rdf 25 25 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 26 26 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 27 27 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 28 28 comvin jm8.990802.cbr.grp1.rdf jm8.990802.cbr.vig1.rdf 300 1500 150 734 comvin jm8.990802.cbr.grp2.rdf jm8.990802.cbr.vig2.rdf 300 1500 150 750 comvin jm8.990802.cbr.grp3.rdf jm8.990802.cbr.vig3.rdf 300 1500 150 735 comvin jm8.990802.cbr.grp4.rdf jm8.990802.cbr.vig4.rdf 300 1500 150 751 comvin jm8.990802.cbr.grp5.rdf jm8.990802.cbr.vig5.rdf 300 1500 150 736 comvin jm8.990802.cbr.grp6.rdf jm8.990802.cbr.vig6.rdf 300 1500 150 752 comvin jm8.990802.cbr.grp7.rdf jm8.990802.cbr.vig7.rdf 300 1500 150 737 comvin jm8.990802.cbr.grp8.rdf jm8.990802.cbr.vig8.rdf 300 1500 150 753 comvin jm8.990802.cbr.grp9.rdf jm8.990802.cbr.vig9.rdf 300 1500 150 739 comvin jm8.990802.cbr.grp10.rdf jm8.990802.cbr.vig10.rdf 300 1500 150 754 comvin jm8.990802.cbr.grp11.rdf jm8.990802.cbr.vig11.rdf 300 1500 150 740 comvin jm8.990802.cbr.grp12.rdf jm8.990802.cbr.vig12.rdf 300 1500 150 755 comvin jm8.990802.cbr.grp13.rdf jm8.990802.cbr.vig13.rdf 300 1500 150 740 comvin jm8.990802.cbr.grp14.rdf jm8.990802.cbr.vig14.rdf 300 1500 150 757 comvin jm8.990802.cbr.grp15.rdf jm8.990802.cbr.vig15.rdf 300 1500 150 741 comvin jm8.990802.cbr.grp16.rdf jm8.990802.cbr.vig16.rdf 300 1500 150 759 comvin jm8.990802.cbr.grp17.rdf jm8.990802.cbr.vig17.rdf 300 1500 150 743 comvin jm8.990802.cbr.grp18.rdf jm8.990802.cbr.vig18.rdf 300 1500 150 760 comvin jm8.990802.cbr.grp19.rdf jm8.990802.cbr.vig19.rdf 300 1500 150 746 comvin jm8.990802.cbr.grp20.rdf jm8.990802.cbr.vig20.rdf 300 1500 150 762 comvin jm8.990802.cbr.grp21.rdf jm8.990802.cbr.vig21.rdf 300 1500 150 745 comvin jm8.990802.cbr.grp22.rdf jm8.990802.cbr.vig22.rdf 300 1500 150 763 comvin jm8.990802.cbr.grp23.rdf jm8.990802.cbr.vig23.rdf 300 1500 150 746 comvin jm8.990802.cbr.grp24.rdf jm8.990802.cbr.vig24.rdf 300 1500 150 764 comvin jm8.990802.cbr.grp25.rdf jm8.990802.cbr.vig25.rdf 300 1500 150 748 comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig26.rdf 300 1500 150 765 comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig27.rdf 300 1500 150 749 comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig28.rdf 300 1500 150 766 cat jm8.990802.cbr.vig1.rdf jm8.990802.cbr.vig2.rdf jm8.990802.cbr.vig3.rdf jm8.990802.cbr.vig4.rdf jm8.990802.cbr.vig5.rdf jm8.990802.cbr.vig6.rdf jm8.990802.cbr.vig7.rdf jm8.990802.cbr.vig8.rdf jm8.990802.cbr.vig9.rdf jm8.990802.cbr.vig10.rdf jm8.990802.cbr.vig11.rdf jm8.990802.cbr.vig12.rdf jm8.990802.cbr.vig13.rdf jm8.990802.cbr.vig14.rdf jm8.990802.cbr.vig15.rdf jm8.990802.cbr.vig16.rdf jm8.990802.cbr.vig17.rdf jm8.990802.cbr.vig18.rdf jm8.990802.cbr.vig19.rdf jm8.990802.cbr.vig20.rdf jm8.990802.cbr.vig21.rdf jm8.990802.cbr.vig22.rdf jm8.990802.cbr.vig23.rdf jm8.990802.cbr.vig24.rdf jm8.990802.cbr.vig25.rdf jm8.990802.cbr.vig26.rdf jm8.990802.cbr.vig27.rdf jm8.990802.cbr.vig28.rdf> jm8.990802.cbr.vig.rdf sum_rdf jm8.990802.cbr.vig.rdf jm8.990802.cbr.sum.rdf acunorm jm8.990802.cbr.sum.rdf jm8.990802.cbr.nrm.rdf 98 381 231 936 rdf2spy jm8.990802.cbr.nrm.rdf jm8.990802.cbr.nrm.spy rm *grp* rm *vig* rm *sum* lance@intruder:/tmp_mnt/home/lance [39] source jm8.ao.aug2.proc Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Comvin using 475.000000,78.000000 as center Image 0 Mean 4616486622.647219 sdev 5782545966.443227 count 376185 ==> The normalized image doesn't look right: I think that the registration ==> is wrong. The image looks smeared and the peak SNR/pixel is only about 35; ==> it should be several hundred. Hey-what's the deal with the comvin output? ==> it's not using the centers that I specified. Run this on think instead. Let's double check that the images with the largest initial eph_row offsets are registering correctly, and run this on think. Doing this on think has the result that comvin outputs the correct center points. Shoot--did I use comvin on any of the other days? ==> NO. comvin on intruder has a bug! Abandon image reduction on intruder... Check the leading edges without using comvin to register the images: Frame LE ----- --- 1 470 28 472 This is puzzling: the difference should have been about 32 gates. Did Mike already correct for the differences? It turns out that some of the script was wrong. Try it again... think:/public/protected/lance/1999JM8/arecibo < 147 > group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp1.rdf 1 1 think:/public/protected/lance/1999JM8/arecibo < 148 > group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp28.rdf 28 28 think:/public/protected/lance/1999JM8/arecibo < 149 > comvin jm8.990802.cbr.grp1.rdf jm8.990802.cbr.vig1.rdf 300 1500 150 734 Comvin using 150.000000,734.000000 as center think:/public/protected/lance/1999JM8/arecibo < 150 > comvin jm8.990802.cbr.grp28.rdf jm8.990802.cbr.vig28.rdf 300 1500 150 766 Comvin using 150.000000,766.000000 as center think:/public/protected/lance/1999JM8/arecibo < 151 > acunorm -i jm8.990802.cbr.vig1.rdf -o jm8.990802.cbr.nrm1.rdf -l 98 -t 381 -r 231 -b 936 Image 0 Mean 3839894729.312627 sdev 3827196651.573207 count 376185 think:/public/protected/lance/1999JM8/arecibo < 152 > acunorm -i jm8.990802.cbr.vig28.rdf -o jm8.990802.cbr.nrm28.rdf -l 98 -t 381 -r 231 -b 936 Image 0 Mean 4077812004.792430 sdev 4067332671.969527 count 376185 This matches the LE to within 2-3 gates. The reason for the discrepancy before was that I'm tired and that I didn't realized that I had corrected for the differences in eph_row. OK...fire away with the script again. For the record, here it is: group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp1.rdf 1 1 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp2.rdf 2 2 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp3.rdf 3 3 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp4.rdf 4 4 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp5.rdf 5 5 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp6.rdf 6 6 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp7.rdf 7 7 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp8.rdf 8 8 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp9.rdf 9 9 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp10.rdf 10 10 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp11.rdf 11 11 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp12.rdf 12 12 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp13.rdf 13 13 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp14.rdf 14 14 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp15.rdf 15 15 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp16.rdf 16 16 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp17.rdf 17 17 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp18.rdf 18 18 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp19.rdf 19 19 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp20.rdf 20 20 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp21.rdf 21 21 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp22.rdf 22 22 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp23.rdf 23 23 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp24.rdf 24 24 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp25.rdf 25 25 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp26.rdf 26 26 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp27.rdf 27 27 group_rdf jm8.990802.cbr.rdf jm8.990802.cbr.grp28.rdf 28 28 comvin jm8.990802.cbr.grp1.rdf jm8.990802.cbr.vig1.rdf 300 1500 150 734 comvin jm8.990802.cbr.grp2.rdf jm8.990802.cbr.vig2.rdf 300 1500 150 750 comvin jm8.990802.cbr.grp3.rdf jm8.990802.cbr.vig3.rdf 300 1500 150 735 comvin jm8.990802.cbr.grp4.rdf jm8.990802.cbr.vig4.rdf 300 1500 150 751 comvin jm8.990802.cbr.grp5.rdf jm8.990802.cbr.vig5.rdf 300 1500 150 736 comvin jm8.990802.cbr.grp6.rdf jm8.990802.cbr.vig6.rdf 300 1500 150 752 comvin jm8.990802.cbr.grp7.rdf jm8.990802.cbr.vig7.rdf 300 1500 150 737 comvin jm8.990802.cbr.grp8.rdf jm8.990802.cbr.vig8.rdf 300 1500 150 753 comvin jm8.990802.cbr.grp9.rdf jm8.990802.cbr.vig9.rdf 300 1500 150 739 comvin jm8.990802.cbr.grp10.rdf jm8.990802.cbr.vig10.rdf 300 1500 150 754 comvin jm8.990802.cbr.grp11.rdf jm8.990802.cbr.vig11.rdf 300 1500 150 740 comvin jm8.990802.cbr.grp12.rdf jm8.990802.cbr.vig12.rdf 300 1500 150 755 comvin jm8.990802.cbr.grp13.rdf jm8.990802.cbr.vig13.rdf 300 1500 150 740 comvin jm8.990802.cbr.grp14.rdf jm8.990802.cbr.vig14.rdf 300 1500 150 757 comvin jm8.990802.cbr.grp15.rdf jm8.990802.cbr.vig15.rdf 300 1500 150 741 comvin jm8.990802.cbr.grp16.rdf jm8.990802.cbr.vig16.rdf 300 1500 150 759 comvin jm8.990802.cbr.grp17.rdf jm8.990802.cbr.vig17.rdf 300 1500 150 743 comvin jm8.990802.cbr.grp18.rdf jm8.990802.cbr.vig18.rdf 300 1500 150 760 comvin jm8.990802.cbr.grp19.rdf jm8.990802.cbr.vig19.rdf 300 1500 150 746 comvin jm8.990802.cbr.grp20.rdf jm8.990802.cbr.vig20.rdf 300 1500 150 762 comvin jm8.990802.cbr.grp21.rdf jm8.990802.cbr.vig21.rdf 300 1500 150 745 comvin jm8.990802.cbr.grp22.rdf jm8.990802.cbr.vig22.rdf 300 1500 150 763 comvin jm8.990802.cbr.grp23.rdf jm8.990802.cbr.vig23.rdf 300 1500 150 746 comvin jm8.990802.cbr.grp24.rdf jm8.990802.cbr.vig24.rdf 300 1500 150 764 comvin jm8.990802.cbr.grp25.rdf jm8.990802.cbr.vig25.rdf 300 1500 150 748 comvin jm8.990802.cbr.grp26.rdf jm8.990802.cbr.vig26.rdf 300 1500 150 765 comvin jm8.990802.cbr.grp27.rdf jm8.990802.cbr.vig27.rdf 300 1500 150 749 comvin jm8.990802.cbr.grp28.rdf jm8.990802.cbr.vig28.rdf 300 1500 150 766 cat jm8.990802.cbr.vig1.rdf jm8.990802.cbr.vig2.rdf jm8.990802.cbr.vig3.rdf jm8.990802.cbr.vig4.rdf jm8.990802.cbr.vig5.rdf jm8.990802.cbr.vig6.rdf jm8.990802.cbr.vig7.rdf jm8.990802.cbr.vig8.rdf jm8.990802.cbr.vig9.rdf jm8.990802.cbr.vig10.rdf jm8.990802.cbr.vig11.rdf jm8.990802.cbr.vig12.rdf jm8.990802.cbr.vig13.rdf jm8.990802.cbr.vig14.rdf jm8.990802.cbr.vig15.rdf jm8.990802.cbr.vig16.rdf jm8.990802.cbr.vig17.rdf jm8.990802.cbr.vig18.rdf jm8.990802.cbr.vig19.rdf jm8.990802.cbr.vig20.rdf jm8.990802.cbr.vig21.rdf jm8.990802.cbr.vig22.rdf jm8.990802.cbr.vig23.rdf jm8.990802.cbr.vig24.rdf jm8.990802.cbr.vig25.rdf jm8.990802.cbr.vig26.rdf jm8.990802.cbr.vig27.rdf jm8.990802.cbr.vig28.rdf> jm8.990802.cbr.vig.rdf sum_rdf jm8.990802.cbr.vig.rdf jm8.990802.cbr.sum.rdf acunorm -i jm8.990802.cbr.sum.rdf -o jm8.990802.cbr.nrm.rdf -l 98 -t 381 -r 231 -b 936 rdf2spy jm8.990802.cbr.nrm.rdf jm8.990802.cbr.nrm.spy rm *grp* rm *vig* rm *sum* think:/public/protected/lance/1999JM8/arecibo < 169 > source jm8.ao.aug2.proc Comvin using 150.000000,734.000000 as center Comvin using 150.000000,750.000000 as center Comvin using 150.000000,735.000000 as center Comvin using 150.000000,751.000000 as center Comvin using 150.000000,736.000000 as center Comvin using 150.000000,752.000000 as center Comvin using 150.000000,737.000000 as center Comvin using 150.000000,753.000000 as center Comvin using 150.000000,739.000000 as center Comvin using 150.000000,754.000000 as center Comvin using 150.000000,740.000000 as center Comvin using 150.000000,755.000000 as center Comvin using 150.000000,740.000000 as center Comvin using 150.000000,757.000000 as center Comvin using 150.000000,741.000000 as center Comvin using 150.000000,759.000000 as center Comvin using 150.000000,743.000000 as center Comvin using 150.000000,760.000000 as center Comvin using 150.000000,746.000000 as center Comvin using 150.000000,762.000000 as center Comvin using 150.000000,745.000000 as center Comvin using 150.000000,763.000000 as center Comvin using 150.000000,746.000000 as center Comvin using 150.000000,764.000000 as center Comvin using 150.000000,748.000000 as center Comvin using 150.000000,765.000000 as center Comvin using 150.000000,749.000000 as center Comvin using 150.000000,766.000000 as center Image 0 Mean 3888535799.712333 sdev 735366146.677721 count 376185 There's detail in this image that was not obvious in Jean-Luc's data. For example, there are several craters that I haven't noticed before. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CHECK THE DTIME AND YEAR TAGS ON THE NORMALIZED IMAGES file year dtime UTC eph_row should be (mean) ---- ---- ----- --- ------- --------- jm8.990801.cbr.nrm.rdf 1999 46264 12:51:04 1533.12 1540.3 jm8.990802.cbr.nrm.rdf 1999 46924 13 02 04 578.87 594.7 jm8.990803.cbr.nrm.rdf 1999 45792 12 43 12 400.54 401.0 jm8.990804.cbr.nrm.rdf 1999 48360 13 26 00 401.33 401.1 jm8.990805.cbr.nrm.rdf 1999 43094 11 58 14 401.37 400.9 jm8.990806.cbr.nrm.rdf 1999 45230 12 33 50 400.62 401.0 jm8.990809.cbr.nrm.rdf 1999 38795 10 46 35 400.79 401.0 dtime values are correct: they refer to the first rcsta, NOT the mid-epoch. eph_row values refer to the first one, not to the mean. I modified eph_row in the cbr files to match the values listed above. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INSPECT THE CBR IMAGES: MAKE SURE THEY MATCH THE GSB IMAGES COMBINE THE CBR OC AND SC IMAGES INTO ONE FILE CBR DATA TO NORMALIZE: Aug 1 done Aug 2 done Aug 3 done Aug 4 done Aug 5 done Aug 6 done Aug 9 done MAKE SURE THAT THE TIME TAGS ON THE SUMMED, NORMALIZED IMAGES ARE CORRECT ======================================================================== 1999 December 20 ======================================================================== Things to do to with the images before giving them to Scott: 1. Tabulate: date: DONE DOY: DONE file names: DONE time spans: DONE eph_row: DONE eph_col: DONE solution number: DONE Doppler sense: DONE resolution: DONE size of image (row x col): DONE 2. Make sure time tags, eph_row, and eph_col (if applicable) are correct. DONE 3. Indicate what the times mean: rcsta, rcend, etc. DONE ** THERE'S SOMETHING WRONG WITH THE AUG 3 IMAGE! See extra echo power to the ** right of the LE. Perhaps one frame had a different offset? Perhaps I screwed ** it up with the summing/vignetting. Also see (sincx)^2 effects on Aug 3 and 5. I hope Scott has some method of dealing with that. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - eph_col and eph_row for Goldstone images ======================================== Jul 20 ------ eph_col: DC is in gate 32. TXoff = 2.3 Hz using 0.1 Hz/bin. -> txoff = 23 bins relative to DC. 32-23 = 9 or bin 8 (zero-based) eph_row: CLT is in gate 13, one-based. I'm using zero-based numbers, so that puts it into gate 12 Jul 21 ------ eph_col: txoff = + 5 Hz or +50 bins relative to DC. So 128-50=78 one-based or bin 77 zero-based. eph_row: clt is in gate 13 (one-based), but we inserted a +30 us range offset, putting eph_row into gate 43 one-based or gate 42 zero-based. Jul 23 ------ eph_col: txoff = +5 Hz. dfreq = 0.075 Hz/bin so in bins the offset is 5 Hz/0.075 Hz/bin = 66.7 bins. 128-66.7=61.3 one-based or 60.3 zero-based. eph_row: txoff = +25 gates. CLT was in gate 17 (one based). So that puts us at 17+25=42 gates (one-based) or 41 (zero-based). Jul 24 ------ eph_col: txoff =+4 Hz or 4 Hz/0.075 Hz/bin = 53.4 bins. 128-53.4=74.6 one-based or 73.6 zero-based. eph_row: txoff = +25 us (+50 gates). CLT = 17 (one-based), so 17+50=67 one-based or 66 zero-based. Jul 27 ------ eph_col: txoff = +2.5 Hz or 2.5/0.04982 Hz/bin = 50.2 bins. 128-50.2=77.8 bins one based or 76.8 bins zero-based. eph_row: txoff=+150 range gates. CLT = 22, so 22+150=172 one based or 171 zero-based. Jul 28 ------ eph_col: txoff = +2.5 Hz/(0.04982 Hz/bin) = 50.2 bins. Same as the day before. eph_row: txoff=+100 gates. clt = 22. => gate 122 one-based or 121 zero-based. Jul 31 ------ eph_col: txoff = + 2.5 Hz. 2.5 Hz/(0.05002 Hz/bin) = 49.98 bins 128-49.98=78.02 bins one-based or 77.02 bins zero-based. eph_row: txoff = -100 gates. clt = 34. 34-100=-66. 255-66=189 one-based or 188 zero-based. Aug 1 ----- eph_col: txoff = +3 Hz. 3/(0.05002) = 59.98 bins. 128-59.98=68.02 or 67.02 zero-based. eph_row: txoff = +120 gates. clt = gate 34. 120+34=154 one-based or 153 zero-based. Aug 7 ----- eph_col: txoff = +3 Hz. 3/(0.074725) = 40.1 bins. 128-40.1 = 87.9 one-based or 86.9 zero-based. eph_row: CLT = gate 22. txoff=+100 gates. total = 122 one based or 121 zero-based. Aug 8 ----- eph_col: txoff = +3 Hz, so same result as day before. eph_row: CLT = 22. txoff = +100 gates, so same result as day before - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I spent several hours preparing the table: 1999JM8.images.summary to help Scott and us understand the processing of the reduced images. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I have not examined the GSB data in detail yet. There were problems with it on the first couple of days that I think will be more painful than the problems with the CBR data, plus the echo strengths will probably be down by a few dB relative to the CBR data. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Aug 3 Arecibo image ------------------- This image looks like there are one or two frames that have a Doppler offset relative to the others. There are 31 frames total. Mike's file Readme* doesn't indicate that he did anything different with any of the files, but perhaps he accidentally vignetted some differently. One way to find out would be to look at each frame and check for ones that are shifted. That will be time-consuming and tedious. This is different from the ghosts I saw in the Goldstone images, so I don't think it's an I & Q problem. It's not (sincx)^2 either; there's plenty of that in the image but it takes on a different morphology from the "ghost." Other possibilities: 1. check the GSB data The gif file that Jean-Luc prepared shows sincx effects but no other artifacts or obvious problems. That's not the same as working with the files themselves, though. 2. Problem with the CBR? How can we trace that? There are 31 frames in the file but my observing notes indicate that we got only 30 runs. Perhaps there's a partial run included? It seems that one of the final two runs is included--when the target was out of the beam. Let's repeat the reduction excluding that frame. Script: group_rdf jm8.990803.cbr.rdf jm8.990803.cbr.grp.rdf 1 30 sum_rdf jm8.990803.cbr.grp.rdf jm8.990803.cbr.sum.rdf acunorm -i jm8.990803.cbr.sum.rdf -o jm8.990803.cbr.nrm.rdf -l 83 -t 267 -r 204 -b 602 rdf2spy jm8.990803.cbr.nrm.rdf jm8.990803.cbr.nrm.dud.spy rm *grp* rm *sum* think:/public/protected/lance/1999JM8/arecibo < 63 > source jm8.ao.proc Image 0 Mean 4167212422.089890 sdev 761518269.186882 count 199465 That solved the problem. Interesting... I ftped the new (good) files to reason from think and got rid of the bad ones. Just for kicks, let's take a look at that final frame. --> There's a complete image there but it's weak. Onward... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I sent Scott and Steve email describing everything in considerable detail. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Let's back up the files onto think:/public/protected. (Note: we don't have a functional cd burner). Alternatively, I could do a backup onto exabyte tape. Arecibo reason:/data/ast5/1999JM8/arecibo/proc/rng < 186 > du -ks reduced_images/ 9513 reduced_images Goldstone reason:/data/ast5/1999JM8/proc/rng < 190 > du -ks reduced_images/ 4484 reduced_images So the reduced rdf files are about 14 Meg total. There's more than 900 Meg of space on think:/public/protected, so put them there first. think:/public/protected/lance/1999JM8/reduced_images_backup/ Back them up onto intruder:/d1/1999JM8/proc/reduced_images_backup/ I'm backing everything up onto exabyte tapes too--by using Mike Thomas' script /etc/dump4. That backs up /ast3, /ast4, /ast5/ and /ast6. The JM8 data are on /ast5 and /ast6. ==> Didn't work. Back up the JM8 directories individually instead: reason:/data/ast5/1999JM8 < 29 > /tar cvf /dev/rmt/0n . reason:/data/ast6/1999JM8_arecibo < 31 > tar cvf /dev/rmt/0n . reason:/data/ast6/1999JM8_arecibo < 33 > mt -f /dev/rmt/0n rewoffl reason:/data/ast5/1999JM8 < 40 > tar tvf /dev/rmt/0n > analysis/1999JM8_122099_1.1 I meant to put that in /archive/.. This seems to indicate that only the Arecibo files are on the tape. Did they overwrite the Goldstone files? No--when I repeat the tar tvf command and write it to the xterm window all the Goldstone files show up. That's odd... What happened was that I entered ^C to stop it while tar was displaying the contents of /data/ast5/1999JM8/ files. When I started and told it to write the results to a file, I forgot to rewind the tape, so it wrote only the /data/ast6/1999JM8_arecibo/ files. All the files are there and they're now written to ../ast5/1999JM8/archives/1999JM8_122099_1.1 ========================================================================= Summed, normalized, and vignetted Goldstone images -------------------------------------------------- File Contents dtime (seconds) time (UTC) interval (h) ---- -------- --------------- ---------- ------------ jm20103.nrm.vig.rdf frames 1- 9 10221-10676 025021-025756 0.13 jm20203.nrm.vig.rdf frames 1-112 64751-67472 175911-184432 0.76 jm20403.nrm.vig.rdf frames 1- 69 3213- 5926 005333-013846 0.75 jm20511.nrm.vig.rdf frames 1-191 64938-71960 180218-195920 1.95 jm20511.nrm1.vig.rdf frames 1- 96 64938-68434 180218-190034 0.97 jm20511.nrm2.vig.rdf frames 97-191 68448-71960 190048-195920 0.98 jm20803.nrm.vig.rdf frames 1- 34 6628-10428 015028-025348 1.06 jm20903.nrm.vig.rdf frames 1- 43 63064-68448 173104-190048 1.50 jm20903.nrm1.vig.rdf frames 1- 22 63064-65887 173104-181807 0.78 jm20903.nrm2.vig.rdf frames 23- 43 66011-68448 182011-190048 0.68 jm21205.nrm.vig.rdf frames 3- 72 62735-71724 172535-195524 2.50 jm21205.nrm1.vig.rdf frames 3- 25 62735-65424 172535-181024 0.75 jm21205.nrm2.vig.rdf frames 26- 48 65548-68231 181228-185711 0.75 jm21205.nrm3.vig.rdf frames 49- 72 68900-71724 190820-195524 0.78 jm21305.nrm.vig.rdf frames 6-102 45258-57549 123418-155909 3.41 jm21305.nrm1.vig.rdf frames 6- 29 45258-48135 123418-132215 0.80 jm21305.nrm2.vig.rdf frames 30- 53 48262-51434 132422-141714 0.88 jm21305.nrm3.vig.rdf frames 54- 77 51557-54429 141917-150709 0.80 jm21305.nrm4.vig.rdf frames 78-102 54557-57549 150917-155909 0.83 jm21903.nrm.vig.rdf frames 5- 28 62816-65038 172656-180358 0.62 jm22003.nrm.vig.rdf frames 1-250 42850-51758 115410-142251 2.48 jm22003.nrm1.vig.rdf frames 1- 83 42850-45761 125077-124241 0.81 jm22003.nrm2.vig.rdf frames 84-166 45775-48815 124255-133335 0.84 jm22003.nrm3.vig.rdf frames167-250 48828-51758 133348-142238 0.81 jm22004.nrm.vig.rdf frames 1-264 52206-61683 143006-170803 2.63 jm22004.nrm1.vig.rdf frames 1- 88 52206-55296 143006-152136 0.86 jm22004.nrm2.vig.rdf frames 89-176 55309-58550 152149-161550 0.90 jm22004.nrm3.vig.rdf frames177-250 58564-61683 161604-170803 0.87 jm22007.nrm.vig.rdf frames 1-212 61994-69568 171314-191928 2.10 jm22007.nrm1.vig.rdf frames 1- 71 61994-64489 171314-175449 0.69 jm22007.nrm2.vig.rdf frames 72-142 64502-67032 175502-183712 0.70 jm22007.nrm3.vig.rdf frames143-212 67162-69568 183922-191928 0.67 Summed, normalized, and vignetted Arecibo images ------------------------------------------------ file year dtime UTC eph_row should be (mean) ---- ---- ----- --- ------- --------- jm8.990801.cbr.nrm.rdf 1999 46264 12:51:04 1533.12 1540.3 jm8.990802.cbr.nrm.rdf 1999 46924 13 02 04 578.87 594.7 jm8.990803.cbr.nrm.rdf 1999 45792 12 43 12 400.54 401.0 jm8.990804.cbr.nrm.rdf 1999 48360 13 26 00 401.33 401.1 jm8.990805.cbr.nrm.rdf 1999 43094 11 58 14 401.37 400.9 jm8.990806.cbr.nrm.rdf 1999 45230 12 33 50 400.62 401.0 jm8.990809.cbr.nrm.rdf 1999 38795 10 46 35 400.79 401.0 ======================================================================== 2000 January 3 & 4 ======================================================================== Before leaving JPL for the holiday vacation, I tabulated the delay-Doppler imaging results in the file: 1999JM8.images.summary I emailed copies of that file to Scott and Steve. Also before the holidays, I revised the brief description I wrote in October describing observing and data reduction at Goldstone. This is the first such guide in about four years since Dave Mitchell wrote one largely for my benefit. The Goldstone system has changed substantially during those four years. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tabulate the number of looks in each delay-Doppler image ======================================================== The objective is to add this information to 1999JM8.images.summary, which I intend to post on a website to facilitate communication with co-authors. Arecibo ------- Mike Nolan chose FFTs so that there is one look/image, so this is trivial. Goldstone --------- On some days we got one look/image but on others there were multiple looks. Date Setup frames looks/frame looks ---- ----- ------ ----------- ----- Jul 20 1 us x 0.1 Hz 9 2 18 Jul 21 1 us x 0.1 Hz 112 1 112 Jul 23 1/2 us x 0.075 Hz 68 1 68 Jul 24 1/2 us x 0.075 Hz 191 1 191 *** Jul 27 1/4 us x 0.05 Hz 34 1 34 Jul 28 1/4 us x 0.05 Hz 43 1 43 Jul 31 1/8 us x 0.05 Hz 70 1 70 Aug 01 1/8 us x 0.05 Hz 97 1 97 Aug 07 1/4 us x 0.075 Hz 24 2 48 Aug 08 1/4 us x 0.075 Hz 250 1 250 264 1 264 212 1 212 My processing script indicates that I used only the first 49 out of 191 frames from DOY 205 (July 24) in file jm20511. Why? ==> I mistook runs and frames. There are 49 runs with a total of 191 frames. ==> Repeat the reduction and then send email to Scott. DOY 205 (July 24) ----------------- We got 49 RUNS spanning 2.0 h for a total of 191 looks. Prepare one summed image and two spanning about 1 hour each. script on THINK: # jm20511: sum into one file group_rdf jm20511.rdf jm20511.grp.rdf 1 191 sum_rdf jm20511.grp.rdf jm20511.sum.rdf acunorm -i jm20511.sum.rdf -o jm20511.nrm.rdf -l 177 -t 3 -r 216 -b 84 comvin jm20511.nrm.rdf jm20511.nrm.vig.rdf 128 255 193 127 rdf2spy jm20511.nrm.vig.rdf jm20511.nrm.vig.spy rm *grp* rm *sum* # Sum into two groups # Group 1 group_rdf jm20511.rdf jm20511.grp1.rdf 1 95 sum_rdf jm20511.grp1.rdf jm20511.sum1.rdf acunorm -i jm20511.sum1.rdf -o jm20511.nrm1.rdf -l 177 -t 3 -r 216 -b 84 comvin jm20511.nrm1.rdf jm20511.nrm1.vig.rdf 128 255 193 127 rdf2spy jm20511.nrm1.vig.rdf jm20511.nrm1.vig.spy rm *grp* rm *sum* # Group 2 group_rdf jm20511.rdf jm20511.grp2.rdf 96 191 sum_rdf jm20511.grp2.rdf jm20511.sum2.rdf acunorm -i jm20511.sum2.rdf -o jm20511.nrm2.rdf -l 177 -t 3 -r 216 -b 84 comvin jm20511.nrm2.rdf jm20511.nrm2.vig.rdf 128 255 193 127 rdf2spy jm20511.nrm2.vig.rdf jm20511.nrm2.vig.spy rm *grp* rm *sum* can't do this on think:/data/lance/1999JM8/Goldstone--/data is nearly full. Switch to /public/protected/lance/1999JM8/ instead. think:/public/protected/lance/1999JM8/goldstone < 81 > source jm8proc Image 0 Mean 58105508.034127 sdev 4229026.982174 count 62121 Comvin using 193.000000,127.000000 as center Image 0 Mean 58929017.335909 sdev 6057004.624396 count 62121 Comvin using 193.000000,127.000000 as center Image 0 Mean 57290576.846992 sdev 5864328.191532 count 62121 Comvin using 193.000000,127.000000 as center ...Done. I have divided the resulting files into three categories and separated them into appropriate directories: reduced_images/ unvignetted_reduced_images/ spyglass_files/ I sent email to Scott. This time he replied. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Prepare an ephemeris covering the dates when we observed JM8 ------------------------------------------------------------ For the following table, I computed the mid-epochs of the observations and then rounded them to the nearest 10-minute mark. The Aug 1 observations were conducted at both telescopes but I adopted the Goldstone interval because those observations completely encompassed the Arecibo observations. The RA, DEC, and delta values differ in the 2nd - 4th significant digits depending on whether or not one chooses Arecibo or Goldstone as the observatory. mid-epoch DOY DATE RA (deg) DEC (deg) delta (AU) Observatory (UTC) --- ---- -------- --------- ---------- ----------- --------- 199-200 Jul 18-19 186.86316 59.91692 0.0986950379 G 02:10 201 Jul 20 182.49773 61.31689 0.0927759882 G 03 10 202 Jul 21 173.48589 63.45410 0.0839631015 G 18 10 204 Jul 23 163.49301 64.87432 0.0774280241 G 01 10 205 Jul 24 146.08152 65.54093 0.0696525769 G 18 30 208 Jul 27 118.34826 61.99643 0.0615591099 G 02 10 209 Jul 28 101.40668 55.57469 0.0579923112 G 18 10 212 Jul 31 81.69768 38.71527 0.0576216663 G 18 30 213 Aug 1 78.29506 33.91821 0.0588849962 G 14 00 214 Aug 2 74.83822 28.41457 0.0610769255 A 13 20 215 Aug 3 71.97869 23.19617 0.0639870786 A 13 00 216 Aug 4 69.51887 18.27725 0.0676252294 A 13 30 217 Aug 5 67.57866 14.10063 0.0715526777 A 12 40 218 Aug 6 65.85205 10.21789 0.0760713690 A 12 50 219 Aug 7 64.11012 6.15781 0.0819247971 G 17 40 220 Aug 8 62.98709 3.44577 0.0866410327 G 15 40 221 Aug 9 62.08343 1.25406 0.0910521650 A 11 30 Check the sky motion: reason:/data/ast5/1999JM8/analysis < 11 > angle Enter RA1 (deg): 186.86 Enter DEC1 (deg): 59.92 Enter RA2 (deg): 62.08 Enter DEC2 (deg): 1.25 Angle = 105.4833 The sky motion during the imaging (Jul 20-Aug 9) is a bit less: reason:/data/ast5/1999JM8/analysis < 12 > angle Enter RA1 (deg): 182.5 Enter DEC1 (deg): 61.32 Enter RA2 (deg): 62.08 Enter DEC2 (deg): 1.25 Angle = 102.9325 This will provide excellent geometric leverage with the shape modeling. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I completed the table of delay-Doppler dispersions (using contiguous pixels above the 2-sigma level). The Arecibo Doppler dispersions don't vary by much: 0.88-1.01 Hz The Arecibo delay disperions vary considerably: 3.47-5.27 km. ======================================================================== 2000 January 17 ======================================================================== Go back and normalize the SC images and then create ratio images. Creating normalized SC images will be straightforward because I already have a Perl script to do everything after minor modifications. The script is: jm8.ao.sc.proc, which was modified from jm8.ao.proc. Do the reduction on think due to the lack of rdf imaging software on reason. Use think:/public/protected/lance/1999JM8/arecibo/ I'm going to reduce Aug 1 first since--that's the data that requires the most registration. This is crunching along slowly on think. Result: nice SC image. Looks good--I opened it with Spyglass Transform. Forge ahead with images from the other days. I'm doing them all in one fell swoop. think:/public/protected/lance/1999JM8/arecibo < 92 > source jm8.ao.sc.proc Aug 4: Image 0 Mean 0.001214 sdev 0.447209 count 191562 Aug 3: Image 0 Mean 4182808474.133266 sdev 761408562.809779 count 199465 Aug 5: Image 0 Mean 4780336850.023087 sdev 808176734.420315 count 187294 Aug 6: Image 0 Mean 5133356300.264912 sdev 1420332355.947895 count 256508 Aug 9: Image 0 Mean 6245801645.364065 sdev 1248579928.684739 count 251375 Where is the image for August 2? ==> It's not in the script so it wasn't reduced. Odd... ==> It turns out that I wrote a separate script in December to reduce the Aug 1 and 2 files due to the problems with eph_row. I added the oc script to jm8.ao.sc.proc, revised it to handle sc images, and then ran it on think. It's chugging along... think:/public/protected/lance/1999JM8/arecibo < 108 > source jm8.ao.sc.proc Comvin using 150.000000,734.000000 as center Comvin using 150.000000,750.000000 as center Comvin using 150.000000,735.000000 as center Comvin using 150.000000,751.000000 as center Comvin using 150.000000,736.000000 as center Comvin using 150.000000,752.000000 as center Comvin using 150.000000,737.000000 as center Comvin using 150.000000,753.000000 as center Comvin using 150.000000,739.000000 as center Comvin using 150.000000,754.000000 as center Comvin using 150.000000,740.000000 as center Comvin using 150.000000,755.000000 as center Comvin using 150.000000,740.000000 as center Comvin using 150.000000,757.000000 as center Comvin using 150.000000,741.000000 as center Comvin using 150.000000,759.000000 as center Comvin using 150.000000,743.000000 as center Comvin using 150.000000,760.000000 as center Comvin using 150.000000,746.000000 as center Comvin using 150.000000,762.000000 as center Comvin using 150.000000,745.000000 as center Comvin using 150.000000,763.000000 as center Comvin using 150.000000,746.000000 as center Comvin using 150.000000,764.000000 as center Comvin using 150.000000,748.000000 as center Comvin using 150.000000,765.000000 as center Comvin using 150.000000,749.000000 as center Comvin using 150.000000,766.000000 as center Image 0 Mean 3910581786.151558 sdev 737468887.314903 count 376185 This took roughly 20 minutes. - - - - - - - - - - Vignette the reduced images further for ratio images ---------------------------------------------------- Before I really get into this, go back to the reduced and vignetted rdf files and vignette them even more. They are much too large. Additional vignetting is needed for: Aug 1 Aug 2 Aug 3 Aug 4: less than on other days Aug 5: Yes. This day sets the horizontal vignetting Aug 6: Yes. This day sets the vertical vignetting Aug 9: Yes, but less than on the first three days. Make all images the same size (row x col) Do the vignetting on think. Means I need to ftp the files back over from reason. I'll write the script to do the ratios in Perl and run it on rhyme/reason. Using the images with the most range and Doppler pixels as a guide, adopt row x col = 500 x 200. Vignetting Centers: Date row (range) col (Doppler) Mid point ---- ----------- ------------- --------- Aug 1 750-1249 50-249 1000,150 Aug 2 369- 868 50-249 619,150 Aug 3 150- 649 50-249 400,150 Aug 4 226- 725 80-279 476,180 Aug 5 186- 685 50-249 436,180 Aug 6 122- 621 80-279 372,180 Aug 9 164- 663 128-327 414,164 Since the images will be SC/OC, I'll map echo powers less than a threshold level to 1 sigma in OC and to 0 (zero) sigma in SC. ==> those pixels will map to black. The script will allow the user to select different thresholds. Reasonable thresholds are 3, 5, or 10 sigma. Rethink that: if the same pixel in *either* image is less than some threshold, then map it to black by mapping the SC pixel to zero sigma. If the OC pixel happens to be exactly zero, which is unlikely, then map it to one sigma. The vignetting script is: think:/public/protected/lance/1999JM8/arecibo/jm8.ao.vig.proc comvin jm8.990801.cbr.nrm.sc.rdf jm8.990801.cbr.nrm.vig.sc.rdf 500 200 1000 150 comvin jm8.990801.cbr.nrm.rdf jm8.990801.cbr.nrm.vig.rdf 500 200 1000 150 rdf2spy jm8.990801.cbr.nrm.vig.sc.rdf jm8.990801.cbr.nrm.vig.sc.spy rdf2spy jm8.990801.cbr.nrm.vig.rdf jm8.990801.cbr.nrm.vig.spy comvin jm8.990802.cbr.nrm.sc.rdf jm8.990802.cbr.nrm.vig.sc.rdf 500 200 619 150 comvin jm8.990802.cbr.nrm.rdf jm8.990802.cbr.nrm.vig.rdf 500 200 619 150 rdf2spy jm8.990802.cbr.nrm.vig.sc.rdf jm8.990802.cbr.nrm.vig.sc.spy rdf2spy jm8.990802.cbr.nrm.vig.rdf jm8.990802.cbr.nrm.vig.spy comvin jm8.990803.cbr.nrm.sc.rdf jm8.990803.cbr.nrm.vig.sc.rdf 500 200 400 150 comvin jm8.990803.cbr.nrm.rdf jm8.990803.cbr.nrm.vig.rdf 500 200 400 150 rdf2spy jm8.990803.cbr.nrm.vig.sc.rdf jm8.990803.cbr.nrm.vig.sc.spy rdf2spy jm8.990803.cbr.nrm.vig.rdf jm8.990803.cbr.nrm.vig.spy comvin jm8.990804.cbr.nrm.sc.rdf jm8.990804.cbr.nrm.vig.sc.rdf 500 200 476 180 comvin jm8.990804.cbr.nrm.rdf jm8.990804.cbr.nrm.vig.rdf 500 200 476 180 rdf2spy jm8.990804.cbr.nrm.vig.sc.rdf jm8.990804.cbr.nrm.vig.sc.spy rdf2spy jm8.990804.cbr.nrm.vig.rdf jm8.990804.cbr.nrm.vig.spy comvin jm8.990805.cbr.nrm.sc.rdf jm8.990805.cbr.nrm.vig.sc.rdf 500 200 436 150 comvin jm8.990805.cbr.nrm.rdf jm8.990805.cbr.nrm.vig.rdf 500 200 436 150 rdf2spy jm8.990805.cbr.nrm.vig.sc.rdf jm8.990805.cbr.nrm.vig.sc.spy rdf2spy jm8.990805.cbr.nrm.vig.rdf jm8.990805.cbr.nrm.vig.spy comvin jm8.990806.cbr.nrm.sc.rdf jm8.990806.cbr.nrm.vig.sc.rdf 500 200 372 180 comvin jm8.990806.cbr.nrm.rdf jm8.990806.cbr.nrm.vig.rdf 500 200 372 180 rdf2spy jm8.990806.cbr.nrm.vig.sc.rdf jm8.990806.cbr.nrm.vig.sc.spy rdf2spy jm8.990806.cbr.nrm.vig.rdf jm8.990806.cbr.nrm.vig.spy comvin jm8.990809.cbr.nrm.sc.rdf jm8.990809.cbr.nrm.vig.sc.rdf 500 200 414 164 comvin jm8.990809.cbr.nrm.rdf jm8.990809.cbr.nrm.vig.rdf 500 200 414 164 rdf2spy jm8.990809.cbr.nrm.vig.sc.rdf jm8.990809.cbr.nrm.vig.sc.spy rdf2spy jm8.990809.cbr.nrm.vig.rdf jm8.990809.cbr.nrm.vig.spy It turns out that I don't need to write a Perl script to compute ratio images: Keith (?) already did it: reason:/home/lance < 26 > ratioimg -h Usage: ratioimg -1 channel_1_file -2 channel_2_file -o output_ratio_file -t threshold Inputs should have same numbers of corresponding, normalized frames Presumably this means that channel 1 = SC, channel 2 = OC, and the threshold is in standard deviations. ratioimg is also available on think. I've been testing ratioimg but I haven't gotten any ratio images. I finally used rdf2spy to check the vignetted rdf files above and found that the one from Aug 1 doesn't have the echo: it's just noise. ?? Let's just use ratioimg on the original, unvignetted (but grouped, summed, and normalized) files. OK, it turns out that ratioimg IS working, but the stretch I was using made it difficult to tell. This is largely due to the fact that I'm tired, so let's go get some rest. I did some tests and verified that the threshold is in sigmas. The ratio images will probably need logarithmic stretches. ratio.proc: # convention: file 1 = OC and file 2 = SC ratioimg -1 jm8.990801.cbr.nrm.rdf -2 jm8.990801.cbr.nrm.sc.rdf -o jm8.990801.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990801.cbr.scoc.2.rdf jm8.990801.cbr.scoc.2.spy ratioimg -1 jm8.990802.cbr.nrm.rdf -2 jm8.990802.cbr.nrm.sc.rdf -o jm8.990802.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990802.cbr.scoc.2.rdf jm8.990802.cbr.scoc.2.spy ratioimg -1 jm8.990803.cbr.nrm.rdf -2 jm8.990803.cbr.nrm.sc.rdf -o jm8.990803.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990803.cbr.scoc.2.rdf jm8.990803.cbr.scoc.2.spy ratioimg -1 jm8.990804.cbr.nrm.rdf -2 jm8.990804.cbr.nrm.sc.rdf -o jm8.990804.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990804.cbr.scoc.2.rdf jm8.990804.cbr.scoc.2.spy ratioimg -1 jm8.990805.cbr.nrm.rdf -2 jm8.990805.cbr.nrm.sc.rdf -o jm8.990805.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990805.cbr.scoc.2.rdf jm8.990805.cbr.scoc.2.spy ratioimg -1 jm8.990806.cbr.nrm.rdf -2 jm8.990806.cbr.nrm.sc.rdf -o jm8.990806.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990806.cbr.scoc.2.rdf jm8.990806.cbr.scoc.2.spy ratioimg -1 jm8.990809.cbr.nrm.rdf -2 jm8.990809.cbr.nrm.sc.rdf -o jm8.990809.cbr.scoc.2.rdf -t 2 rdf2spy jm8.990809.cbr.scoc.2.rdf jm8.990809.cbr.scoc.2.spy Before I run this, though, I need to fix the vignetting from before--the output files will be about 3.5 Meg each otherwise. --> Save that for tomorrow. ======================================================================== 2000 January 18 ======================================================================== My quick perusal of the Aug 1 ratio image made it clear that we need color instead of a grayscale: grayscales just don't do it. I don't think that's possible with Transform, but perhaps XV, GIMP, or IDL can do it. The problem yesterday was that I had mixed up rows vs. columns. Here's the correct and renamed script: # reason:/data/ast5/1999JM8/arecibo/proc/rng/jm8.ratio.proc # # Lance A. M. Benner # # Created: 2000 January 17 # Modified:2000 January 18 # # Vignette the 1999 JM8 Arecibo OC and SC images to be 200 cols x 500 rows. # and then output Spyglass Transform files. Then use Keith's software # ratioimg to produce SC/OC images in rdf and Spyglass formats. # # This script is designed to be run on think.jpl.nasa.gov # # comvin notation: 300 2000 150 1000 means 300 columns x 2000 rows # centered on column 150 and row 1000 # # think:/public/protected/lance/1999JM8/arecibo < 77 > ratioimg -h # Usage: ratioimg -1 channel_1_file -2 channel_2_file -o output_ratio_file -t threshold # Inputs should have same numbers of corresponding, normalized frames # convention: file 1 = OC, file 2 = SC, t = threshold in sigmas # # ------------------------------------------------------------------------------- # August 1: 5-sigma threshold comvin jm8.990801.cbr.nrm.sc.rdf jm8.990801.cbr.nrm.vig.sc.rdf 200 500 150 1000 comvin jm8.990801.cbr.nrm.rdf jm8.990801.cbr.nrm.vig.rdf 200 500 150 1000 rdf2spy jm8.990801.cbr.nrm.vig.sc.rdf jm8.990801.cbr.nrm.vig.sc.spy rdf2spy jm8.990801.cbr.nrm.vig.rdf jm8.990801.cbr.nrm.vig.spy ratioimg -1 jm8.990801.cbr.nrm.vig.rdf -2 jm8.990801.cbr.nrm.vig.sc.rdf -o jm8.990801.scoc.5.rdf -t 5 rdf2spy jm8.990801.scoc.5.rdf jm8.990801.scoc.5.spy # August 2: 5-sigma threshold comvin jm8.990802.cbr.nrm.sc.rdf jm8.990802.cbr.nrm.vig.sc.rdf 200 500 150 619 comvin jm8.990802.cbr.nrm.rdf jm8.990802.cbr.nrm.vig.rdf 200 500 150 619 rdf2spy jm8.990802.cbr.nrm.vig.sc.rdf jm8.990802.cbr.nrm.vig.sc.spy rdf2spy jm8.990802.cbr.nrm.vig.rdf jm8.990802.cbr.nrm.vig.spy ratioimg -1 jm8.990802.cbr.nrm.vig.rdf -2 jm8.990802.cbr.nrm.vig.sc.rdf -o jm8.990802.scoc.5.rdf -t 5 rdf2spy jm8.990802.scoc.5.rdf jm8.990802.scoc.5.spy # August 3: 5-sigma threshold comvin jm8.990803.cbr.nrm.sc.rdf jm8.990803.cbr.nrm.vig.sc.rdf 200 500 150 400 comvin jm8.990803.cbr.nrm.rdf jm8.990803.cbr.nrm.vig.rdf 200 500 150 400 rdf2spy jm8.990803.cbr.nrm.vig.sc.rdf jm8.990803.cbr.nrm.vig.sc.spy rdf2spy jm8.990803.cbr.nrm.vig.rdf jm8.990803.cbr.nrm.vig.spy ratioimg -1 jm8.990803.cbr.nrm.vig.rdf -2 jm8.990803.cbr.nrm.vig.sc.rdf -o jm8.990803.scoc.5.rdf -t 5 rdf2spy jm8.990803.scoc.5.rdf jm8.990803.scoc.5.spy # August 4: 5-sigma threshold comvin jm8.990804.cbr.nrm.sc.rdf jm8.990804.cbr.nrm.vig.sc.rdf 200 500 180 476 comvin jm8.990804.cbr.nrm.rdf jm8.990804.cbr.nrm.vig.rdf 200 500 180 476 rdf2spy jm8.990804.cbr.nrm.vig.sc.rdf jm8.990804.cbr.nrm.vig.sc.spy rdf2spy jm8.990804.cbr.nrm.vig.rdf jm8.990804.cbr.nrm.vig.spy ratioimg -1 jm8.990804.cbr.nrm.vig.rdf -2 jm8.990804.cbr.nrm.vig.sc.rdf -o jm8.990804.scoc.5.rdf -t 5 rdf2spy jm8.990804.scoc.5.rdf jm8.990804.scoc.5.spy # August 5: 5-sigma threshold comvin jm8.990805.cbr.nrm.sc.rdf jm8.990805.cbr.nrm.vig.sc.rdf 200 500 150 436 comvin jm8.990805.cbr.nrm.rdf jm8.990805.cbr.nrm.vig.rdf 200 500 150 436 rdf2spy jm8.990805.cbr.nrm.vig.sc.rdf jm8.990805.cbr.nrm.vig.sc.spy rdf2spy jm8.990805.cbr.nrm.vig.rdf jm8.990805.cbr.nrm.vig.spy ratioimg -1 jm8.990805.cbr.nrm.vig.rdf -2 jm8.990805.cbr.nrm.vig.sc.rdf -o jm8.990805.scoc.5.rdf -t 5 rdf2spy jm8.990805.scoc.5.rdf jm8.990805.scoc.5.spy # August 6: 5-sigma threshold comvin jm8.990806.cbr.nrm.sc.rdf jm8.990806.cbr.nrm.vig.sc.rdf 200 500 180 372 comvin jm8.990806.cbr.nrm.rdf jm8.990806.cbr.nrm.vig.rdf 200 500 180 372 rdf2spy jm8.990806.cbr.nrm.vig.sc.rdf jm8.990806.cbr.nrm.vig.sc.spy rdf2spy jm8.990806.cbr.nrm.vig.rdf jm8.990806.cbr.nrm.vig.spy ratioimg -1 jm8.990806.cbr.nrm.vig.rdf -2 jm8.990806.cbr.nrm.vig.sc.rdf -o jm8.990806.scoc.5.rdf -t 5 rdf2spy jm8.990806.scoc.5.rdf jm8.990806.scoc.5.spy # August 9: 5-sigma threshold comvin jm8.990809.cbr.nrm.sc.rdf jm8.990809.cbr.nrm.vig.sc.rdf 200 500 164 414 comvin jm8.990809.cbr.nrm.rdf jm8.990809.cbr.nrm.vig.rdf 200 500 164 414 rdf2spy jm8.990809.cbr.nrm.vig.sc.rdf jm8.990809.cbr.nrm.vig.sc.spy rdf2spy jm8.990809.cbr.nrm.vig.rdf jm8.990809.cbr.nrm.vig.spy ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.5.rdf -t 5 rdf2spy jm8.990809.scoc.5.rdf jm8.990809.scoc.5.spy # -- END -- think:/public/protected/lance/1999JM8/arecibo < 91 > source jm8.ratio.proc Comvin using 150.000000,1000.000000 as center Comvin using 150.000000,1000.000000 as center Comvin using 150.000000,619.000000 as center Comvin using 150.000000,619.000000 as center Comvin using 150.000000,400.000000 as center Comvin using 150.000000,400.000000 as center Comvin using 180.000000,476.000000 as center Comvin using 180.000000,476.000000 as center Comvin using 150.000000,436.000000 as center Comvin using 150.000000,436.000000 as center Comvin using 180.000000,372.000000 as center Comvin using 180.000000,372.000000 as center Comvin using 164.000000,414.000000 as center Comvin using 164.000000,414.000000 as center Do this again with a 10-sigma threshold (recall that Keith used 5 and 10 sigma with the 1996 Toutatis data). I used the existing vignetted SC and OC files to create new ratio images with a 10-sigma threshold: # August 1 ratioimg -1 jm8.990801.cbr.nrm.vig.rdf -2 jm8.990801.cbr.nrm.vig.sc.rdf -o jm8.990801.scoc.10.rdf -t 10 rdf2spy jm8.990801.scoc.10.rdf jm8.990801.scoc.10.spy # August 2 ratioimg -1 jm8.990802.cbr.nrm.vig.rdf -2 jm8.990802.cbr.nrm.vig.sc.rdf -o jm8.990802.scoc.10.rdf -t 10 rdf2spy jm8.990802.scoc.10.rdf jm8.990802.scoc.10.spy # August 3 ratioimg -1 jm8.990803.cbr.nrm.vig.rdf -2 jm8.990803.cbr.nrm.vig.sc.rdf -o jm8.990803.scoc.10.rdf -t 10 rdf2spy jm8.990803.scoc.10.rdf jm8.990803.scoc.10.spy # August 4 ratioimg -1 jm8.990804.cbr.nrm.vig.rdf -2 jm8.990804.cbr.nrm.vig.sc.rdf -o jm8.990804.scoc.10.rdf -t 10 rdf2spy jm8.990804.scoc.10.rdf jm8.990804.scoc.10.spy # August 5 ratioimg -1 jm8.990805.cbr.nrm.vig.rdf -2 jm8.990805.cbr.nrm.vig.sc.rdf -o jm8.990805.scoc.10.rdf -t 10 rdf2spy jm8.990805.scoc.10.rdf jm8.990805.scoc.10.spy # August 6 ratioimg -1 jm8.990806.cbr.nrm.vig.rdf -2 jm8.990806.cbr.nrm.vig.sc.rdf -o jm8.990806.scoc.10.rdf -t 10 rdf2spy jm8.990806.scoc.10.rdf jm8.990806.scoc.10.spy # August 9 ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.10.rdf -t 10 rdf2spy jm8.990809.scoc.10.rdf jm8.990809.scoc.10.spy I copied this and other jm8 Arecibo scripts to reason:/home/lance/src/ I organized the results into this directory structure: reason:/data/ast5/1999JM8/arecibo/proc/rng/ratio_images < 58 > ls 10_sigma_threshold/ 5_sigma_threshold/ vignetted_oc_images/ vignetted_sc_images/ Look at the results ------------------- How did Keith add color to the Toutatis ratio images? I've poked around with Spyglass Transform and found that one can select from grayscale or colors under the "Tables" menu. Selecting "hot metal" reproduced the 5-sigma color bar that Keith used. It's necessary to use an external program (like XV, GIMP, or IDL) to get logarithmic stretches. Steve mentioned that he and Keith had a hard time finding a stretch that they liked--there wasn't enough dynamic range. I need to redo the August 9 ratio image--it's truncated. The other images are OK. The big surprise is that the ratio seems quite high--close to 0.5. We didn't do much cw at Arecibo but we did do some, so I need to check it out. The high ratio worries me--perhaps there's some system problem that's skewing the ratio? How thoroughly have both channels been tested? Has it been calibrated against targets that are well understood, like Mercury? 0.5 is significantly higher than the ratio at X-band from the Goldstone CW data, which were close to 0.2. The answer appears to have been that the saturation I chose (0.8) was such that the overall ratio appeared close to 0.5. When I set the saturation level at 0.5, then the average ratio changed to about 0.3, which is conceivable. At any rate, quick inspection of the Aug 1 and 5 images shows an obvious decrease in SC/OC on portions of the LE and scattered brighter pixels toward the limb. The distribution of darker pixels isn't uniform along the LE, though: in the Aug 5 image they concentrate in two regions on either side of 0 Hz, although the LE in general is darker than elsewhere. In the Aug 1 image, there are scattered regions with darker pixels. Overall, though, the surface is more heterogeneous than the surface of Toutatis, which is an important rsult. In the more detailed paper (not the Science paper) we should repeat the Toutatis discussion. The "Saturn" table with a saturation of 0.3 or 0.5 looks pretty good--certainly better than the "Hot metal" table: there's *a lot* more dynamic range and the zero-sigma points map to white, which will save toner. A bit more experimenting shows that a saturation of 0.4 is probably a very good compromise. The darkest LE pixels have ratios of close to or somewhat less than 0.1 but the overall ratio is between 0.2 and 0.3, consistent with the Goldstone results. The darkest points are darker than the ones seen in 1996 Goldstone images of Toutatis--those ratio images show a more uniform surface with only subtle ratio effects. Of course, the JM8 data are better, but it could be that the surface scattering is different. Our Lexmark color printer "monet" can make hardcopies directly from Spyglass Transform--just enter the printer name and select color (vs. grayscale) prints. Be aware that the toner on the paper tends to smear. We'll need to use a better printer for the camera-ready figures. I labelled the Aug 5 image and saved the settings in a Spyglass macro. Clearly we need to take SC images for very high SNR Goldstone targets in the future and for any well-resolved target with a high SC/OC. What would an Adonis SC/OC image look like? An idea to keep in mind: explore the saturation for each day's image--0.4 looks great for Aug 5, but it might not for other days. The Aug 2 image is really cool: the radar-facing side of the big crater near the middle of the image (not the big concavity, obviously) has a region of very low SC/OC that is even more pronounced than that at the closest part of the LE. Ah, the thrill of scientific discovery! This is fun... The Aug 4 image doesn't show much--there were only 5 looks. Similarly with the Aug 6 image-- there are only 13 looks. That's enough to see darker pixels on the LE. Redo the Aug 9 image -------------------- For some reason I set the mid col at 164 instead of 200 (image is 400 cols wide). This should be straightforward... I'm repeating the vignetting of the OC and SC images, creation of the OC and SC Spyglass files, and creation of the ratio rdf and Spyglass files. The image is still on the right edge but none of it is truncated. In general, the images from Aug 4, 6, and 9 don't show much detail due to small numbers of looks (Aug 4 and 6) and weaker SNR (Aug 9). The other images are very interesting. This is all for a 5-sigma threshold. Summary ------- There are distinct SC/OC variations on the surface on all the days (Aug 1, 2, 3, and 5) when there's enough SNR to discern it at locations other than the LE. The lowest SC/OC values concentrate at the LE and are typically about 0.1 or somewhat less. The strongest pixels are on the limb. Sides of craters that are probably oriented close to orthogonal to the radar also have low ratios. We could also repeat the more extensive analysis in Ostro et al. (1999), who used the ratios to constrain the abundance of rocks on the surface of Toutatis. Their discussion is rather complicated but we should be able to condense it and apply it to 1999 JM8 once we have the 3-D shape models, radar scattering law, and radar albedos. Steve pointed out that the large low SC/OC region in the Aug 2 image is the first real ratio feature seen on any asteroid. We compared SC and OC images and images showing the same feature on Aug 9. Steve points out that there could be a lack of small-scale structure there or that the radar scattering law there could be different. He favors the former explanation. I thought that we could be seeing nearly specular reflections from a crater wall oriented nearly orthogonal to the radar line of sight, but Steve thinks it could be more substantial. This is really a question for Scott, so I'm going to do a screen grab on the images, post them on a website, and as Scott what he thinks. This may also help get Scott moving on the shape reconstruction. Let's go the whole way: put SC, OC, and SC/OC images on the web for each day of Arecibo data. >> Tell Scott where the SC images are << The Aug 2 image alone justifies obtaining ratio images with future experiments. Steve points out that we should use Keith's program "trace" on JM8 to see where features are on the surface. Aug 9 SC/OC image ----------------- I also need to redo the Aug 9 vignetting etc. again--the edge of the echo is cut off. Move the image over another 30 Doppler bins. # August 9: 5-sigma threshold comvin jm8.990809.cbr.nrm.sc.rdf jm8.990809.cbr.nrm.vig.sc.rdf 200 500 230 414 comvin jm8.990809.cbr.nrm.rdf jm8.990809.cbr.nrm.vig.rdf 200 500 230 414 rdf2spy jm8.990809.cbr.nrm.vig.sc.rdf jm8.990809.cbr.nrm.vig.sc.spy rdf2spy jm8.990809.cbr.nrm.vig.rdf jm8.990809.cbr.nrm.vig.spy ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.5.rdf -t 5 rdf2spy jm8.990809.scoc.5.rdf jm8.990809.scoc.5.spy 10-sigma: # August 9 ratioimg -1 jm8.990809.cbr.nrm.vig.rdf -2 jm8.990809.cbr.nrm.vig.sc.rdf -o jm8.990809.scoc.10.rdf -t 10 rdf2spy jm8.990809.scoc.10.rdf jm8.990809.scoc.10.spy ...done This version is clearly better. Let's re-create the spiffy ratio image and then leave: it's almost 19:30. ======================================================================== 2000 January 19 & 20 ======================================================================== Close inspection of the ratio images shows some pixels close to the LE at freqs separated from the echoes by a few Doppler bins. Those are seen in the strongest images when we had what I suspect are (sincx)^2 effects. Yesterday I used a stretch of 0.4. After tinkering with the images using Spyglass Transform, saturation = 0.5 shows more detail and works better; 0.6 is too far--pixels near the LE are too uniform. Let's experiment with logarithmic stretches too using XV. ==> Not so great. That introduced more distortion than clarity. The intrinsic dynamic range of the pixels that we care about seems better suited to a linear stretch. I printed each plot with sc/oc saturated at 0.5. I posted them on a website. Let's explore the high end of the SC/OC distribution in the Aug 2 image. There are several hundred points with mu > 0.6, most of them at the more distal regions. One interesting juxtaposition occurs immediately adjacent to the low SC/OC feature on what appears to be the side of a crater. My preliminary explanation is that there could be a relative increase in roughness at the top of the crater, which is effectively on the horizon. Date Min Max ---- --- --- Aug 1 Aug 2 0 1.26 Aug 3 Aug 4 Aug 5 Aug 6 Aug 9 Thus far I haven't looked at the 10-sigma results. To be complete, I should also check a weaker threshold, say, 2- or 3-sigma. Obviously chi-sq and self noise will be more of an issue, especially with the Aug 4 and 6 data. Steve and I discussed the ratio images in more detail. The precedents for sc/oc features are lunar work by Tommy Thompson, Nick Stacy, and Jean-Luc Margot, and Magellan. Thompson's work long ago demonstrated that X-band radar can be sensitive to ejecta blankets that aren't obvious optically. A major issue is the noise estimates in the ratios. The noise obeys a chi-square distribution. Stacy et al. discuss uncertainty estimates. They adopt an F-distribution formulation, in which the fractional uncertainty for N looks is approximately sqrt(2/N). Date Looks sqrt(2/N) ---- ----- --------- Aug 1 26 0.28 2 28 0.27 3 31 0.25 4 5 0.63 <== TILT 5 35 0.24 6 13 0.39 <== not so great 9 25 0.28 Aug 4 and 6 don't have enough looks to be useful. Concentrate on the other days. Steve points out that another way around the fractional errors is to work with many pixels that define a feature. There are about 100 pixels in the low sc/oc region, so we could run a boxcar filter over them to compute sc/oc and the uncertainties. For that many pixels, the distribution is Gaussian. Then pick adjacent regions with strong echo power and do the same. There is just such a region at about the same range gates as the low sc/oc feature but at slightly more positive Doppler frequencies. There should be a strong sc/oc contrast between the regions. Other adjacent regions aren't as easy to define due to radar shadowing at larger ranges and more shadowing at lesser ranges in a crater. We can also compare another region at more negative Doppler frequencies, also at about the same ranges (although that region has fewer bright pixels. 10-sigma threshold data ----------------------- The low sc/oc feature on Aug 2 is obvious in the 10-sigma data too. The linear features and somewhat smaller ranges are more evident. I cranked out the ratio images. 3-sigma threshold results ------------------------- I also computed three-sigma ratio images on think. I transferred the results to reason. The results are about as would be expected: more pixels show up at the more distal regions and deeper into features that look like craters. There are a few scattered noise pixels and more (sincx)^2 pixels. Otherwise there aren't any new features. ==> Don't bother going to lower thresholds than this. Let's use the 3-sigma data to constrain the sc/oc contrast adjacent to the feature in the Aug 2 image. It helps to enlarge the image to 1000x1000 Low SC/OC feature: Use rows 172-181 and cols 122-131 (10 x 10). col sum --- --- 122 0.92 123 1.05 124 0.93 125 0.79 126 0.81 127 0.67 128 0.75 129 0.71 130 0.78 131 0.94 Sum 8.35 mean = 0.0835 Adjacent higher SC/OC feature: Use rows 172-181, cols 132-141 (10 x 10) col sum --- --- 132 1.20 133 1.53 134 2.32 135 2.58 136 2.46 137 2.48 138 2.59 139 2.60 140 3.41 141 2.95 Sum 24.12 mean = 0.24 About a factor of 3 larger. There are 2800 looks in each region for a fractional error of sqrt(2/2800) = 0.03, so the difference is statistically significant. One could already conclude this by inspection, but now we have a quantitative result to back it up. Stacy et al. (1997) note that the strongest radar backscatter from the lunar poles occurs on the sides of craters oriented toward the radar. They obtained a range of sc/oc from crater rims, ranging from high (close to unity) to moderate (close to about 0.2-0.4), but in their Fig. 2B I don't see any crater *rims* with sc/oc obviously close to 0.1 or less. Granted, they're looking at a much larger object with a thick regolith and with facets that are much larger. Careful inspection of the sc/oc and oc images shows a radar-bright "bump" inside the crater-like structure. I've already noticed that feature in the Aug 9 image, but it's now apparent that it's present on Aug 2 and even in images obtained on Aug 1. My thinking before was that the bump was on the hemisphere opposite the large crater. The images suggest that the low sc/oc region is on the bump, not on the crater wall. Perhaps the radar-facing side of the bump is scattering in a manner similar to the LE. Alternatively...could there be a slump on the side of the crater? There *is* a lack of echo power between the bright "bump" and the crater wall. The resolution of the Aug 1 image isn't high enough to see details on the "bump," but there's clearly a cluster of bright OC pixels at the right spot. The "bump" is not evident on Aug 3, although structures that may be craters of ~200 and ~500 m in diameter are present on that day. What I don't see are sc/oc features on Aug 1 and 9 at the location of the "bump." The Aug 1 image is strong enough but there's no distinct pattern of low sc/oc. The Aug 9 image isn't strong enough in terms of S/N. ==> We need the shape model. The gravitational slopes are also relevant. Other things to look for: long ~linear features such as ridges and grooves. No grooves have been seen yet among radar-detected NEAs. - - - - - - - - - - As the website images are now, there's a lot of wasted space, so let's vignette the files more. For now, vignette by rows and columns. Ultimately we'll vignette so the images have the same dimensions (we don't know the km/Hz conversion yet). As I've chosen them, the numbers of rows and columns will be uneven. The goal is to save screen space. << Stay tuned >> Generate labelled SC and OC Arecibo images ------------------------------------------ I haven't produced really nice images from each day yet for the Arecibo data, so let's do it for each polarization. I started to make a nice version of the Aug 2 OC image. Finish it tomorrow. It will be necessary to do logarithmic stretches due to the dynamic range of the OC images. ==> I used a template to create the images, but I haven't played with the logarithmic stretches yet. It's time to get some of this down into a draft manuscript. 1. 10-sigma data ==> DONE 2. SC and OC images with linear and logarithmic stretches ... in progress 3. Better vignetting of the ratio images...some other time 4. boxcar filter the Aug 2 image ==> DONE for the regions of interest 5. 3-sigma ratio images ==> DONE ======================================================================== 2000 January 21 ======================================================================== Directly compare the Arecibo SC and OC images ============================================= August 1 -------- Obviously the images are similar but the OC image is much brighter and it shows more detail in regions where there is none in the SC image. The "bump" doesn't stand out in the SC image but it does in OC. Some of the distal pixels on the arcuate feature on the negative limb are barely discernible in SC but are obvious in OC. Likewise, there are a few relatively bright OC pixels on the positive distal limb that do not appear in SC. August 2 -------- The principal differenences are between the "bump" and the distal echoes that barely show up in the SC image but are obvious in the OC image. By "distal" I refer to the weak points along the limb and TE at negative freqs. There appear to be two impact craters there in the OC image but they aren't evident in the SC image. The craters are about 350 and 400 m in diameter. August 3 -------- Something I hadn't noticed before is that the big central concavity is evident in the Aug 3 images, as is one of the elliptical craters that was obvious on Aug 2. There's a feature in the OC image that looks like a crater rim, but it's not visible in the SC image. There are several linear OC features on the negative TE that aren't present in the SC image. These are mostly curved collections of relatively bright pixels that look like obliquely-viewed craters. The crater mentioned above on Aug 3 and an adjacent feature that may be another crater (both in the OC image) are close to a bent lineament of bright pixels that is clear in the Aug. 4 and 5 images. The crater-like features are present in the Aug 4 image, but they're subtle due to low SNR. August 4 -------- The ridge-like feature I mentioned for Aug 3 isn't obvious in the SC image, nor are any of the features that look like craters. There isn't enough S/N. The far negative TE seems even weaker in SC than the overall S/N of the image would suggest, but given that there are only 5 looks, I'm not going to dwell on it. August 5 -------- The images look similar except for S/N differences, which prevent some OC features from being seen in the SC image. The OC image is so strong that it reveals numerous small (~200 m) impact craters. Some larger craters are also apparent in SC. Some of the OC craters appear to be only about ~100 m in diameter. August 6 -------- thus far I've just been comparing the images by inspection by fiddling with the saturations. To improve the results, I should set the the lower thresholds to, say, 3-sigma. There are only 13 looks so the SC image doesn't have much high-freq detail--mostly it just shows the outline of the shape. The OC image shows numerous craters. In a sense, the SC images are reminiscent of the Goldstone images in terms of the levels of detail that are visible. August 9 -------- These are the weakest Arecibo images, and as such, the SC image doesn't reveal much detail. The "bump" is present in both polarizations as are a few features that are probably large craters. - - - - - - - - - - Keith called about the format of Goldstone SC and OC dual-polarization imaging. Evidently Ray never settled on a format and the separation is ugly, so there's no packaged software available for a quick reduction. Keith separated the 1996 Toutatis data by hand. We could ask Marty/Ray about the present format, but ultimately we should match whatever Arecibo does with Jean-Luc's GSB (does that match the radar interface?). If Jean-Luc installs one of his boxes at Goldstone, then that would obviously facilitate getting uniform data formats. With the present Goldstone system, the problem is separating the SC and OC images in near-real time so we can see what we have in the data. Had we taken dual poln imaging last summer with JM8, we would have had to have bugged Keith to reduce it, which could have interfered with the decisions we had with the observing strategy on each day. ======================================================================== 2000 January 24 & 25 ======================================================================== I printed out well-labeled GSB images in both polarizations from each day. It turns out that I made a mistake with my earlier attribution of the "bump" seen so clearly on Aug 2 in the Aug 1 image: I was looking at the wrong crater in the Aug 1 image--the one in the center on Aug 1 does have a group of bright pixels just inside the trailing crater rim (i.e. away from the LE) but that's not the crater I focussed on in the Aug 2 images. The correct crater in the Aug 1 image (the more tear-drop shaped one in the delay-Doppler images) also has a collection of brighter pixels, but they don't have a distinct morphology in the Aug 1 image. It turns out that I never saved some of the Goldstone spyglass files as images--several are only arrays of numbers. Rats... Closer inspection of the July 24 Goldstone image shows more (sincx)^2 effects. There's a bright spot in the large nearly central crater just to the positive side of zero Hz--the same spot where one is visible in Aug 1 Arecibo images. The July 23 image shows hints of the big concavity that is much more evident in early August. - - - - - - - - - - Impact Cratering on 1999 JM8 ---------------------------- 1. Geographic distribution of craters: is it random? 2. R-plot: is the surface saturated? If we assume that the population of impactors is the same as for Ida, Gaspra, and Mathilde, what can we say about the age of 1999 JM8? 3. depth/diameter ratios: are the uncertainties in the dimensions small enough for meaningful statements? Based on small lunar craters, we should expect ratios close to about 0.2. But will large craters that are a significant fraction of the asteroid's diameter obey this simple relationship? The smallest craters are impacting into a half-space, but the larger ones are not. Do Asphaug et al. (1996) say anything about this? 4. Is there evidence of craters overlapping adjacent craters? Any evidence for ejecta? No obvious ejecta in the images except for the radar-bright annulus surrounding what appears to be a ~100-m crater in the July 28 image. No obvious rays. The craters appear to be simple in structure, although the delay-Doppler projection makes several likely craters appear tear-shaped. The large central concavity may be somewhat angular in map view, perhaps due in part to its large size relative to that of 1999 JM8. Raised rims? There are hints in terms of radar bright features that appear along the rims and closer to the LE than the distal rims. Note: depth/diameter ratios have been estimated for Gaspra, Ida, and Mathilde. Gaspra and Ida have d/D ~ 1/6.5 - 1/7. There's significant dispersion in the ratio for Mathilde: 0.12-0.25 (there are fewer well-imaged craters on Mathilde). Why is d/D apparently lower for small objects (including Deimos, but excluding Phobos) than for, say, the Moon? Sullivan et al. (1996, Ida) and Carr et al. (1994, Gaspra) address this issue and claim that the best explanation is that the low gravity provides less ejecta to pile up and raise the rim heights. That seems overly simplistic and begs for someone like Asphaug to examine this in detail. Asphaug et al. (1996) did examine bright annuli surrounding craters but not rim heights. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SC/OC > 0.8 in the rato images ------------------------------ Aug 1: isolated pixels mostly along the TE. There are also small numbers inside the large rounded features that are probably impact craters. Aug 2: visual inspection suggests there are less than on Aug 1. They again concentrate among the weaker SNR pixels near the TE. There are a few in the ellipsoid crater-like feature on the approaching limb. Aug 3: Very few among craters (aren't many craters visible); small numbers of high SC/OC among weak TE pixels. Also a few along the limbs, as also seen on the other days. Some of those may be (sincx)^2 effects because a number are not contiguous with the echoes. Aug 5: High sc/oc pixels are again dispersed among the distal regions, which extend over larger ranges on Aug 5 than on other days due to the greater range extent of the image. Overall there are also more such pixels than on the other three days. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Detailed summary of delay-Doppler images from July 21-August 9 ============================================================== JULY 20: Spatially resolve target. Maximum range extent is given by Table DISC-INTEGRATE PROPERTIES. No features visible; crude indication of angularity of the shape with a pointed end oriented toward the radar. JULY 21. Resolved JM8 into ~a few hundred pixels. See pointed end oriented toward negative frequencies. Much stronger image due to closer target and much longer integration. Starting to see possible surface features (large concavities?) near the TE. JULY 23: Asymmetric delay-Doppler distribution. Brightest pixels are on the negative limb. Distal group of weak pixels at the negative TE show the first hints of a significant concavity. Best resolution to date: 75 m x 0.075 Hz. JULY 24: Spheroidal echo signature along the LE but interesting detail within the interior of the echo: two prominent tear-drop shaped structures that lack echo power. First image with obvious structure within the echo. Much stronger evidence for a big concavity along the TE. Hint of weak echoes from a distal feature along the negative limb. Appearance of the echoes has not yet repeated from earlier days. First set of images long enough to check for evidence of rotation: none seen. Tear-shaped features may be obliquely-viewed impact craters. Placed hundreds of pixels on the asteroid. JULY 27: Increased resolution to 37.5 m x 0.05 Hz. Placed thousands of pixels on the asteroid. Clearly reveal an asymmetric shape with a promient pointed end slightly positive of zero Hz. Asteroid from this perspective is very angular. Pointed end vaguely resembles appearance of echoes on July 20 but detailed comparison is not possible because echoes on July 20 were much weaker and much coarser resolution. Hints of detail within the echo beyond the LE but less than was seen on July 24. Echo isn't strong enough due to short interval covered (only about 1 hour). JULY 28: Image is dramatically different from the July 27 image. Distribution of echo power is asymmetric with more power evident at negative frequencies than at positive frequencies. LE has two prominent "hills" with sub-Earth points that are at nearly the same time delay. Between the two hills the LE is about 10 0.25 us range gates back. That is, the LE is undulatory in time delay. There's a a radar-bright annulus near zero-Hz that encompasses a group of radar-dark pixels that are about 100 m in diameter, suggesting a small impact crater with a radar-bright feature surrounding it. This resembles some impact craters seen in radar observations of the Moon and Venus and may indicate a relatively young crater with a rough surrounding near-surface at decimeter spatial scales, probably due to the impact. We do not expect significant regolith retention on such a small object, so the radar bright annulus may be the result of proximal surface shaking, as Asphaug et al. (1996) proposed for optical annuli surrounding craters on 243 Ida. There is also an arcuate feature of bright pixels just inside the positive limb. JULY 31: This and the August 1 image are the highest resolution images obtained at Goldstone. The image does not obviously repeat features that were seen on previous days. The shape of the LE is somewhat angular but there are no pointed ends or twin peaks visible as there were on July 27 and 28. New surface features are visible at ranges beyond the LE. For example, at frequencies just positive of zero Hz and beginning about 20 range gates in from the LE there's a large approximately circular feature that is probabably an impact crater. Its range extent is about 700 meters and its bandwidth is about 0.9 Hz. Adjacent to this crater at slightly larger range gates is another much smaller, nearly circular feature that may also be an impact crater that extends about 190 m in range and 0.3 Hz in Doppler frequency. At the same range gates as this crater-like feature but at immediately more positive Doppler frequencies is a small radar- bright region spanning about 0.2 Hz and about 90 meters. The resolution is not high enough to determine definitively what this feature is. A third possible crater that has range and Doppler extents of about 400 m x 0.5 Hz is present adjacent to but at larger time delays than the bright feature. There is a weak roughly circular feature near the TE along the positive limb that may be another crater; it appears to be close to 1 km in range extent and about 0.9 Hz in Doppler frequency. The TE near zero Hz is has a broad distribution of weak pixels that suggest a large concavity. The other prominent feature in this image is a linear group of bright pixels between the positive limb/LE and the large crater that starts about 20 range gates behind the LE. The LE negative of zero Hz is almost linear--that is, it's not parabolic as would be expected from a spherical target. AUGUST 1: --------- This is the only day in which we have coverage at both Goldstone and Arecibo. The Arecibo image is much stronger, has higher range and frequency resolution, and shows more detail. Comparison of the Goldstone and Arecibo images indicates that there are no features in the Goldstone image that are not also present in the Arecibo image. This image is similar to the one obtained on July 24, suggesting that at least one component of 1999 JM8's rotation period is close to 8 days. (This does not include effects of rotation due to sky motion). The two large crater-like features seen on July 31 are obvious on August 1 and also correspond to the two tear-shaped features seen on July 24. One feature is clearly an impact crater with an apparently radar bright rim near the LE. This suggests either elevated topograph, surface roughness, or both along that rim. There is a narrow region of bright pixels extending from the crater rim just negative of zero Hz toward the positive LE/limb and in the other direction toward the negative limb. Within the large crater just negative of zero Hz there is a group of radar bright pixels at ranges just inside (i.e. closer to the radar) than the far rim. The really obvious crater on the negative side of zero Hz has a range extent of about 850 m in the Arecibo image (using bright pixels along apparent proximal and distal rims) and about 880 m in the Goldstone image. There is a prominent tear-shaped feature along the positive limb that may be a crater viewed obliquely. It has a radar-bright rim and there is a diffuse group of bright pixels about 10 range gates deep and about 8 Doppler cells wide adjacent to it on its side toward the LE. The range extent is indefinite due to the non-circular shape but it appear to be either 1.0 or 1.2 km, depending on which group of bright pixels one chooses to define the distal rim. The receding limb is strikingly angular with a sharp bend about 3 km beyond the LE at the subradar point. Between the sub-Earth point and the bend, much of the receding limb is approximately linear as a function of delay and Doppler, and appears to correspond to the linear LE that was seen at negative frequencies on July 31. There is a column of faint but statistically significant pixels at the receding limb that extend at least ~1 km deeper in range than the rest of the TE. The column is about 0.2 Hz wide. The TE is irregular in shape and it suggests the presence of a large concavity; the shape of the concavity is not obvious but it does not appear to be not circular. AUGUST 2: --------- The perimeter of the August 2 image is strikingly rounded with about 3/4 of a circular perimeter visible. The most prominent interior feature in the echo is a large radar dark region that extends from the TE inward to slightly less than 1/2 of the echo's delay depth. The large dark feature appears to be a substantial concavity that is about 2.4 km wide. Two prominent tear-shaped features are probably the craters that were seen on August 1, but they are rotated by about 45 degrees relative to their position on the previous day. The one near zero Hz has an intriguing radar bright feature that appears inside it near the distal crater rim. This feature may be a topographic high, but it is not clear whether it is actually inside the crater or whether it is a superposition from the opposite hemisphere. The rim of this crater closest to the LE is radar bright, as was seen with the rim of the other crater (that is near the receding limb on Aug 2) that was near zero Hz in the Aug 1 image. The central crater in this image has an apparent range extent of about 800 m. The arc of points on the receding limb near the TE has an irregular distribution of bright and dark pixels suggesting surface structure. AUGUST 3: --------- The echo is rounded and modestly asymmetric as a function of Doppler frequency with points closer to the radar to the negative of zero Hz. The August 3 image has an angular region at the TE that is devoid of pixels with significant echo power, suggesting that it is the concavity seen in the August 2 image. The progression of tear-shaped crater from August 2 is obvious in the August 3 image. The crater near zero Hz on August 2 is close to the receding limb on August 3. The rim nearest the LE is again radar bright, particularly at less negative Doppler frequencies. The tear-shaped structure appears to have a maximum range extent of about 1.2 km, comparable to its extent on August 1 but about 50% more than its extent on August 2. There is another probable impact crater with dimensions of about 560 m x 0.75 Hz that is evident on the negative side of zero Hz near the sub-Earth point. Its proximal rim begins about 150 m into the echo from the LE. A prominent radar bright, narrow linear feature extends from the positive limb toward the LE at zero Hz. There are hints of structure on the approaching limb and TE but the echoes there are not strong enough to distinguish the features. AUGUST 4: --------- The August 4 image is distinctly asymmetric with the LE to the negative of zero Hz. The delay-Doppler distribution is broadly triangular. The image has only 5 looks and the SNR relatively weak so that fewer surface details are visible than on other days. The approaching limb has three distinct linear segments, two of which are approximately parallel. There is a short segment between the two parallel segments. The approximately linear radar-bright feature seen on August 3 (between the approaching limb and the sub-radar point) is more obvious on August 4, although it has rotated by close to 50 degrees. There are hints of several circular features but none has sufficient detail to be confident that it is an impact crater. The best plausible crater candidate is just inside the bend in the approaching limb and at range gates just beyond the linear radar bright feature mentioned above. AUGUST 5: --------- The LE of this echo is the most nearly uniform in time delay of any day that we observed 1999 JM8. The LE is not remotely parabolic, as would be expected of a spheroidal target, but is approximately flat. The image is very strong and shows the most detail of any Arecibo image of this object. Numerous approximately circular patches of pixels dot the surface and are probably impact craters. The two largest craters are just past the LE near zero Hz and about half-way between zero Hz and the receding limb. They have dimensions of about 470 m x 0.14 Hz and 450 m x 0.17 Hz. There is another smaller crater-like feature near the positive limb about half way between the LE and the TE that has dimensions of about 420 m x 0.11 Hz. A fourth comparably-sized feature exists slightly closer to the TE and near the receding limb. The August 5 image gives the impression that the portion of the surface illuminated is heavily cratered. Clearly more features that appear to be impact craters are visible. The linear feature seen on the previous two days is evident close to the receding limb but it isn't as prominent as it was on August 4. There is an indentation in Doppler frequency on the approaching limb. Pixels on the trailing edge at this feature are radar bright, suggesting that surface facets have more projected area oriented normal to the line of sight than is present on adjacent regions. The brightest pixels are on the positive side of the approaching LE. AUGUST 6: --------- The nearly flat surface that formed the LE in the August 5 image forms the receding limb on August 6. The echo is asymmetric and angular and there are more pixels at positive frequencies than at negative frequencies. The brightest pixels are on an approximately flat region positive of zero Hz. Numerous dark circular features are present and are probably impact craters. Fewer are visible in the August 6 image, which has only about 1/3 the number of looks relative to the August 5 image. The craters appear to be up to several hundred meters in diameter. AUGUST 7: --------- We resumed observing at Goldstone for two days. The echoes have an asymmetric delay-Doppler distribution. The echo is more rounded than on the previous three days. There is a radar-bright "step" on the negative limb that is the rotated "indentation" that was seen on the approaching limb on August 5. The image does not show any obvious detail inside the echo other than an arcuate collection of pixels at the positive limb. AUGUST 8: --------- The delay-Doppler distribution of echo power illustrates that this side of 1999 JM8 is approximately spheroidal, in stark contrast with the distribution seen between August 4 and 6. The August 8 images span more than 7 hours and show the most compelling evidence of rotation among any of the 1999 JM8 images. However, the rotation is subtle. In general the image is similar to the August 1 image: the two prominent craters close to 1 km in diameter are both obvious, with what appears to be a smaller crater between them, although there is some rotation between the Aug 1 and 8 images. This is the best example of a nearly circular delay-Doppler distribution for the tear-shaped feature that was seen on August 1, 2, and 3. That feature on August 8 has a visible range extent of about 0.9 km, which is substantially less than suggested by the August 1 and 3 images but is closer to the extent from the August 2 image. The large concavity seen previously seems to have more of its interior illuminated on August 8. The concavity appears to be somewhat angular and it is about 1.5 km across and close to 1.4 Hz wide. The distal arc of points at the negative limb is on the negative limb and is now seen to be the rotated "indentation" that was prominent on the approaching limb on August 5. AUGUST 9: --------- This is the highest resolution view of 1999 JM8. The delay-Doppler distribution is parabolic and indicates that the portion of the asteroid that was imaged is rounded. Nevertheless, the image is asymmetric: there are more distal points at negative frequencies than at positive frequencies. One of the two prominent craters that is evident in the August 8 images is located just negative of zero Hz on August 9. The crater has dimensions of 1.1 km x 0.22 Hz. The big concavity seen on August 8 is largely in radar shadow on August 9. As was the case on August 2, the crater has a distinct group of bright pixels inside it near the distal rim. The pixels look like a topographic high. There is another large region just positive of zero Hz that looks like another large concavity. It has dimensions of 1.4 km x 0.21 Hz. Other thoughts: No obvious ejecta in the images except for the radar-bright annulus surrounding what appears to be a ~100-m crater in the July 28 image. No obvious rays. There are several linear features but their origins are not clear. They might be ridges. More intriguing possibilities are that the prominent feature on August 3-5 might be a fault or a groove, neither of which has been seen before among radar images of NEAs. The location of this feature on the shape model should elucidate its origin. None of the craters is complex: there are no central peaks or peak rings, nor are such features expected for such a small object due to its weak gravity. We do not see compelling evidence of terracing or slumping in any craters, but there are enigmatic groups of bright pixels that appear in two of the largest craters that are of unknown origins. How many craters or other concavities larger than about 1 km are evident? There are about 4. In retrospect, there is a hint of the large concavity in the images as soon as July 23; the concavity is clearly present in the July 24 images. ======================================================================== 2000 January 27 & 28 ======================================================================== Did the bandwidth change between days when the delay-Doppler images look similar? Compare July 24 and August 1: Jul 24 1.73 Hz Aug 1 3.05 Hz The bandwidth increased by a factor of about 1.8, so the subradar latitude was moving toward the apparent equator. However, this ignores NPA rotation, which almost certainly plays some role, so we need the results from the modeling. Comparison with the Aug 8 bandwidth isn't as meaningful because the orientation, although similar, was distinctly rotated relative to that on the other two days. The time base between Jul 24 and Aug 1 was slightly less than 8 days. Using the midpoints of the two images, the difference was . Sky motion during that interval was about 50 degrees. Following a simplistic line of thought in which NPA rotation and synodic rotation are ignored, this suggests that the subradar latitude moved from relatively high values, say, more than 45 deg, to within a few tens of deg of the equator. - - - - - - - - - - I just discovered a useful trick for stopping the lexmark printer if it's spewing large numbers of pages: pull out the paper tray to stop the printing, then use the menu button to reset the printer. That will flush the current buffer. It's often not possible to stop a job from the console because the print job moves into the printer's memory very quickly and out of the queue, so lprm won't help. - - - - - - - - - - Is the "twin peaks" region seen on July 28 the same as the "indentation" that is evident from August 5-7? If the major component of rotation is close to 8 days, then we would expect to see the twin peaks feature again on August 5. The orientation, resolution, and SNR are very different between the two days, perhaps masking the similarity. Perhaps the July 28 and August 6 images are a better match in terms of orientation. The shape model should answer this question. - - - - - - - - - - One significant conclusion and distint difference relative to Toutatis: 1999 JM8 shows no obvious evidence for bifircation. The elongation is more difficult to estimate due to the NPA rotation and the significant sky motion, but thus far I haven't seen evidence that JM8 is unusually elongated. That is, my best estimate of the elongation from the Doppler dispersions in images obtained between July 31 and August 9 is about 1.2. I chose thoses dates because we have an image on each day and there appears to be slightly more than one rotation. (Some of the rotation is due to the ~42 degrees of sky motion during that interval.) If one naively uses the full variation in bandwidths over the whole experiment, then one would conclude that the elongation is about 2.4 (Goldstone images). - - - - - - - - - - How many craters or other concavities larger than about 1 km are evident? There are at least two: The two that are so prominent on July 24, August 1, August 2, and August 8 (one is also visible on August 3 and 9). The big concavity mentioned on several days is another candidate, as is a significant concavity that is obvious only on August 9. Dates crater delay Crater is evident extent (km) ------ ------------ ----------- 1 Jul 24, 31 0.9 Aug 1, 2, 8 2 Jul 24, 31 1.2 (Aug 1, 3) Aug 1, 2, 3, 0.8-0.9 (Aug 2, 8) 8, 9 3 Jul 23, 24, 1.5 (Aug 8) Aug 1, 2, 3 8, 9 4 Aug 2 ?, 9 1.4 (Aug 9) Concavity #2 is puzzling: the "oblique" views on Aug 1 and 3 suggest it is close to 50% larger than the views on August 2 and 8. Why? Interesting exercises ===================== 1. Use the bandwidths on July 24 and August 1 and sky motion to constrain diameter, then compare that estimate with visible delay extents. Use the X-band data Date bandwidth Jul 24 1.73 Hz Aug 1 3.05 Hz Difference: 3.05/1.73 = 1.76. Mid-epochs: date duration mid-epoch Jul 24 18:01:51-19:59:54 19:00:53 Aug 1 12:34:18-15:59:09 14:16:44 Elapsed time: 7 days, 19.264 h or 187.264 hours or 7.80 days Use Horizons to get the RA and DEC at those epochs: 1999-Jul-24 19:00 * 145.83595 65.53778 1999-Aug-01 14:16 *m 78.24947 33.85424 reason:/data/ast5/1999JM8/analysis < 23 > angle Enter RA1 (deg): 145.84 Enter DEC1 (deg): 65.54 Enter RA2 (deg): 78.25 Enter DEC2 (deg): 33.85 Angle = 50.3479 Steve discusses using two measurements of B at widely separated sky positions in his paper "Physical properties of asteroids from radar observations" which was published in "The Evolution of the Small Bodies of the Solar System" in 1987. I had read that before but never fully understood some key concepts. Now I do. Let's define alpha as the aspect angle, that is, the angle between the radar line of sight and the object's spin vector. Further, define alpha1 = alpha for the first measurement and alpha2 = alpha for the 2nd measurement. Then the angular separation gamma = alpha1 + alpha 2. Further, recall that B = 4 pi D sin(alpha)/(lamda P) Since we have two measurements of B, the bandwidth equation for one measurement by the bandwidth equation for the other measurement, giving: B1/B2 = sin(alpha1)/sin(alpha2) Since gamma = alpha1 + alpha2, we can substitute for alpha1 giving: B1/B2 = sin(gamma - alpha2)/sin(alpha2). Now apply the trig rule: sin(a-b) = sin(a)cos(b) - cos(a)sin(b), then solve for alpha2 giving: sin(alpha2)/cos(alpha2) = tan(alpha2) = sin(gamma)/(B1/B2 + cos(gamma)) From this we can compute both aspect angles (and thus subradar latitudes) and place a strong constraint on the pole direction. Interesting points: this doesn't depend on the diameter or directly on the rotation period. In the ideal case this applies to a spherical target but even if the target isn't spherical, one can use this if delay-Doppler images on different days look very similar (as is the case with JM8). So applying this to JM8 *does* depend on the rotation period because that's how we choose the epochs and thus bandwidths to compare. For 1999 JM8 there appears to be rotation about more than one axis, but if we ignore that and forge ahead, here's what we get: Let 1 refer to the smaller bandwidth and 2 refer to the larger bandwidth. Then tan(alpha2) = sin(50.3)/(1.73/3.05 + cos(50.3)) = 0.638 alpha2 = 32.54 deg => delta = 57.46 deg Thus alpha1 = 50.3 - 32.5 = 17.8 deg => delta = 72.2 deg. The implication is that the instantaneous subradar latitude was pretty high on both days. If JM8 were a PA rotator, then we could use Scott and Keith's polesearch software but since there are strong indications that JM8 is an NPA rotator, that wouldn't accomplish much. If we accept a synodic period of 7.80 days from the radar images, then the bandwidth and subradar latitude on August 1 imply that JM8 has a large diameter: D = (3.05 Hz)(187.3 h)/[(100)(cos(57.5))] = 10.6 km We observe a maximum delay extent on Aug 1 at Arecibo of 4.50 km, so if we assume that the true range extent is twice that, then that corresponds to a diameter of about 9 km, which is almost certainly too large. If we adopt Pravec's period of 6.76 days, then we get D = 9.2 km which is more consistent but still probably too large. Scott's 2nd iteration shape model based on 6 days of Goldstone images gives a maximum dimension of 5.2 km. The Arecibo image on Aug 6 has a maximum range extent of 5.3 km, so we already know that Scott's preliminary estimate is too small. So if JM8 is larger...then will that decrease the optical geometric albedo into the range of C-type objects? If so, then this is our first close look at a C-type NEA and only our 2nd close look (excluding KY26) at a C-type at all (the other was Mathilde by NEAR). reason:/data/ast5/1999JM8/analysis < 27 > pvd Enter the absolute magnitude: 15.2 Enter the diameter (km): 4.0 H = 15.200 d = 4.000 pv D (km) 0.091 4.000 --> It looks increasingly likely that JM8 is an optically dark object. As a simple exercise, compute the mean visible range extent from the Arecibo images: 4.2 km. Note that these observations cover about one rotation. In the unlikely event that the visible range extent equals the actual range extent, which it doesn't, then that still implies that JM8 is big and optically dark. The size that Scott obtained from the first 6 days is almost certainly too small and by a substantial factor. What does that say about the effective diameters he has obtained for other, weaker targets? The effects of the greater S/N at Arecibo on the visible range extents are dramatic. - - - - - - - - - - 2. Use sky motion and similarity of the images on July 24 and August 1 to get the sense of rotation directly. This is complicated by the fact that we don't know the rotation period precisely: Pravec's estimates have considerable variation and they don't seem to agree with the radar images unless JM8 has only one minimum and one maximum. JM8's motion was toward decreasing right ascension; that is, toward the west. Either retrograde or direct rotation satisfies the appearance in the images on July 24 and August 1, but the two senses of rotation imply different rotation periods: the period would be longer if the rotation is retrograde and vice versa. Let's accept that the images show the same side of the object. The mid-epochs of the observations are: date duration mid-epoch Jul 24 18:01:51-19:59:54 19:00:53 Aug 1 12:34:18-15:59:09 14:16:44 Elapsed time: 7 days, 19.264 h or 187.264 hours or 7.80 days Pravec's most recent reported period is 6.76 days, which is about 1 full day less than suggested by the radar images. If the rotation is direct, then the apparent rotation period of 7.80 days is shorter than the true period. If the rotation is retrograde, then the apparent rotation period of 7.80 days is longer than the true period. To be consistent with Pravec's result, retrograde rotation is necessary. Forging ahead with a simplistic analysis, if Pravec's rotation period is correct, then the difference in rotation should be about 46 degrees assuming very favorable geometry and assuming that we can ignore rotation about the other principal axes. Surprisingly, that's actually consistent with the sky motion between July 24 and August 1: 49 deg. Scott's 2nd iteration shape model had components of rotation of (3, 19, -29 deg/day) about the principal axes. That's from a very preliminary shape model (only 6 days of data, not much work to really nail the spin vector) but it's consistent with retrograde rotation. Thus, several lines of evidence combine to strongly suggest that the dominant component of JM8's rotation is retrograde with a period of close to 6.8 days. We can test that conclusion by comparing the images from August 1 and 8, which show similar views of JM8. Aug 1 12:33:37-15:59:25 14.2753 h Aug 8 14:29:39-17:08:07 15.8146 h Difference = 7 d 1.539 h or 169.54 h = 7.06 days. Granted, the similarity between the echoes isn't as close as it was on Jul 24/Aug 1--there appears to be a few tens of deg of rotation, so the comparison doesn't work as well. The sky motion was: 35.5 deg. Simplistic synodic rotation: 6.76 d/7.06 d = 0.96 -> 0.04(360 deg) = 15 deg of rotation. It looks like there's more than 15 deg of rotation between the two images. At any rate, I think this simple analysis puts us in the ballpark for largest component and sense of rotation. Have I got this backwards? As JM8 moves west, if it rotates directly, and if the spin vector is oriented north-south, then it should take less time to return to the same apparent rotation phase, and vice versa. The key is having images that show nearly the same phase on three rotations, which we have: July 24, August 1, and August 8. Actually, the key is August 8. The correspondence on that day isn't close enough to the other two days to be sure--there's rotation about more than one axis. I think that retrograde rotation is still the better explanation. Here are JM8's coordinates at 0 h UTC between July 24-August 10: RA (deg) DEC (deg) delta (AU) deltadot 1999-Jul-24 00:00 *m 154.41437 65.48882 0.0729799787 -7.69056 1999-Jul-25 00:00 *m 143.33838 65.45964 0.0687160350 -6.86743 1999-Jul-26 00:00 * 131.32287 64.45690 0.0649578359 -5.88191 1999-Jul-27 00:00 * 119.38845 62.27087 0.0618018613 -4.72382 1999-Jul-28 00:00 * 108.51756 58.86111 0.0593470104 -3.39796 1999-Jul-29 00:00 * 99.25159 54.36930 0.0576840650 -1.93111 1999-Jul-30 00:00 * 91.66133 49.06507 0.0568821013 -0.37460 1999-Jul-31 00:00 * 85.55073 43.27591 0.0569754679 1.20127 1999-Aug-01 00:00 * 80.64465 37.32662 0.0579563377 2.72116 1999-Aug-02 00:00 * 76.68425 31.49334 0.0597762537 4.12115 1999-Aug-03 00:00 * 73.45725 25.97670 0.0623559724 5.36002 1999-Aug-04 00:00 * 70.79900 20.89670 0.0655993159 6.42138 1999-Aug-05 00:00 * 68.58456 16.30462 0.0694061839 7.30876 1999-Aug-06 00:00 * 66.71945 12.20255 0.0736818483 8.03791 1999-Aug-07 00:00 * 65.13196 8.56266 0.0783420422 8.63002 1999-Aug-08 00:00 * 63.76725 5.34219 0.0833147553 9.10712 1999-Aug-09 00:00 *m 62.58290 2.49335 0.0885399893 9.48950 1999-Aug-10 00:00 *m 61.54582 -0.03091 0.0939684988 9.79470 Skymotion per day (0 h->0 h UTC) -------------------------------- Jul 24-25 4.6 deg Jul 30-31 7.2 deg Jul 31-Aug 1 7.0 deg Aug 1-2 6.7 deg Aug 5-6 4.5 deg - - - - - - - - - - USE DELAY EXTENTS TO PLACE LOWER BOUNDS ON DIMENSIONS OF FEATURES ================================================================= Can we use the delay extents and bandwidths of features in images obtained on consecutive days (when there was little sky motion) to constrain the km/Hz conversion? 1. As an example, consider the big "flat" side that is so prominent on August 4, 5, and 6. It's oriented nearly broadside on Aug 5 but it's tilted at a substantial angle on Aug 4 and especially Aug 6 (better S/N than on Aug 4: more looks). The bandwidth on Aug 5 is 1.01 Hz. The delay extent of the same feature on Aug 6 is at least 4.8 km. The Aug 6 image has lower S/N and not all of the flat side is illuminated, but clearly more than 90% of it is. The side isn't oriented along the LOS either but it appears to be within a few tens of deg of "vertical." So we get 4.8 km/1.01 Hz. That side is AT LEAST 4.8 km long. It's huge! So we could apply the same reasoning to the craters and other features seen on those two days. 2. "Indentation" on Aug 5 and 6 It has a delay depth of approximately 1.9 km. 3. ~linear ridge that is most prominent on Aug 4. It has a bandwidth of about 0.50 Hz. It's not oriented along the LOS in any of the images but it seems to be at it's steepest angle on Aug 3: ======================================================================== 2000 January 31 & Feb 1 ======================================================================== I wrote a short FORTRAN program to estimate NPA damping timescales using the expression in Harris (1994). Here are examples for JM8: Deff = 8.4 km ============= reason:/home/lance < 1 > damping Enter the rotation period in hours: 162.24 Enter the effective diameter in km: 8.4 period (h) = 162.2400 deff (km) = 8.4000 tau (10^9 y) + - --------------------------- 12.319 164.131 11.502 Deff = 4.2 km ============= reason:/home/lance < 1 > damping Enter the rotation period in hours: 162.24 Enter the effective diameter in km: 4.2 period (h) = 162.2400 deff (km) = 4.2000 tau (10^9 y) + - --------------------------- 49.275 656.524 46.008 If 6.76 days is a good approximation for the rotation period of JM8, then given the visible range extents and the lower bound (4.2 km) on the effective diameter that is implied, it's clear that we would expect JM8 to be a non-principal axis rotator. If Scott's estimate of Deff = 3.5 km is correct, then the nominal damping time increases to 71 E 9 y. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Surface bulk density ==================== The X-band circular polarization ratio of JM8 indicates that most of the echo power comes from single back reflections. Consequently, we can relate the OC radar albedo to the normalized reflection coefficient and thus back out constraints on the surface bulk density (refs). In the absence of a 3-D shape model we do not know the gain g, but from previous shape reconstructions we have found that g does not usually differ from unity by more than several tens of percent, which is less than the adopted systematic uncertainty in the radar cross section, so, to first order, we can assume that g = 1. Then R = the radar albedo +/- 100% and the bulk density d (R) = 3.2 ln[(1 + sqrt(R))/(1 - sqrt(R))]. d (R = 0.034) = 1.2 g/cm^3 d (R = 0.14) = 2.5 g/cm^3 We really can't do much until we have a better estimate for Deff. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - It's obvious that we'll need to write an Icarus paper to do this object justice. The question becomes whether or not we can also make the case for a Science paper. That depends on the shape model and what we extract from it. Regardless, I'm going to draft an Icarus paper first and then assess whether or not to approach Science and Nature with a shorter manuscript. Possible collaborations ======================= Clark Chapman? -------------- We have also addressed whether or not to invite Clark Chapman to join us as a collaborator to work on the distribution of impact craters and their significance. Steve seems eager to do this. I gather that he and Clark have a good relationship, but I think Steve is also looking to bolster political support for what we do by bringing Clark on board. On the other hand, R-plots and d/D plots aren't all that difficult to do or understand, so I'd prefer to do that myself. Once Scott and I establish criteria for what constitutes a crater (or, at the least, a concavity) then we can forge ahead. I'm not averse to working with Clark (I have great respect for his work and I'm rather fond of him personally) but I don't see that we really need him. It's also not yet clear how far we can go with crater analyses. Although there are many craters, a quick visual inspection suggests that the surface isn't even close to saturated. That is something that we'll be able to test using the larger craters. The abundance of large craters raise the obvious question of the effects that they've had on the spin vector of JM8. If the features about 1.4 - 1.5 km in diameter are craters, could they deliver enough momentum to produce the spin state? Or *remove* enough? There are enough large craters that it seems unlikely that JM8's spin state is primordial. Erik Asphaug & Dan Scheeres? ---------------------------- Erik Asphaug's impact modeling could prove quite useful and perhaps we could make some sense of the bizarre shape, large craters, and spin state by doing impact simulations (in collaboration with Scheeres?). It would make sense for Erik or Dan to be lead author. Another important question to address: is JM8 a rubble pile? How much of JM8's interior could the impactors that produced the craters plausibly fracture? Enough to rubblize JM8? Petr Pravec? ------------ Steve thinks we should invite Pravec to join us on an Icarus paper and I'm inclined to agree. I had rejected this idea earlier but I'm coming around to believe that it would be worthwhile to back out Hapke parameters and show the orientation of JM8 on the sky during lightcurve observations as Scott has done with other objects. Ideally it would be good if Petr publishes the photometry separately, as he did with Bacchus. Ellen Howell and Michael Hicks? ------------------------------- They both got vis-IR spectroscopy and Hicks got thermal IR radiometry. I'd be glad to go in with Ellen as lead author--we could show the orientation of the shape model when they were observing so we could potentially identify where optical spectral features are located on the surface. The collaboration with Hicks could prove to be a useful calibration of the thermal models and a natural follow-up to Golevka. David Rubincam/Bill Bottke? --------------------------- Do Yarkovsky forces affect the orbital and spin evolution of JM8? We could numerically integrate the orbit using the SWIFT code by Levison and Duncan and tap into David and Bill's expertise. This might work better with just David, but Bill could be a good liason since I don't know Rubincam personally. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - COMPARE JM8 WITH OTHER RADAR-DETECTED DARK OBJECTS PLUS MATHILDE ================================================================ It's clear now that JM8 is an optically and radar dark object. It's the best look with radar that we've ever had at such an object, but there are still others with which we can compare it: Mathilde, Phobos, Deimos, and possibly Ra-Shalom, 1986 JK, Betulia, and 1998 KY26. KY26 is so drastically different due to its small size, rapid rotation, and weak gravity that a comparison may not be very meaningful. For KY26 SC/OC ~ 0.5 and the radar albedo is between 0.012 and 0.11. The radar albedo estimates overlap very preliminary estimates for JM8. We don't know the radar albedo, effective diameter, or rotation period of 1986 JK. SC/OC = 0.26+/-0.02. That's close to estimates for JM8, but it's also close to the mean for ALL radar-detected NEAs, so it doesn't say much (yet). Correction: Steve estimated the radar albedo by adopting the best available estimates of the effective diameter from optical observations of H and the taxonomy, suggesting that the radar albedo is between 0.0053 and 0.067. The upper limit is consistent with that of JM8. 1580 Betulia was observed at both 3.5 cm and 13 cm in 1989. SC/OC is 0.18+/-0.03 at 3.5 cm and 0.16+/-0.01 at 13 cm. In the 1986 DA paper Steve reported that the radar albedo of Betulia is about 0.09, which is also consistent with the preliminary estimates. How well does the radar albedo of JM8 compare with the mean and rms dispersion observed among radar-detected main-belt targets? Chris Magri found that the main-belt C- and S-class radar albedos are indistinguishable. The lowest is 0.11 (Daphne) and a few others are about 0.13. Some, however, are as large as 0.23. Perhaps it would be more appropriate to compare the radar albedo of JM8 with the BFGP objects. Most of their radar albedos cluster at less than 0.1, although one (554 Peraga, type FC) is about 0.2. Conclusion: radar albedo of JM8 is consistent with other radar-dark C- and BFGP-type objects. SC/OC is less diagnostic due to the substantial observed range of values. What about Phobos? Steve mentioned that he's almost sure that the radar cross section and radar albedos that he published for Phobos are too small: he didn't trust the Goldstone calibration, which he later discovered were reliable. Steve's nominal estimated albedo is 0.093+/-0.035, which is consistent with results for JM8, although the consistency isn't as good if Steve's estimate is too small by ~20%. SC/OC = 0.09+/-0.10, so the decimeter-scale surface is smooth. This is all based on a ~9 sigma detection. SC/OC is about a factor of two smaller for Phobos than it is for JM8. Again, I don't think that SC/OC has reliable correlations with composition. Mathilde Mathilde is about an order of magnitude larger, but like JM8, is is optically dark (a C-type) and it has several very large craters relative to its diameter. Mathilde actually has *more* craters large compared with its diameter than JM8 does. Perhaps a better analogy with large craters would be Ida... Ida Ida is an S-type. Its effective diameter is 15.7 km. The largest craters are about 14 km in diameter; according to Chapman et al. (1996), there are 12 craters with diameters exceeding about 5 km, that is, with crater diameter/asteroid effective diameter ratios > 0.2. We don't know Deff of JM8 yet, but it already seems unlikely that there are this many relatively large craters on JM8 (only 4 obvious in the images have D >~ 0.9 km). Tisserand Parameter for JM8: ============================ reason:/data/ast5/1999JM8/analysis < 7 > tisserand Enter the semimajor axis (AU): 2.72 Enter the eccentricity: 0.644 Enter the inclination: 13.69 2.720 0.644 13.690 q = 0.968 Q = 4.472 TISSERAND PARAMETERS Neptune: T = 11.499 Uranus: T = 7.615 Saturn: T = 4.301 Jupiter: T = 2.988 Mars: T = 2.546 Earth: T = 2.819 Venus: T = 3.149 Mercury: T = 4.083 T = 2.988 is suggestive of a comet, but it's not compelling evidence: Valsecchi et al. (1995) found dynamical pathways between NEAs and JFCs so the distinction based on T is not robust. Encke is a good example of an object with an NEA orbit that is obviously cometary. However, an inactive comet nucleu is an intriguing possibility for JM8...we know that JM8 is dark, in agreement with the best-known comet nucleus albedo, Halley. There is strong evidence that Halley is a NPA rotator too. Need to get the refs... Belton et al.? The orbit of JM8 is almost surely chaotic, given that it crosses the orbits of Earth and Mars and approaches that of Jupiter. Just for fun I could fire up my old code and numerically integrate it for +/- a few thousand years, or I could do a more robust but shorter integration using Horizons. Track the evolution of the elements, close approach distances, and the evolution of T...estimate Lyapunov times. It's obvious that it's chaotic. Whether or not JM8 is a comet is a much more important question because we've never (to our knowledge) seen a comet as well as we've seen JM8. The semimajor axis of JM8 is comparable to but somewhat less than that of 243 Ida. I should write a short Perl code to parse the MPC NEA list files, compute Tisserand parameters, and then sort them. It might also be interesting to compute their mean, standard deviation, and plot a histogram. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Is JM8's orbit close to a strong mean-motion resonance with Jupiter? reason:/home/lance < 1 > resonance Mean-motion resonance maximum order = 25 Only matches within 0.01 of a resonance will be output Enter the period of the minor body (yr): 4.495 <== THAT'S WRONG! Planet convention: Mercury = 1, ..., Pluto = 9 Enter number of innermost planet to consider: 3 Enter number of outermost planet to consider: 6 Earth Period/period of Earth = 4.4948 Expected Difference ratio 2: 9 = 4.5000 0.0052 Mars Period/period of Mars = 2.3898 Expected Difference ratio Jupiter Period/period of Jupiter = 0.3789 Expected Difference ratio 8: 3 = 0.3750 0.0039 13: 5 = 0.3846 0.0057 18: 7 = 0.3889 0.0100 21: 8 = 0.3810 0.0020 Saturn Period/period of Saturn = 0.1526 Expected Difference ratio 7: 1 = 0.1429 0.0097 13: 2 = 0.1538 0.0013 19: 3 = 0.1579 0.0053 20: 3 = 0.1500 0.0026 25: 4 = 0.1600 0.0074 Closest mean-motion resonance detected: Saturn Ratio of periods = 0.1526 13: 2 = 0.1538 0.0013 This isn't as useful as it could be: I should modify resonance.f to compute the heliocentric semimajor axes of each resonance for comparison. Could even estimate the change in orbital energy necessary to get there from the present orbit. I modified my software "resonance.f" to output the semimajor axis corresponding to the close resonances and the difference in AU between the sma of the resonance and the asteroid. Here's the result for JM8 relative to Earth and Jupiter: Earth Period/period of Earth = 4.4858 Expected Difference ratio 2: 9 = 4.5000 0.0142 2.7258 0.0058 Mars Period/period of Mars = 2.3850 Expected Difference ratio 5:12 = 2.4000 0.0150 8:19 = 2.3750 0.0100 Jupiter Period/period of Jupiter = 0.3782 Expected Difference ratio 8: 3 = 0.3750 0.0032 2.7048 0.0152 11: 4 = 0.3636 0.0145 2.6499 0.0701 13: 5 = 0.3846 0.0064 2.7508 0.0308 18: 7 = 0.3889 0.0107 2.7712 0.0512 19: 7 = 0.3684 0.0097 2.6731 0.0469 21: 8 = 0.3810 0.0028 2.7333 0.0133 23: 9 = 0.3913 0.0131 2.7826 0.0626 25: 9 = 0.3600 0.0182 2.6322 0.0878 Threshold to display: difference of <= 0.02 in the period ratio. The difference between the orbit of JM8 and the 21:8 resonance is only 0.013 AU or about 5.1 lunar distances. That's pretty close. The 2:9 resonance with Earth is only about 2.2 lunar distances from JM8's semimajor axis. JM8 is closer to the 2:9 resonance with Earth in terms of semimajor axis than it is with any Jovian resonance by at least a factor of 2.3. How do you gauge the "strength" of a mean-motion resonance? We need to know that to assess which resonance is more important. This is a minor issue that we don't need to answer immediately--there are other more important issues to deal with, so return to this later. Perhaps the answer is related to the change in orbital energy that's necessary to drive an object into a resonance coupled with the magnitude of perturbations that a given planet can generate, which, in turn, are likely proportional to Mplanet/r^2. ======================================================================== 2000 February 2 & 3 ======================================================================== Tisserand parameter revisited ============================= I was curious about how unusual the Tisserand parameter for JM8 really is, so I modified my Perl script for computing and ranking delta_v for flybys to compute and rank NEA Tisserand parameters. Of 888 objects in the 2000 Jan 27 lists from the MPC, JM8 ranks 50th, that is, it's less than about 94% of all NEA Tisserand parameters. This doesn't include Jupiter- family comets. I posted the results on the web at: echo.jpl.nasa.gov/~lance/tisserand/tisserand.html Thus, although T for JM8 is similar to that of JFCs, it's also consistent with those of a subset of NEAs, 49 of which have smaller values. Those other NEAs generally have semimajor axes > 2.6 AU and many occupy orbits with eccentricitis > 0.5. Thus, the Tisserand parameter by itself is not compelling evidence that JM8 is an inactive comet nucleus. This would seem to confirm the results of Valsecchi et al. (1995), although it's also conceivable that some of these objects are inactive comets. It would be interesting to prepare a histogram of the Tisserand parameters. Save that for some other time. There's only one other NEA with T < T for JM8 that has been detected by radar: 1986 JK T = 2.9337 Here are the next five radar-detected NEAs in order of ascending T: Rank Object Provis. desig. T ---- ------ -------------- ------ 63 (8201) 1994 AH2 3.0242 68 (1036) Ganymed 1924 TD 3.0349 71 (6178) 1986 DA 3.0387 81 (1580) Betulia 1950 KA 3.0659 93 (4197) 1982 TA 3.0890 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I'm still pounding away on the draft Icarus manuscript. There's a lot to cover... it's almost overwhelming. Steve wants a draft of the whole thing (including the shape model) by the end of the month. It's my hope to have a first draft of everything except the shape model by the end of next week. The most challenging section to write (w/o the shape model) is the description of the images. That's next... then go back to fill in more of the intro, the CW results, the astrometry (to the extent that we can complete it), and the discussion. I haven't done much yet with the figures: the imaging figures will be a good reason to plunge into IDL. We'll need logarithmic stretches for most. The SC/OC figure is doable using screen-grabbed gifs from Transform imported into Tkpl, but it might be easier using IDL. Another project for IDL: skymotion plotted on a sphere. There really aren't that many figures that I can create without the shape model. ======================================================================== 2000 February 4 ======================================================================== Continuing to work on the draft. I'm reading some of the Mathilde papers to check that I've covered the important issues that we can address. One thing we haven't mentioned in any of our papers is a satellite search. I've done some simple calculations for 1998 ML14 and for JM8 to see whether or not the Goldstone and Arecibo images covered enough range and Doppler frequency to include likely asteroid orbits, using the Hill sphere as a guide. We could refine that by referring to the results from Hamilton and Burns (1991) but it won't make much of a difference except for pathological retrograde orbits. I mentioned to Mike Nolan and Jean-Luc Margot that we should consider satellite searches when I was at Arecibo in August. We did a couple of runs with a 4-usec baud on August 1 with a 65535 code that more than encompasses the Hill sphere, and I checked that image when I was at AO for possible secondary echoes. I found none. The Gaspra, Ida, Mathilde, and Eros papers have all discussed satellite searches and with Ida they found one. Since the caliber of our observations is better than that of the 1998 Eros flyby, should we discuss satellite searches too? I'm inclined not to since there's already so much to cover, but it might be good to put something in print to let the community know that we're looking and what our techniques are. Satellite searches are another good argument for using really long codes at Arecibo in order to cover lots of range. On the flip side, though, long codes limit our ability to sample widely in Doppler frequency, so it's conceivable that in so doing we could miss a satellite outside the passband. For example, using a 65535-code with a 0.1 usec baud gives a bandwidth of only 152 Hz. We don't use such long codes at Goldstone so it's less of a problem there, although, of course, the drawback is that the system isn't as sensitive. We didn't exhaustively search the Arecibo 0.1 usec images: there were so many pixels that Mike Nolan (correctly) vignetted the echo and ignored the rest. Perhaps insert a concise paragraph summarizing what I wrote above...? Issues: Diameter from Hamilton & Burns & comparison with Hill sphere. -Depends on asteroid's effective diameter and density. Assume plausible upper and lower bounds on the density and compute. Doppler frequencies covered and expected shifts from plausible orbits Bauds and frequency resolutions vs. size and rotation period of satellite Registration of the images vs. time: satellite motion will smear the echo in delay and Doppler. ======================================================================== 2000 February 8 ======================================================================== I backed up the JM8 reduction log and draft manuscript onto think:/public/protected/lance/1999JM8/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Radar bright annulus on July 28 ------------------------------- Near the center of the July 28 image is a radar-bright annulus encompassing a group of pixels that are about 100 m in diameter, suggesting a small impact crater with a radar-bright feature surrounding it. Radar-bright features surrounding impact craters have not been seen previously in radar images of asteroids, but they have been found surrounding impact craters in Haystack (Thompson et al. 1981) and Arecibo (Stacy et al. 1997) radar images of the Moon and in Arecibo (Burns and Campbell 1985, Campbell et al. 1990), Goldstone (Jurgens et al. 1988), Venera (Basilevsky et al. 1987), and Magellan (Phillips et al. 1991) images of Venus. The feature on 1999 JM8 may be the signature of an impact crater with a rough surrounding near-surface at decimeter spatial scales. If the annulus formed as a result of an impact, then it may be geologically young because impact gardening should remove such features over short geologic timescales. Significant regolith retention is not expected on JM8 due to its weak gravity, so if the annulus does surround an impact crater, then it may be the result of proximal surface shaking, as Asphaug et al. (1996) proposed to explaing optical annuli surrounding craters on 243 Ida. The literature on radar observations of Venus and the Moon is vast, so there may well be earlier papers that report bright annuli surrounding craters than the ones I cited. From my brief perusal of several papers, it appears that Don Campbell et al. weren't sure in early Arecibo images whether or not they were seeing impact craters or volcanic craters (as it turns out, the answer is probably both), so they didn't make definitive claims. Use the shape model to locate this feature on the asteroid and determine whether or not we imaged it on other days. ==> USE TRACE See bright rims in SC images of the Moon from Haystack data (Thompson et al. 1981) and from Arecibo SC and OC images of Venus (Campbell et al. 1990, GRL 17, 1389). Stacy et al. (1997) reported bright SC rims on the moon and bright SC/OC features associated with some craters. The potential youthfulness of this feature is important. We haven't seen radar-bright crater rims on asteroids before. To assess the number of craters on August 4-6, print out SC and OC images, then circle and number the features. For now I'm using visual inspection. I compare images on different days to verify that features repeat. Some of the features that I'm circling are on the edge--my best estimate is that they're craters but the evidence isn't overwhelming. Estimate the crater dimensions using the range extents (using my best esimates for the crater rims): Date Possible craters ---- ---------------- Aug 4 4 All are evident on August 5 Aug 5 25 Aug 6 15 Most are evident on Aug 5, but 3 on the approaching limb aren't. Crater identifications on Aug 6 are difficult due to SNR Units: meters Aug 4 Aug 5 Aug 6 feature range extent range extent range extent ------- ------------ ------------ ------------ 1 675 405 2 285 270 3 435 435 360 4 570 480 375 5 315 330 6 195 7 225 8 150 9 270 10 195 11 405 12 600 495 13 270 270 14 195 225 15 435 525 16 450 405 17 195 18 180 19 135 20 135 21 135 22 270 23 210 24 360 270 25 465 465 26 225 27 165 315 28 360 29 Too vague: can't see rims. May be 2+ craters. 30 Too vague: can't see rims 31 225 Some of the day-to-day estimates match well; others differ by up to a factor of two. The factor of two differences suggest I should discard one or both estimates--perhaps I'm not seeing a crater. Crater 27 is a good example: it's very hard to locate in the August 5 image, but it's easier on August 6. With other examples, such as crater 12, it seems clear there's something there, but the low S/N makes discerning the crater dimensions accurately difficult. One way to improve the accuracy of these estimates is to measure them multiple times: say, three times. Ugh. Hold off for now until we see what we've got. I just noticed from careful inspection of craters on Aug 4 and 5 that the rotation about more than one axis is evident in the images. Specifically, craters 2-4 appear to be deeper into the echo from the LE on Aug 5 than on Aug 4. This could distort some of the images enough to make the visible range extents different. What we can say with confidence is that we can see craters on these three days (and on others) rotating in delay-Doppler from day-to-day. That is, some craters are clearly present in images on two or more days in succession. Their range extents place lower bounds on their dimensions, subject to projection effects. Although I'm not confident that all the proposed features are actually impact craters, the August 4-6 images strongly suggest that there are many craters on the surface that are between about 100-600 meters in diameter (perhaps even larger). We tentatively identify about 30 such craters from the images on these three days. These craters appear to be on the opposite hemisphere from craters seen on July 24, 31, August 1-3 and August 8-9 so I suspect that they aren't the same. The craters on the other days were less numerous and much larger. Seems to indicate a significant difference between hemispheres, which would be interesting. Why would one side have more much larger craters than the other? The side with large craters might not have as many small ones because the big craters could have "erased" the smaller ones. For the draft, don't put too much emphasis on the dimensions of the craters: base that on the shape model. Crater 3 appears to have a radar bright annulus around it, although it doesn't stand out as well as the one on July 28. Using Transform, it is necessary to boost the saturation to about 200 sigma before this becomes evident. This crater is near the LE so perhaps that is facilitating seeing the rim. From inspection, this is the only other crater noted to date in which one can trace radar bright pixels all the way around it. One of the questions this raises is: how are we defining a radar-bright rim? There appears to be a continuum of rims--for example, the tear-shaped features have radar bright perimeters that one can trace most of the way around the dark pixels. Clearly in many instances the near rim and distal rims face the line of sight and thus are bright. It's the orthogonal rims that are intriguing. The proximal radar bright rims are also interesting because they probably indicate that the rims are topographically raised. There's a general tendency of nearly complete radar bright rims for craters that are closest to the leading edge (Aug 5). Are stratigraphic relationships evident from any of the craters or other features? I haven't seen any obvious evidence yet...but also need to be aware of the north-south ambiguity, which could make features appear to overlap. There appear to be a few clusters of adjacent craters such as 25, 24, 31; 3, 4; 6-10; and perhaps 16-21. ======================================================================== 2000 February 9 & 10 ======================================================================== I'm outlining more craters on the other days when we have enough detail and S/N to identify them. Several of the craters visible on Aug 4 and 5 are also visible on August 3. Comparing those craters makes it obvious that the asteroid's apparent rotation is about more than one axis. I've tallied 14 likely craters in the August 3 image. I'm pretty sure that four on the approaching limb are visible on Aug 4 and 5. There is a cluster near the center of the Aug 3 image that may or may not be visible on Aug 5; it's hard to tell because the rotation between the two days appears to be about more than one axis, and because the craters are not evident in the Aug 4 image (the one where we got only 5 runs). What I don't see is an obvious correspondence between small craters on August 3 and small craters on Aug 2: the region in the Aug 2 image where there should be craters doesn't show any. If we ignore the Aug 3 mystery craters that I can't confidently link with those seen on other days, there are still about 40 craters that I have identified elsewhere and I've made a point of being careful not to count the same features more than once (I've numbered each feature on a hardcopy). Obviously the shape model will help determine which features are actually concavities and their locations. I labelled the ~40 craters on hardcopies of the images. Perhaps IDL will allow us to label the images directly? Another cumbersome option would be to use tkgraph: do screen grabs on the images, import into tkpl, then use text, arrows, circles, and ovals to label possible concavities. What a tedious task! I've been pushing the radar bright annulus surrounding a small concavity about 100 m in diameter in the July 28 image, but after looking at all the concavities, it's not clear to me that the one on July 28 is special. I had thought that it was reminiscent of radar bright rings seen around craters on the Moon and Venus, but this begs the obvious question: how do you define a radar bright ring? With numerous concavities we see a narrow bright ring that appears to coincide with the rim, but that's not unusual. What _would_ be interesting would be if the annulus clearly extended beyond the concavity. I don't think we have enough resolution with the July 28 feature to claim that it does. Let's just point it out as a possibility but not dwell on it. It's always safer to underinterpret. Some comparison with bright rim craters on other objects is useful though. I may have missed something important about the bright rims: the rim of crater 36 is obvious when it's tear-shaped or elliptical (Aug 1-3, 8; this is most obvious when it's near the approaching or receding limbs). The rims don't appear prominent when the craters are near the "middle" of the echo and appear "circular." Crater 32 isn't as good an example, even though it looks somewhat elliptical in some images. Crater 36 appears circular only on July 31 when it's a weak feature near the approaching TE. Careful inspection of the July 31 and August 1 images reveals that I mislabelled some features on the hardcopies. The July 31 image clearly shows one big concavity (#32) and suggests the other big one (#36) near the TE on the approaching limb. There are two other craters adjacent to #32: #37, which is ~xx in range extent, and #35, which is ~yy m in range extent. 35 and 37 aren't so obvious in the August 1 Goldstone or Arecibo images, but I've finally found them in both. What's intriguing is that #37 appears almost inside #32 on August 1 and it clearly has a collection of bright "rim" pixels on Jul 31 and Aug 1. The bright rim is much more prominent in the Arecibo image (but it's visible in the Goldstone image too), to the point that I did not recognize it as a concavity. It appears that the proximity of the two concavities lead me to think that #32 has a larger range extent on Aug 1 than I previously thought. Date No. of concavities ---- ------------------ Jul 31 5 LOW RES GOLDSTONE Aug 1 8 (Arecibo) 2 9 3 14 4 5 5 26 6 15 7 1 LOW RES GOLDSTONE 8 3 LOW RES GOLDSTONE 9 3 Ignoring the low-resolution Goldstone results, the fewest are visible on August 9 and the most are visible on August 5. There could well be many other small craters close to the limit of the resolution that I'm excluding (all the ones I've tabulated have range extents > 100 m). There may be other concavities that are visible but that I haven't recognized: this is reasonable because some are quite subtle. I went through the tedious task of estimating range extents for all the other craters, which I tabulated in file "concavity.dimensions" There are 43 features in the list. There are six features visible on Aug 3 that I was unable to link with features on other days (especially Aug 5), but to avoid counting them twice, I ignored them on Aug 3. It turns out that there are 3 features larger than about 1 km and 5 or 6 larger than about 500 meters. About 1/2 are between 200-400 m in range extent. This isn't as robust as I would like, so I'm trying to be careful and not draw sweeping conclusions. I don't know if we'll be able to do meaningful R-plots or d/D estimates for JM8, but we should be able to get meaningful information on the geographic distribution of features as a function of size. ======================================================================== 2000 February 16 ======================================================================== Steve gave a talk on Feb 11 in which he showed gravitational slopes on the Golevka shape model. Slopes exceed the angle of repose near particularly sharp topography that are mostly near the edges of the shape. That means that those regions are nearly devoid of regolith. That offers some interesting opportunities: we could compare SC/OC maps with the surface slopes to indentify whether roughness or lack thereof is related to regolith. In principle, we could also estimate the % of the surface illuminated by the Sun (and even identify where, once we know the spin vector and shape model), and compare it with vis-IR spectroscopy. We could also compare with photometry to test theories about optical scattering by regoliths and Shepard's lab measurements of the opposition effect on bare rocks. Ideally we'd like to make radar albedo maps to back out the surface bulk density. At present we don't have calibrated delay-Doppler images but the other ideas are tractable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Greg Black has installed and tested tkrdfreduc and tkpl on his computers at NRAO in Green Bank. He also wrote and tested CW reduction software in IDL and compared the results with those he got from tkrdfreduc using Arecibo Callisto data. He found a bug in our software rnb.cc, which removes the noise background. Evidently sdev is being computed correctly but the normalization of the spectra is not, so the net result is that the radar cross sections are about a factor of sqrt(3) too high. Greg identified the lines of code where the error exists and Mike Thomas is going to fix it. I noticed problems with the JM8 noise statistics last fall but thought it was a problem with the tkpl filter, not the statistics themselves. Yesterday I plotted noise statistics for a JM8 spectrum obtained on the first day (199) with low freq. resn and about 480 looks: the noise wasn't well fit by a Gaussian--there is an excess of ~1 sigma points. I checked 1991 CS spectra from DOY 240 and 241: the noise statistics look OK. As a double check, I converted the CS files into the old PLAY format and checked the noise with that software too. The results aren't identical to those obtained with TKpl (because we don't know the number of bins that PLAY uses in its histograms), but they're a close match. This raises obvious questions: 1. Is Greg right? Why didn't we notice this before? 2. If Greg is correct, then some of our published radar cross sections, radar albedos, and surface bulk densities are incorrect: they're a factor of 1.7 too small. 3. Is this a problem only with the VME format CW data or with _all_ the CW data, including old cw data obtained with Goldstein's IBM? 4. Why do we get an excess of 1-sigma points with the JM8 spectrum? Is it an artifact of not having enough Doppler bins (only 128)? --> Could test with 4 kHz sampling data. 5. Recent published objects that could be affected: 1998 KY26, Toutatis (1996), Bacchus, 1991 CS, 1992 QN, 3103 Eger, 2062 Aten. Current papers in progress: 1999 JM8, Golevka, 1999 GU3, and maybe 2100 Ra-Shalom. Other implications: the radar cross section of Mercury. That's been down by several dB for at least several months. Is part (or most) of the problem with our software? I suspect not because Ray Jurgens got results nearly the same as mine using independent software. Does Ray's software make the same mistake as ours? That doesn't seem likely. I have a hard time believing that the radar cross section of Bacchus is larger by a factor of 1.73 becauase that would increase our nominal radar albedo to 0.56, which is VERY high. That's comparable to the radar albedo of 1986 DA, which is a metallic object. Bacchus isn't metallic (optical spectroscopy places it among the Q-S continuum), but this would bolster the case that it may be bare rock or stony/iron. The factor of 1.7 would increase the normal reflectivity coefficient R to 0.40 and the bulk surface density to 4.8 g/cm^3 (from 3.3 g/cm^3). That increase in R would effectively rule out an ordinary chondrite composition for Bacchus in favor of a stony-iron or iron composition, neither of which is favored by the optical spectroscopy. That is hard to believe... The issue may be Goldstone's tendency to produce hops that vary in time duration, unlike the situation at Arecibo prior to the upgrade, when the hops all had the same length. Keith modified the reduction software to handle this... maybe that's the source of the problem... the Bacchus and 1991 CS observations wouldn't have been affected because I probably threw out incomplete hops, or perhaps because there were so few of them. At any rate, perhaps that's where the error crept in. Steve suggested that I compute the radar cross section directly from individual hops without using rnb.cc. Use raw spectra to estimate the background and the echo. I'll try that for 1999 GU3, 1999 JM8, and Mercury. Mercury and JM8 will be strong enough but I don't know if I'll be able to see echoes in individual hops with the GU3 data. ======================================================================== 2000 February 23 ======================================================================== Scott submitted the Golevka paper earlier this week, so I started asking him again about JM8. Although there's still work to do on the draft manuscript, the shape model is the bottleneck at this point. I haven't prepared camera-ready figures yet either. Some of those will take a lot of time and may require learning IDL. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /data/ast5/ is 96% full largely due to JM8 files. There's 84 Meg of space left (the partition holds 2.077 Gig). The JM8 files account for a lot of space: reason:/data/ast5 < 374 > du -ks * 787367 1999JM8 10 4179_Toutatis_2000_arecibo 19 4179_Toutatis_2000_goldstone 601696 6489_Golevka 13409 delta 92208 hudson 47784 jx_src 2 lost+found 191634 ostro Which JM8 files are taking up so much space? reason:/data/ast5/1999JM8 < 407 > du -ks * 1 README.TXT 1285 analysis 193 archives 151878 arecibo <== These files are on /data/ast5/ 850 html 1 paper 88189 proc 542865 raw 2104 support It's the raw imaging files... Those files are all properly reduced and backed up onto multiple CDroms and exabyte tapes, so let's remove them. I double checked that I backed up the raw files: YES. Most of the raw VAX files are already gone. The ones taking up all the space now are the unreduced rdf files created by running vax2rdf. Have those files been backed up onto CDroms? Many have, but not all: I worked on some of those files in late November when I did the image reductions correctly. Find out which ones I have backed up onto CDroms and then remove them. Evidently I made minor modifications to several files in November. I'll back up those files onto CDroms during the next iteration (as soon as Richard Zinar figures out what's wrong with the cd burner software). Removing the other files liberated about 400 Meg. Updated disk space: reason:/data/ast5/1999JM8 < 508 > du -ks * 1 README.TXT 1285 analysis 193 archives 151878 arecibo 850 html 1 paper 88189 proc 127861 raw 2104 support rhyme:/data/ast5 2077232 1369472 500040 74% /data/ast5 rhyme:/data/ast6 2082712 1399504 474944 75% /data/ast6 ==> We're in pretty good shape now. Note: I need to make multiple backups of the Arecibo CBR data files--we have only the one CDrom that Mike Nolan sent. Once that's done, I'll remove the Arecibo files. ======================================================================== 2000 March 1 ======================================================================== I got backups onto CDroms to work again, so let's do that with the JM8 Arecibo data. The Arecibo files take up 451 Meg of space. Those are the files in the raw directories. The other JM8 files take up 372 Meg. Burn, baby burn... I'm making three disks: one for the office, one for myself to take home, and one for Steve to take home. ...done. I deleted the rdf files. We have plenty of disk space on ../ast6: reason:/data/ast6/1999JM8_arecibo < 118 > df -k Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t1d0s0 31239 14178 13941 51% / /dev/dsk/c0t1d0s6 246167 192500 29057 87% /usr /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd /dev/dsk/c0t1d0s4 246167 18321 203236 9% /var /dev/dsk/c0t1d0s7 1057078 59238 892140 7% /export/apps0 /dev/dsk/c0t1d0s5 61735 11785 43780 22% /opt /dev/dsk/c0t1d0s3 61735 9 55556 1% /usr/vice/cache swap 346416 1488 344928 1% /tmp /dev/dsk/c0t2d0s0 771110 438316 255684 64% /usr/local/src /dev/dsk/c0t2d0s1 2118718 1186912 719936 63% /data/ast1 /dev/dsk/c0t2d0s3 2118718 1480278 426570 78% /data/ast2 /dev/dsk/c0t2d0s4 963869 810119 57370 94% /dev1 /dev/dsk/c0t2d0s6 2338501 1941488 163163 93% /usr/local rhyme:/data/ast4 2077232 1609848 259664 87% /data/ast4 rhyme:/data/ast5 2077232 1373152 496360 74% /data/ast5 rhyme:/data/ast6 2082712 1037072 837368 56% /data/ast6 <== rhyme:/cdmaster 1968608 315320 1456432 18% /cdmaster rhyme:/data/ast3 2077232 1621512 248000 87% /data/ast3 rhyme:/export/home/ostro 874160 709656 77088 91% /home/ostro rhyme:/export/home/lance 874160 709656 77088 91% /home/lance rhyme:/export/home/wart 874160 709656 77088 91% /home/wart - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DOY 199 CW reduction revisited ============================== Over the last two weeks I've done extensive tests of our CW reduction software using noise background removal, polynomial background removal, and estimating radar cross sections using raw hops. The polynomial and raw hop reductions for Mercury give consistent results with each other but both give radar cross sections that are 12-21% larger than the results we get using noise background removal (the "regular" method). Greg Black suggested that there's a bug in our software but Steve doesn't fully believe it yet. Meanwhile, Mike Thomas revised rnb.cc in the rdfreduc pipeline to incorporate Greg's fix, but that fix isn't the default yet. About two weeks ago (Feb 15) I reduced JM8 cw data and got weird noise histograms. The file was 99199b. I used dofft with a 512 point FFT to get lots of looks. Unfortunately, that provides a relatively small number of frequency bins (only about 128), so that could be the reason why the histograms are off. I want to to double check the histograms and also check the results of different methods of noise removal on the radar cross sections. Use this file instead: 99199-16k CW 4000 15 6 212119-213931 Go with a 4 k FFT => plenty of looks and plenty of Doppler bins. That file does not exist as a VOLT file: recall that we started the expt. with a 4 k FFT and then switched it on the fly to a 16 k FFT. That produced two PSD files but there's only 1 VOLT file with 4 kHz sampling: VOLT99199.1999JM8 There are 7 runs total. This didn't work the first time I tried: I forgot that I had compressed the PRDX file. dofft couldn't read it. reason:/data/ast5/1999JM8/proc/cw < 104 > dofft -d 5.0 -p 163 -f 4096 -i VOLT99199.1999JM8 -o 99199.4k.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 4096, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199.1999JM8 RDFOUT_1=99199.4k.raw.1_1.rdf RDFOUT_2=99199.4k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199.4k.raw.1.rdf -o 99199.4k.raw.rdf -x PRDX.OUT.s15 -p 163 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 627 Total SC spectra: 627 Processing data... reason:/data/ast5/1999JM8/proc/cw < 105 > So far, so good... There are 627 FFTs. As usual, irun values all equal one. Rats. There are a lot of hops too. I wish Ray's software output hops instead of FFTs. Run spectra --- ------- 1 1- 91 2 92-180 3 181-268 4 269-358 5 359-448 6 449-538 7 539-627 I fixed all the irun values. Printing out the rcsta values with enscript was a pain: the top lines were truncated. The option -P printer didn't work when I tried printing to lexmark. Run this the rest of the way through the pipeline using noise background removal... Note: I haven't looked at individual hops yet. That'll be a real pain but it can be done: sum each hop. The hops have different numbers of FFTs so the baselines will jump around. Got rnb errors: rmsc is not what it should be, so rmsc was changed. This is the problem that Greg Black has pointed out. I want to repeat the reduction using the "fixed" rnb.cc. e/m values are very good for ch2 and pretty good for ch1: some are as low as 0.4 but most exceed 0.9. Ch1 = OC Ch2 = SC Individual runs look OK. These echoes are probably strong enough to get cross sections from the hops. change jsnr1,2 = 510, 519 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-oc 21:37:57 00:00:00 21:39:31 0.0 2.56e-03 1.56e+00 ± 3.7e-03 2.0 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-sc 21:37:57 00:00:00 21:39:31 0.0 2.78e-03 3.04e-01 ± 3.9e-03 1.9 0.195498 0.198065 0.192933 OCxsec = 1.56e+00 km^2 SCxsec = 3.04e-01 km^2 SC/OC = 0.19 First pass at the noise histograms is very discouraging: they look horrible. There are 627 looks so they should be OK, unless something is wrong with the data... May need to check individual hops. Rats. Look over the tags again...maybe tau is wrong...No, maybe this is the effect of the rnb problem. That's the most obvious answer. Steve agrees. Why didn't we see this with Mercury? Two hops... What about 1991 CS? those observations used 4 hops (IBM data). Try a polynomial reduction instead. Then try reducing one raw hop with lots of FFTs. Polynomial reduction ==================== Polynomial reduction uses rpb.cc, not rnb.cc, so I didn't get the error messages. change jsnr1,2 = 510, 519 Sum runs; remove baseline with 4th order polynomial. OC noise histogram looks weird: off centered. It's possible that the big noise spikes at both ends are distorting the noise distribution. Poly redn OC S/N is much higher: about 800 sigma vs. 400 sigma for rnb red'n. Baseline isn't flat and there are some big noise spikes. Zoom in to check: Ugh. Noise statistics won't work because background removal didn't produce a flat baseline. We can still extract cross sections, though. Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.poly.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-oc 21:37:57 00:00:00 21:39:31 0.0 2.22e-03 2.72e+00 ± 3.2e-03 2.0 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.poly.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-sc 21:37:57 00:00:00 21:39:31 0.0 2.41e-03 5.31e-01 ± 3.4e-03 1.9 0.195112 0.196374 0.193851 OCxsec = 2.72e+00 km^2 SCxsec = 5.31e-01 km^2 SC/OC = 0.19 Notice how much larger the polynomial result is: they're in a ratio of 2.72/1.56 = 1.74, which is very close to sqrt(3). Damn. Looks like Greg was right. The ratios are the same to two significant digits. RAW HOP REDUCTION ================= Sum a bunch of FFTs; don't remove baseline. Here are the first several hops: rows irun xjcen -------------------- 1 1.0 513.0 2 1.0 513.0 3 1.0 513.0 4 1.0 513.0 5 1.0 513.0 6 1.0 513.0 7 1.0 1537.0 8 1.0 1537.0 9 1.0 1537.0 10 1.0 1537.0 11 1.0 1537.0 12 1.0 1537.0 13 1.0 1537.0 14 1.0 1537.0 15 1.0 1537.0 16 1.0 1537.0 17 1.0 1537.0 18 1.0 1537.0 19 1.0 1537.0 20 1.0 1537.0 21 1.0 1537.0 22 1.0 1537.0 23 1.0 1537.0 24 1.0 1537.0 25 1.0 1537.0 26 1.0 2561.0 27 1.0 2561.0 28 1.0 2561.0 29 1.0 2561.0 30 1.0 2561.0 31 1.0 2561.0 32 1.0 2561.0 33 1.0 2561.0 34 1.0 2561.0 35 1.0 2561.0 36 1.0 2561.0 37 1.0 2561.0 38 1.0 2561.0 39 1.0 2561.0 40 1.0 2561.0 41 1.0 2561.0 42 1.0 2561.0 43 1.0 2561.0 44 1.0 2561.0 45 1.0 3585.0 46 1.0 3585.0 47 1.0 3585.0 48 1.0 3585.0 49 1.0 3585.0 50 1.0 3585.0 51 1.0 3585.0 52 1.0 3585.0 53 1.0 3585.0 54 1.0 3585.0 55 1.0 3585.0 56 1.0 3585.0 57 1.0 3585.0 58 1.0 3585.0 59 1.0 3585.0 60 1.0 3585.0 61 1.0 3585.0 62 1.0 3585.0 63 1.0 3585.0 64 1.0 513.0 65 1.0 513.0 66 1.0 513.0 67 1.0 513.0 68 1.0 513.0 69 1.0 513.0 70 1.0 513.0 71 1.0 513.0 72 1.0 513.0 73 1.0 513.0 74 1.0 513.0 75 1.0 513.0 76 1.0 513.0 77 1.0 513.0 78 1.0 513.0 79 1.0 513.0 80 1.0 513.0 81 1.0 513.0 82 1.0 513.0 83 1.0 1537.0 84 1.0 1537.0 85 1.0 1537.0 86 1.0 1537.0 87 1.0 1537.0 88 1.0 1537.0 89 1.0 1537.0 90 1.0 1537.0 91 1.0 1537.0 The 2nd hop looks fine: spectra 7-25. background is at about 2.4e9 arbitrary units. vignette by 1000 on left and 2000 bins on the right. divide by 2.4e9 to locate the echo Echo is between bins 536 and 541 use *vig* file to subtract 2.4e9 the sum the relevant points. Oh, hell: there are only a handful--do it by hand. Here they are: rows 536 537 538 539 540 541 ---------------------------------------------------------------------------------------------- 1 188440576 1608561408 18934968320 55651524608 7918448640 783266816 Sum = 8.51e10 (<== I double checked this) Tsys = 15.2 (tag value; actual value was slightly different) background = (2.4e9)*(6) = 1.44e10 E/B = 8.51e10/1.44e10 = 5.91 band = (6 bins)*(0.9766 Hz/bin) = 5.859 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(5.859 Hz) = 1.23e-21 W Prcv = 5.91*(1.23E-21 W) = 7.26E-21 W Prcv = Ptx*(G^2)*(lambda^2)*OCxsec/[((4*pi)^3)*(d^4)] Or... OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] G^2 = 691.6E12 RTT = 99.7 s*(150 m/1E-6 s) = 1.50E10 m Ptx = 425000 W OCxsec = (7.26E-21 W)*(64*31)(1.50E10^4)/[425000*691.6E12*0.035*0.035] = 2.025E6 m^2 OR... (2.025E6 m^2)*(1 km/1000 m)^2 = 2.03 km^2 Unfortunately, this is intermediate between the polynomial reduction result (higher) and the rnb result (lower). Regardless, the rnb result is lower than both other results. ======================================================================== 2000 March 2, 3, & 5 ======================================================================== The discrepancy between the raw hop redn and the polynomial redn is odd. Steve suggested summing all the ffts in each hop and then using the resulting spectra to do the red'n. Hop FFTs --- ---- 1 1-6, 64-82, 92-95, 153-171, 203-221, 269-272, 330-348, 382-400, 449-451, 509-527, 560-578 2 7-25, 83-91, 96-114, 172-180, 222-240, 273-291, 349-358, 401-419, 452-470, 528-538, 579-597 3 26-44, 115-133, 181-183, 241-259, 292-310, 359-362, 420-438, 471-489, 539-540, 598-616 4 45-63, 134-152, 184-202, 260-268, 311-329, 363-381, 439-448, 490-508, 541-559, 617-627 Hop FFTs --- ---- 1 146 2 171 3 142 4 168 Background levels are about 7e9 units; echoes are strongest in hops 2 and 4, which have the most spectra. background levels are about the same in both channels Hop background --- ---------- 1 2 6.8e9 3 4 ===== Hop 2 ===== hop 2 normalized by 6.8e9: rows 1536 1537 1538 1539 1540 1541 1542 ---------------------------------------------- 1 1.32 1.94 8.74 35.67 3.86 1.56 1.16 rows 1536 1537 1538 1539 1540 1541 1542 ---------------------------------------------- 1 1.01 1.17 2.64 7.91 1.60 1.18 1.01 Use points 1538-1540. Unnormalized: rows 1536 1537 1538 1539 1540 1541 1542 ----------------------------------------------------------------------------------------------- 1 8961508352 13209784320 59429937152 242577473536 26246967296 10636954624 7880826880 rows 1536 1537 1538 1539 1540 1541 1542 ----------------------------------------------------------------------------------------------- 1 6839524352 7946156544 17976283136 53762555904 10866804736 7997476352 6854330368 OC Echo points 1538-1540: 59429937152 + 242577473536 + 26246967296 = 3.28e11 background = (3 points)*(6.8e9) = 2.04e10 bandwidth = (3 bins)*(0.97656 Hz/point) = 2.93 Hz E/B = 3.28e11/2.04e10 = 16.08 base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(2.93 Hz) = 6.15e-22 W Prcv = 16.08*(6.15E-22 W) = 9.88E-21 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] Tsys = 15.2 G^2 = 689.3E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W OCxsec = (9.88E-21 W)*(64*31)(1.494E10^4)/[425000*689.3E12*0.035*0.035] = 2.72E6 m^2 OR... (2.72E6 m^2)*(1 km/1000 m)^2 = 2.72 km^2 That matches the result from the polynomial reduction, as it should. ===== HOP 4 ===== Tsys = 15.2 G^2 = 689.2E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W Divide by 6.8E9. Here's the echo: rows 3584 3585 3586 3587 3588 3589 ---------------------------------------- 1 1.47 2.30 18.37 34.44 3.30 1.65 rows 3584 3585 3586 3587 3588 3589 ---------------------------------------- 1 1.25 1.27 3.21 6.50 1.14 1.14 Use points between 3585-3588 rows 3584 3585 3586 3587 3588 3589 ---------------------------------------------------------------------------------- 1 9985381376 15615210496 124892807168 234168320000 22466283520 11243105280 rows 3584 3585 3586 3587 3588 3589 ---------------------------------------------------------------------------------- 1 8490705920 8603100160 21807790080 44211630080 7760810496 7754109952 Echo: 124892807168 + 234168320000 = 3.59e11 background = (2)*(6.8e9) = 1.36e10 E/B = 3.59e11/1.36e10 = 26.4 band = 2*0.976 Hz/bin = 1.953 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(1.953 Hz) = 4.10-22 W Prcv = 26.4*(4.10E-22 W) = 1.08E-20 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] OCxsec = (1.08E-20 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035] = 2.98E6 m^2 = 2.98 km^2 That's about 10% higher than the result I get with hop 2 ===== HOP 1 ===== Tsys = 15.2 G^2 = 690.3E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W Divide by 6.8e9: background average is unity. rows 512 513 514 515 516 517 ---------------------------------------- 1 1.28 2.14 12.25 33.69 3.08 1.32 rows 512 513 514 515 516 517 ---------------------------------------- 1 1.08 1.21 3.01 7.16 1.38 0.98 Echo is between 514 and 516 rows 514 515 516 ---------------------------------------------- 1 83303587840 229058674688 20972343296 = 3.33e11 rows 514 515 516 ---------------------------------------------- 1 20497252352 48655515648 9400629248 background = 3(6.8e9) = 2.04e10 E/B = 3.33e11/2.04e10 = 16.34 band = 2.93 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(2.93 Hz) = 6.15e-22 W Prcv = 16.34*(6.15E-22 W) = 1.00E-20 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] OCxsec = (1.00E-20 W)*(64*31)(1.494E10^4)/[425000*690.3E12*0.035*0.035] = 2.76E6 m^2 = 2.76 km^2 Good match. ===== HOP 3 ===== Tsys = 15.2 G^2 = 689.2E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W Notice how the gain varies from hop to hop. It shouldn't. background is at about 6.8e9. Divide by 6.8e9: rows 2561 2562 2563 2564 ---------------------------- 1 2.18 18.29 27.86 2.51 rows 2561 2562 2563 2564 ---------------------------- 1 1.00 3.34 5.22 1.14 Echo is between 2652-2563 rows 2562 2563 -------------------------------- 1 124353404928 189436493824 = 3.138e11 rows 2562 2563 -------------------------------- 1 22712643584 35468017664 background = 2*(6.8e9) = 1.36e10 E/B = 3.14e11/1.36e10 = 23.1 band = 2*(0.978) = 1.953 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(1.953 Hz) = 4.10e-22 W Prcv = 23.1*(4.10E-22 W) = 9.46E-21 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] OCxsec = (9.46E-21 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035] = 2.61E6 m^2 = 2.61 km^2 Summary Hop FFTs OCxsec km^2 --- ---- ----------- 1 146 2.76 2 171 2.72 3 142 2.61 4 168 2.98 These results are consistent with the polynomial reduction but are inconsistent with the regular noise background removal. Greg Black is right. The reason the gains vary from hop to hop is because the gains vary due to the telescope's elevation and pointing. Recall that the hops span 7 runs when the asteroid had a RTT of nearly 100 seconds--so the dish moved appreciably during that interval. However, the gain that appeared in the tags was the *first* one for a given hop. This probably also accounts for minor differences in the cross sections. ======================================================================== 2000 March 6 & 7 ======================================================================== Now that we know the old "regular" cross sections are wrong, go back to the CW data and repeat the reductions using the new rnb software. As a check, do the reductions using the hops too. ---------------------------------------------------------------------------- Check two-hop data as well: there shouldn't be any change but it's worth finding out. The difference between regular background removal and using the raw hops with 2 frequencies is puzzling. ---------------------------------------------------------------------------- I tried Mike Thomas' fix to rnb but it didn't work: the software looked for the other reduction programs in the wrong directory. I sent Mike email and he fixed it. Try it again: /dev1/wart/bin/tkrdfreduc This time the reduction worked. e/m values are MUCH better: Ch2 (SC) are all close to unity (the smallest is about 0.85). Ch1 are better, but there are still some with values as low as about 0.28, although far fewer than with the old version of the software. Interesting... Spectra look pretty good. OC echoes are between 250 and 300 sigma. Each spectrum has about 90 FFTs, so the noise in each should be close to Gaussian. The noise OC noise statistics for spectra 1-6 look fine, but something is wrong with spectrum 7: I get one huge spike with unphysical limits on the horizontal axis. That's odd: the OC spectrum looks OK. OK: there's no problem--I forgot that the noise plotting is zero based, where the other tkpl filters are 1-based. That is, plot noise for spectra 0-6, not 1-7. Duh. Noise for spectrum 7 is rubbish because there IS no spectrum 7. recall that dfreq = 0.98 Hz Summed spectra has raw OC S/N of about 700. The noise histogram is MUCH better, but it's still not perfect: there appears to be an excess of ~4 sigma points. Perhaps that's (sincx/x)^2? The distribution still looks a bit skewed despite having about Note: the summed spectrum has about 630 FFTs, but the tag on the summed file indicates only 89 FFTs. That value wasn't summed. I changed jsnr2 -> 520. Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.new.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-oc 21:37:57 00:00:00 21:39:31 0.0 2.56e-03 2.87e+00 ± 3.7e-03 2.1 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.sum.new.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-sc 21:37:57 00:00:00 21:39:31 0.0 2.78e-03 5.59e-01 ± 3.9e-03 2.0 0.195131 0.196531 0.193731 OCxsec = 2.87 km^2 SCxsec = 0.56 km^2 SC/OC = 0.20 This is comparable to the raw hop and polynomial results: 2.72 km^2. The difference is about 5.5%, which is fine. Note: I did not correct Tsys to the correct values--for now, I'm just comparing results obtained using the different methods of reduction. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repeat the reduction by blocking into a file. ============================================= output file: 99199.4k.file.new.rdf e/m comparable to last time. this time the # ffts is correct: 627. The histogram looks better: there was a slight mismatch with blocking into runs but not with blocking into a file. - - - - - - - - - - - Mike Thomas installed the new version of tkrdfreduc on the Goldstone computers but he's had trouble doing that at Arecibo: he gets bumped off the system as soon as he logs in. I had that problem about a year ago and I had to get Arun to correct it. ==> REPEAT THE REDUCTIONS USING NEW SOFTWARE AND CORRECT TSYS VALUES <== ======================================================================== 2000 April 7, 10, & 11 ======================================================================== We got CW data with 4 hops on the first three days: DOY 199/200, 201, and 202. All the other CW data used two hops. DOY 199/200 =========== I've already done most of the work. Fix the Tsys tags and then repeat the noise background removal and raw hop reductions. Do this to the raw corrected data file and to each of the four hopsum files. For Tsys, use either the value on point just before we started, or use an average of Tsys measured (the values dropped as the elevation increased). Use the summed, raw hops. Average Tsys Ch1 = 15.53 <== Not recorded; used difference on point just before start of 1st run Ch2 = 17.35 I fixed Tsys for each channel in the files: 99199.4k.hop1sum.rdf 99199.4k.hop2sum.rdf 99199.4k.hop3sum.rdf 99199.4k.hop4sum.rdf This won't change the cross sections very much. Here are salient excerpts from the earlier reduction (early March): ===== HOP 1 ===== Tsys Ch1 = 15.5 Ch2 = 17.4 G^2 = 690.3E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W Divide by 6.8e9: background average is unity. rows 512 513 514 515 516 517 ---------------------------------------- 1 1.28 2.14 12.25 33.69 3.08 1.32 rows 512 513 514 515 516 517 ---------------------------------------- 1 1.08 1.21 3.01 7.16 1.38 0.98 Echo is between 514 and 516 rows 514 515 516 ---------------------------------------------- 1 83303587840 229058674688 20972343296 = 3.33e11 rows 514 515 516 ---------------------------------------------- 1 20497252352 48655515648 9400629248 background = 3(6.8e9) = 2.04e10 E/B = 3.33e11/2.04e10 = 16.34 band = 2.93 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.5 K)*(2.93 Hz) = 6.27e-22 W Prcv = 16.34*(6.27E-22 W) = 1.024E-20 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] OCxsec = (1.024E-20 W)*(64*31)(1.494E10^4)/[425000*690.3E12*0.035*0.035] = 2.817E6 m^2 = 2.82 km^2 ===== Hop 2 ===== hop 2 normalized by 6.8e9: rows 1536 1537 1538 1539 1540 1541 1542 ---------------------------------------------- 1 1.32 1.94 8.74 35.67 3.86 1.56 1.16 rows 1536 1537 1538 1539 1540 1541 1542 ---------------------------------------------- 1 1.01 1.17 2.64 7.91 1.60 1.18 1.01 Use points 1538-1540. Unnormalized: rows 1536 1537 1538 1539 1540 1541 1542 ----------------------------------------------------------------------------------------------- 1 8961508352 13209784320 59429937152 242577473536 26246967296 10636954624 7880826880 rows 1536 1537 1538 1539 1540 1541 1542 ----------------------------------------------------------------------------------------------- 1 6839524352 7946156544 17976283136 53762555904 10866804736 7997476352 6854330368 OC Echo points 1538-1540: 59429937152 + 242577473536 + 26246967296 = 3.28e11 background = (3 points)*(6.8e9) = 2.04e10 bandwidth = (3 bins)*(0.97656 Hz/point) = 2.93 Hz E/B = 3.28e11/2.04e10 = 16.08 base = k*Tsys*band = (1.38e-23 W/HzK)*(15.5 K)*(2.93 Hz) = 6.27e-22 W Prcv = 16.08*(6.27E-22 W) = 1.01E-20 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] Tsys = 15.5 G^2 = 689.3E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W OCxsec = (1.01E-21 W)*(64*31)(1.494E10^4)/[425000*689.3E12*0.035*0.035] = 2.78E6 m^2 OR... (2.78E6 m^2)*(1 km/1000 m)^2 = 2.78 km^2 ===== HOP 3 ===== Tsys = 15.5 G^2 = 689.2E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W background is at about 6.8e9. Divide by 6.8e9: rows 2561 2562 2563 2564 ---------------------------- 1 2.18 18.29 27.86 2.51 rows 2561 2562 2563 2564 ---------------------------- 1 1.00 3.34 5.22 1.14 Echo is between 2652-2563 rows 2562 2563 -------------------------------- 1 124353404928 189436493824 = 3.138e11 rows 2562 2563 -------------------------------- 1 22712643584 35468017664 background = 2*(6.8e9) = 1.36e10 E/B = 3.14e11/1.36e10 = 23.1 band = 2*(0.978) = 1.953 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.5 K)*(1.953 Hz) = 4.18e-22 W Prcv = 23.1*(4.18E-22 W) = 9.65E-21 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] OCxsec = (9.65E-21 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035] = 2.66E6 m^2 = 2.66 km^2 ===== HOP 4 ===== Tsys = 15.5 G^2 = 689.2E12 RTT = 99.6 s*(150 m/1E-6 s) = 1.494E10 m Ptx = 425000 W Divide by 6.8E9. Here's the echo: rows 3584 3585 3586 3587 3588 3589 ---------------------------------------- 1 1.47 2.30 18.37 34.44 3.30 1.65 rows 3584 3585 3586 3587 3588 3589 ---------------------------------------- 1 1.25 1.27 3.21 6.50 1.14 1.14 Use points between 3585-3588 rows 3584 3585 3586 3587 3588 3589 ---------------------------------------------------------------------------------- 1 9985381376 15615210496 124892807168 234168320000 22466283520 11243105280 rows 3584 3585 3586 3587 3588 3589 ---------------------------------------------------------------------------------- 1 8490705920 8603100160 21807790080 44211630080 7760810496 7754109952 Echo: 124892807168 + 234168320000 = 3.59e11 background = (2)*(6.8e9) = 1.36e10 E/B = 3.59e11/1.36e10 = 26.4 band = 2*0.976 Hz/bin = 1.953 Hz base = k*Tsys*band = (1.38e-23 W/HzK)*(15.2 K)*(1.953 Hz) = 4.18-22 W Prcv = 26.4*(4.18E-22 W) = 1.10E-20 W OCxsec = Prcv*((4*pi)^3)*(d^4)/[Ptx*(G^2)*(lambda^2)] OCxsec = (1.10E-20 W)*(64*31)(1.494E10^4)/[425000*689.2E12*0.035*0.035] = 3.03E6 m^2 = 3.03 km^2 SUMMARY ======= Hop FFTs OCxsec km^2 SCxsec km^2 --- ---- ----------- ----------- 1 146 2.82 2 171 2.78 3 142 2.66 4 168 3.03 Mean 2.82 This was more effort than it was worth: use noise background removal for the other days. I changed Tsys in the file: 99199.4k.raw.corrected.rdf and then I ran it through the reduction pipeline using the corrected version of rnb. There weren't any obvious reduction problems. e/m for SC was somewhat better than for OC. Might this be related to jsnr1 and 2 being set incorrectly and the stronger OC echoes? ...It's plausible because jsnr2 is within a very strong echo. jsnr1,2 = 511, 514 rows 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 -------------------------------------------------------------------------------------------------------------------- 1 -0.29 3.45 2.11 3.26 2.88 2.40 3.78 9.20 27.32 298.18 692.75 47.81 8.37 5.18 3.15 1.98 rows 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 -------------------------------------------------------------------------------------------------------------------- 1 -1.09 -1.12 1.39 1.53 -1.36 1.40 0.35 3.60 4.23 45.97 130.07 7.50 2.55 1.26 0.21 -0.61 Change jsnr1,2 = 509, 519. Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.file.new.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-oc 21:14:33 00:00:00 21:39:31 0.0 2.62e-03 2.89e+00 ± 3.8e-03 2.1 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.4k.file.new.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 7-sc 21:14:33 00:00:00 21:39:31 0.0 2.93e-03 5.73e-01 ± 4.1e-03 2.0 0.198645 0.200106 0.197186 OCxsec = 2.89 km^2 SCxsec = 0.57 km^2 SC/OC = 0.20+/-0.01 I played around with frequency smoothing to produce the maximum S/N. To my surprise, the optimal value is about dreq = 1.6 Hz. Differences of only 0.1 Hz produce significant differences in the SNR: dfreq OC S/N ----- ------ 1.0 692 1.4 829 1.5 858 1.6 886 1.7 734 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = file 99199B (DOY 200; July 19) ------------------------------ 99199B.nocal.512.corrected.rdf These data have 484 looks. Tsys has already been set but irun hasn't (not that it really matters if I'm going to block into a file anyway). dfreq = 1.95 Hz. We got this file during the same track as file 99199, but in the interim we observed 1999 NW2, we tried to fix a problem with ranging, and we crossed the threshold from DOY 199 -> 200. There are only 3 runs. Use the existing file to get OCxsec and SC/OC and then go back with a 1024-point FFT to get 0.98 Hz resolution to maintain consistency with file 99199. As expected, the bandwidths between the two files on this track are consistent. Tsys values are close enough that I'm not going to change them. rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 -0.16 1.08 0.18 1.16 3.16 15.48 129.78 4.05 2.47 1.47 0.30 64.0 67.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 1.13 0.92 0.77 0.57 0.80 1.90 19.12 -0.07 0.69 -0.22 0.40 64.0 67.0 jsnr1 and 2 should be fine, although it would be better if they were a couple of bins wider. Use the nocal.corrected file to block into a file. reduction seems to have gone smoothly. change jsnr1,2 = 63, 69 dfreq OC SNR ----- ------ 1.95 238 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199B.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-oc 07:06:05 00:00:00 07:14:08 0.0 7.49e-03 2.16e+00 ± 9.0e-03 2.8 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199B.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-sc 07:06:05 00:00:00 07:14:08 0.0 7.89e-03 3.30e-01 ± 9.3e-03 2.7 0.152532 0.156903 0.148166 OCxsec = 2.16 km^2 SC/OC = 0.15+/-0.01 These results differ significantly from what I got with file 99199. Given that JM8 barely rotated during the interim, this clearly justifies our adoption of large uncertainties. The telescope's elevation was much lower (25 deg vs about 52) and the system Temps were almost 4 degrees hotter, an increase of about 22%. The gain was down by about 5.6% too. The peak S/N in the new figure is substantially higher than in the old figure, as it should be (recall the discussion with Greg Black). Do a quick pass with a 1024 point FFT to get 0.98 Hz resolution: reason:/data/ast5/1999JM8/proc/cw < 18 > dofft -d 5.0 -p 162 -f 1024 -i VOLT99199B-8k.1999JM8 -o 99199B.1k.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 1024, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199B-8k.1999JM8 RDFOUT_1=99199B.1k.raw.1_1.rdf RDFOUT_2=99199B.1k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199B.1k.raw.1.rdf -o 99199B.1k.raw.rdf -x PRDX.OUT.s15 -p 162 -d 5.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 242 Total SC spectra: 242 Processing data... reason:/data/ast5/1999JM8/proc/cw < 19 > dfreq = 0.98 Hz. 242 FFTs. leave irun = 1. The OC reduction output looks a bit strange: some of it is out of order. Is there something wrong with the file? I checked the first 4 hops in each channel: they don't look right--the echoes should jump out above the noise but they don't. Very strong chi-sq effects are evident. The reduced spectrum looks OK, though. Signal is present in many of the individual hops but in some the signal is lost in the noise. I don't understand this. I repeated the reduction just in case the output the first time was a fluke, but the output was the same. I haven't seen this before so I'm going to ignore the results from this file. I checked the first 40 OC hops from file 99199 (as above) and found similar spectra, but in general the echoes were easier to see in most hops. Part of the variation at echo-containing frequencies could be self noise, which is at a maximum with only 1 look/spectrum. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 99201 ===== 99201.512.nocal.corrected.rdf 512 FFT => 1.95 Hz/bin. 2 runs, 308 hops. Tsys Ch1 = 15.9 K Ch2 = 16.8 K Those are good values. They were taken from the electronic logfile. irun = 1, which is fine because I'm going to block into a file. Will probably need to adjust jsnr1 and 2. Run through the new version of rnb: I get the same out-of-sequence output with this file that I did before. What's happening is that the blocking report for SC is being output before rnb for OC has finished. Perhaps they're running in parallel? Or is this a bug? Let's check with the old version of rnb... It happens with the old software too. What if we block into runs? Duh...irun = 1 so everything will be blocked into a file anyway. ==> The output came out in the sequence that I've always seen before. Interesting... So, is this significant? Since I didn't adjust irun, the output should be the same for blocking by file and by runs in this case. Let's check. ==> The results seem to be identical as far as I can tell. I checked the echo points, did t87 listings, made plots of both spectra, checked the tags, and noise histograms. Still need to do a t87 listing etc. rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 4.22 0.98 4.08 12.55 98.47 376.17 13.56 5.38 2.63 0.31 0.92 64.0 65.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 1.55 1.07 0.59 2.77 20.79 63.72 2.78 0.09 1.01 0.24 0.18 64.0 65.0 Change jsnr1,2 = 61,69. That includes the impulse response but it's weak enough that it doesn't contribute much. Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-oc 02:31:56 00:00:00 02:36:32 0.0 5.77e-03 2.97e+00 ± 7.6e-03 3.4 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-sc 02:31:56 00:00:00 02:36:32 0.0 6.08e-03 5.66e-01 ± 8.4e-03 3.8 0.190686 0.193568 0.187806 OCxsec = 2.97 km^2 <== Previously I got 1.6 km^2 SCxsec = 0.57 km^2 SC/OC = 0.19+/-0.01 Crank through a quick reduction using a 1k FFT to get 0.98-Hz resolution: ========================================================================= reason:/data/ast5/1999JM8/proc/cw < 13 > dofft -d 5 -p 162 -f 1024 -i VOLT99201.1999JM8 -o 99201.1k.raw.rdf -x PRDX.OUT.s17 contents of ast_spec control file: 1024, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99201.1999JM8 RDFOUT_1=99201.1k.raw.1_1.rdf RDFOUT_2=99201.1k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99201.1k.raw.1.rdf -o 99201.1k.raw.rdf -x PRDX.OUT.s17 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 154 Total SC spectra: 154 Processing data... reason:/data/ast5/1999JM8/proc/cw < 14 > These data sampled slowly enough that this takes only a few seconds. Change Tsys to: Tsys Ch1 = 15.9 K Ch2 = 16.8 K I looked at all the OC hops (1 FFT/hop). Occasionally the echo appears in the correct hop and in the "next" hop in the sequence. That could be skewing some of the noise statistics and may partially account for the difference in e/m values that I see when I'm reducing OC and SC spectra. leave irun = 1 and block into runs (effectively 1 run). Reduction looks good. rows 123 124 125 126 127 128 129 130 131 132 133 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 0.30 2.68 3.04 5.34 23.91 327.66 333.91 25.00 5.07 4.04 1.82 127.0 130.0 rows 123 124 125 126 127 128 129 130 131 132 133 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 -0.43 0.47 3.04 0.61 7.98 56.43 58.35 2.53 1.85 0.20 -0.10 127.0 130.0 change jsnr1,2 = 125,132 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.1k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-oc 02:31:56 00:00:00 02:36:32 0.0 4.08e-03 2.97e+00 ± 6.3e-03 2.4 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99201.1k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/20 1-sc 02:31:56 00:00:00 02:36:32 0.0 4.31e-03 5.64e-01 ± 6.9e-03 2.5 0.190132 0.192495 0.18777 As expected, this didn't make much difference with the cross sections. Now use the finer freq res'n to estimate the peak S/N: dfreq S/N ----- --- 0.98 334 1.5 414 1.6 427 1.7 385 1.95 376 Check the noise statistics: pretty good, although there seems to be an excess of points at about +0.5 sigma when using more than about 20 histogram bins (there are 256 points). If I use fewer points then the histogram is closer to Gaussian but obviously the resolution is worse. Good thing I didn't sample any more slowly than 1 kHz. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = file 99202 ========== I did only 1 cw run on DOY202. In the future, do at least 3 on those days when I decide to do any. 5 would be even better if there's time, just in case some runs are bad and to get better noise statistics. I'm not going to bother looking at the 512 point FFT data. Go right to a 1 k FFT: reason:/data/ast5/1999JM8/proc/cw < 29 > dofft -d 5 -p 163 -f 1024 -i VOLT99202.1999JM8 -o 99202.1k.raw.rdf -x PRDX.OUT.s19 contents of ast_spec control file: 1024, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99202.1999JM8 RDFOUT_1=99202.1k.raw.1_1.rdf RDFOUT_2=99202.1k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99202.1k.raw.1.rdf -o 99202.1k.raw.rdf -x PRDX.OUT.s19 -p 163 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 70 Total SC spectra: 70 Processing data... reason:/data/ast5/1999JM8/proc/cw < 30 > There are 70 hops. Set Tsys as follows: Ch1 = 17.79 K Ch2 = 18.85 K The individual OC hops look OK (I checked all 70). No obvious problems with the reduction. Peak S/N: dfreq S/N ----- --- 0.98 623 1.4 746 1.5 772 1.6 798 1.7 641 ! Rather large change given the modest increase in the filtering... rows 123 124 125 126 127 128 129 130 131 132 133 134 135 136 jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 2.09 1.59 2.53 4.76 4.11 12.07 179.95 623.46 25.12 8.24 3.53 2.06 -0.17 1.30 127.0 130.0 rows 123 124 125 126 127 128 129 130 131 132 133 134 135 136 jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 1.46 -1.22 0.57 -1.77 2.13 1.25 57.72 95.47 5.94 4.02 0.95 2.30 -0.60 -0.50 127.0 130.0 change jsnr1,2 = 125,134 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.1k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-oc 17:41:37 00:00:00 17:42:56 0.0 4.61e-03 3.99e+00 ± 6.1e-03 1.7 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.1k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-sc 17:41:37 00:00:00 17:42:56 0.0 4.89e-03 8.24e-01 ± 7.4e-03 2.2 0.206307 0.208179 0.204436 Wow! OCxsec = 3.99 km^2 SCxsec = 0.82 km^2 SC/OC = 0.21 +/-0.01 This cross section is about 25% larger than what we got on the previous day and it's also the largest of the three days (DOY 199, 201, and 202). This would be worth double checking using raw hops and with coarser frequency resolution. Check the noise statistics... there's a discernible positive skew to the distributions in both the OC and SC histograms. Check the cross sections and ratio using a 512-point FFT: Tsys values are set as follows: Ch1 = 17.8 Ch2 = 19.0 They're close enough to the "real" values that I'm not going to change them. I didn't change any of the tags in file 99202.512.nocal.corrected.rdf The blocking report and rnb output between OC and SC are interleaved again and the usual e/m discrepancy between OC and SC is present, but there are no obvious show stoppers with the reduction. rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 1.64 0.14 6.67 8.83 19.22 307.35 170.45 18.13 5.52 5.74 -0.09 64.0 65.0 rows 60 61 62 63 64 65 66 67 68 69 70 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 2.16 -0.38 -0.01 0.22 3.71 70.91 30.27 4.04 -0.32 0.57 1.69 64.0 65.0 Change jsnr1,2 = 61,70 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-oc 17:41:37 00:00:00 17:42:56 0.0 6.52e-03 3.54e+00 ± 1.0e-02 4.6 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99202.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/21 1-sc 17:41:37 00:00:00 17:42:56 0.0 6.96e-03 7.71e-01 ± 1.0e-02 4.0 0.217995 0.220883 0.21511 OCxsec = 3.54 km^2 SCxsec = 0.77 km^2 SC/OC = 0.22+/-0.01 The ratio is very similar to what I got with a 1k FFT (0.21) but OCxec is 11% smaller. ==> Quote uncertainties of at least 25%. Check the noise statistics: This may not work well because there are only 128 points... actually, it worked better than expected. The noise is closer to Gaussian than it was with only 70 hops, as it should be, but there's still an excess of positive points. Lessons: 1. Use enough FFTs to get good noise statistics 2. Take enough runs to get good noise statistics over a range of desirable frequency resolutions. In this case one or two more runs would have sufficed. However, this was a very short track: The observations span just over 1 hour, so my decision to take only one CW run was justified because we wanted to maximize the number of imaging runs. The main reason I did _any_ cw runs was to verify that we had echoes and to check that the ephemeris was OK. Question: which cross sections should we use? Let's go with the ones obtained using 140 looks (1.95-Hz resolution). To maintain consistency, use the same frequency resolution for all the cross sections and ratios. Fortunately the results were consistent using 0.98 Hz resn and 1.95 Hz resn on DOY 201. I didn't work with 1.95 Hz spectra on DOY 199, though. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Return to 99199: use a 2 k FFT ============================== reason:/data/ast5/1999JM8/proc/cw < 45 > dofft -d 5 -p 162 -f 2048 -i VOLT99199.1999JM8 -o 99199.2k.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 2048, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199.1999JM8 RDFOUT_1=99199.2k.raw.1_1.rdf RDFOUT_2=99199.2k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199.2k.raw.1.rdf -o 99199.2k.raw.rdf -x PRDX.OUT.s15 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 1270 Total SC spectra: 1270 Processing data... reason:/data/ast5/1999JM8/proc/cw < 46 > Adopt the same temperatures that we used with the 4k FFT file: rows tsys ------------ 1 15.5 rows tsys ------------ 1 17.4 There are 1270 looks. Complete the reduction... ...looks OK. Usual e/m discrepancy and the interleaving of the blocking reports and rnb output. There are so many hops that I'm not going to check them all. Let's go straight to the spectrum, set jsnr1 and 2, and get the cross sections. rows 253 254 255 256 257 258 259 260 261 262 263 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 0.96 5.31 3.53 6.09 52.60 713.74 14.33 4.52 2.65 2.41 1.07 256.0 257.0 rows 253 254 255 256 257 258 259 260 261 262 263 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 -0.94 0.87 -0.43 1.62 9.54 124.33 3.44 0.71 -0.52 -1.38 -1.19 256.0 257.0 change jsnr1,2 = 253, 261 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.2k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 1-oc 21:14:33 00:00:00 21:39:31 0.0 3.68e-03 2.96e+00 ± 4.1e-03 2.5 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99199.2k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/18 1-sc 21:14:33 00:00:00 21:39:31 0.0 4.12e-03 5.71e-01 ± 4.6e-03 2.4 0.193051 0.194622 0.191481 OCxsec = 2.96 km^2 (before we got 2.89 km^2) SCxsec = 0.57 km^2 SC/OC = 0.19 (before we got 0.20) ==> Consistent with earlier results. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 99204 ===== We already have a raw file with 1.95 Hz resolution. According to the notebook, Tsys ch 1 = 16.2, ch2 = 16.7 This was another very short track so I did only one CW run. The observations span about 1 hour. Existing Tsys tags use values from zenith, so change them to those above. reduction proceeded normally. only 132 FFTs. RTT was decreasing from day to day. Spectral shape is almost identical but the peak S/N is about 30 sigma higher than it was with the old reduction using the old rnb software. rows 123 124 125 126 127 128 129 130 131 132 133 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 -0.51 1.57 0.40 0.96 2.50 5.55 391.88 27.89 7.20 3.06 0.45 128.0 129.0 rows 123 124 125 126 127 128 129 130 131 132 133 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 2.80 1.01 -0.77 0.29 0.04 1.51 62.82 4.48 1.14 -0.65 0.73 128.0 129.0 change jsnr1,2 = 127, 132 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-oc 00:36:50 00:00:00 00:38:01 0.0 5.16e-03 2.26e+00 ± 5.8e-03 2.4 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-sc 00:36:50 00:00:00 00:38:01 0.0 5.32e-03 3.69e-01 ± 5.9e-03 2.4 0.163147 0.165771 0.160526 OCxsec = 2.26 km^2 SCxsec = 0.37 km^2 SC/OC = 0.16+/-0.01 This result is only about 10% larger than my earlier estimate using the old version of rnb.cc. What I don't understand is why there's any difference. Did Mike Thomas change something else when he installed the fix? What's really interesting is that this represents a 36% decrease relative to the cross section that we got about 31 hours earlier on July 21 (DOY 202). Recall that the echo on DOY 204 was rather limited--perhaps we were seeing an "end-on" phase? Noise statistics are pretty close to Gaussian. Do a quick 0.98-Hz resn red'n to get the optimal frequency smoothing. --------------------------------------------------------------------- reason:/data/ast5/1999JM8/proc/cw < 63 > dofft -d 5 -p 162 -f 1024 -i VOLT99204.1999JM8 -o 99204.1k.raw.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 1024, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99204.1999JM8 RDFOUT_1=99204.1k.raw.1_1.rdf RDFOUT_2=99204.1k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99204.1k.raw.1.rdf -o 99204.1k.raw.rdf -x PRDX.OUT.s21 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 66 Total SC spectra: 66 Processing data... reason:/data/ast5/1999JM8/proc/cw < 64 > It seems that the VME operator set Tsys because the values I corrected before are already tagged on the VOLT data. Change them to: ch1 = 16.22, ch2 = 16.72 There are only 65 looks. Interestingly, the e/m values are the worst that I've seen thus far in all the JM8 cw data that I've reduced in the last couple of days. Coincidence? JM8 was closer on this day than on the others so the echoes were much stronger. There may have been more "bleeding" of hops during each FFT than before... rows 250 251 252 253 254 255 256 257 258 259 260 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 -0.22 1.03 0.68 0.91 4.30 3.64 19.52 439.33 122.57 10.73 3.11 255.0 258.0 rows 250 251 252 253 254 255 256 257 258 259 260 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------- 1 0.39 -0.13 0.29 -0.78 1.76 0.23 2.46 63.18 29.50 1.70 0.71 255.0 258.0 change jsnr1,2 -> 253, 260 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.1k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-oc 00:36:50 00:00:00 00:38:01 0.0 3.65e-03 2.20e+00 ± 4.8e-03 1.7 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99204.1k.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/23 1-sc 00:36:50 00:00:00 00:38:01 0.0 3.76e-03 3.71e-01 ± 5.3e-03 2.0 0.168524 0.170966 0.166083 Despite having only 65 looks, these results are very similar to what I got with twice that number. dfreq OC S/N ----- ------ 0.98 439 1.5 544 1.6 562 1.7 451 <== That huge decrease again... Odd. I plotted the last two spectra to verify that it's real...and it is. Think about this some more and ask Steve. Something wrong with the smoothing software? Or is there something fundamental about smoothing that I don't realize? What's happening is that a little bit of smoothing, say from 1.6 Hz to 1.7 Hz, spreads a lot of the power in the peak Doppler bin (where most of the power is) into the two adjacent bins, so the peak drops significantly. My guess is that if I used a longer FFT to get finer resolution and then filtered the resulting spectrum that I would see a more gradual transition in the peak S/N as I used coarser filters. Interesting...and worth remembering for narrow bandwidth targets. The peak echo S/N per run decreased between July 21 and July 23. Perhaps that's related to the different phase of the target? Or were there undocumented pointing errors, or some other system problem? ======================================================================== 2000 April 12, 13, & 14 ======================================================================== REPEAT THE REDUCTION ABOVE USING A 4 K FFT (0.5 Hz RES'N) TO CHECK THE BANDWIDTH AND PEAK S/N Use the PSD file--it already used a 4 K FFT. There are only 15 FFTs. I'm not adjusting Tsys. A lot of the e/m values are very low: < 0.5. Not so great... There is a very large spike at the extreme negative frequency. Here's the echo: rows 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 ---------------------------------------------------------------------------------------- 1 0.40 15.88 51.88 222.00 195.05 332.34 104.43 140.01 55.10 9.38 7.93 0.54 rows 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 ---------------------------------------------------------------------------------------- 1 1.55 2.66 3.02 32.27 43.86 56.01 25.20 33.87 10.25 0.80 1.81 1.13 dfreq = 0.244 Hz, so the echo is about 2.2 Hz wide. dfreq OC S/N ----- ------ 0.244 332 1 438 1.3 446 1.4 447 <= PEAK Much smaller than the result I obtained yesterday. 1.5 446 1.6 443 1.7 441 2.0 425 These variations in S/N as a function of smoothing are behaving as I expect. On the other hand, if we reduce the VOLT file with a 4k FFT and smooth that, here's what I get: dfreq OC S/N ----- ------ 0.244 334 1 440 1.3 466 1.4 469 <== PEAK 1.5 469 <== 1.6 467 1.7 2.0 447 These results are similar to but as much as about 20 sigma larger than what I got using the PSD file. I don't fully understand what's going on with the 0.98-Hz peak S/N estimates, but what I'm getting with smoothing the 0.244 Hz results seems reasonable since those spectra clearly resolve the echo. ==> Use the 0.244 Hz spectra to estimate the bandwidths and peak S/N. W/o baseline removal the peak is about 476 sigma. - - - - - - - - - - - - - - - - - - - - Another question: why are the cross sections obtained after DOY 202 (when we used two hops) so much smaller than the cross sections obtained using four hops? If the results continue to be small using the revised rnb software, then recompute the cross sections using raw hops. The 0.98 Hz OC S/N is consistent with what I get when I filter the 0.244 Hz spectra to 1 Hz. So I'm at a quandary: which S/N estimates do I adopt? The more conservative approach would be to adopt the results from the smoothed 0.244 Hz spectra. That means I need to go back to the first three days and revise the numbers. For the sake of consistency, reduce the VOLT files and ignore the PSD files. = = = = = = = = = = = = = = = = = = = = = = = = = = = = Reduce VOLT files for DOY 199, 201, and 202 to get 0.244 Hz resolution. Objectives: bandwidths and peak OC S/N estimates. I will not fix jsnr1, jsnr2, tsys etc. on these files since I do not care about the cross sections. ======= DOY 199 ======= We used 4 kHz sampling, so to get 0.244 Hz res'n use a 16 K FFT. With 7 runs, that will take several minutes... reason:/data/ast5/1999JM8/proc/cw < 24 > dofft -d 5 -p 162 -f 16384 -i VOLT99199.1999JM8 -o 99199.16k.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 16384, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199.1999JM8 RDFOUT_1=99199.16k.raw.1_1.rdf RDFOUT_2=99199.16k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199.16k.raw.1.rdf -o 99199.16k.raw.rdf -x PRDX.OUT.s15 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 130 Total SC spectra: 130 Processing data... reason:/data/ast5/1999JM8/proc/cw < 25 > Forge ahead and run this through the rest of the reduction pipeline. Block everything into one file (leave irun = 1). There are 130 looks. dfreq OC S/N ----- ------ 0.244 548 0.5 744 1.0 923 1.1 934 1.2 935 1.3 932 1.4 926 1.5 913 1.6 896 2.0 842 Note: for all the smoothing, I have also been removing baseline with a first order polynomial afterward, which typically reduces the peak S/N by several sigmas. In retrospect, that wasn't necessary--it was more habit than anything else since I always do that when I sum spectra. You can see that the noise level isn't quite kosher by zooming in on the spectra. The noise histograms should reflect this too. Without baseline removal, the peak immediately above is 936 sigma instead of 935. check the bandwidth using dfreq = 0.244 Hz: rows 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 --------------------------------------------------------------------------------------------------------------------------- 1 0.78 2.83 4.56 3.24 7.04 12.31 31.84 321.05 523.55 548.01 413.37 201.92 49.61 11.76 5.90 5.58 1.64 rows 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 --------------------------------------------------------------------------------------------------------------------------- 1 -0.09 0.30 1.57 1.54 2.24 2.02 3.90 47.29 88.92 78.52 71.29 38.92 7.05 1.65 2.17 0.79 1.26 We're picking up some of the echo's impulse response (and some chi-sq effects) so don't use the 2-sigma levels. Adopt contiguous 5-sigma points: that puts the echo between bins 2051 and 2062, 12 bins total, or the COM + 11 bins. (0.244 Hz/bin)*(11 bins) = 2.7 Hz. That's MUCH larger than my earlier estimate of 1.5 Hz. We had a good ephemeris so the echo shouldn't have been drifting in Doppler (recall that the time base was 9 years). How did I get such a small estimate before? I still have the old files in /old_cw_files/ I checked the summed 16 K FFT file and using the 5-sigma level I got a modestly smaller bandwidth, but certainly not 1.5 Hz. (the difference can be attributed to the way that sdev was computed--the SNR was too low with the previous reduction so some of the points near the edges fall below my five-sigma limit). ======= DOY 201 ======= 1 kHz sampling, so use a 4 k FFT. 2 runs. reason:/data/ast5/1999JM8/proc/cw < 34 > dofft -d 5 -p 162 -f 4096 -i VOLT99201.1999JM8 -o 99201.4k.raw.rdf -x PRDX.OUT.s17 contents of ast_spec control file: 4096, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99201.1999JM8 RDFOUT_1=99201.4k.raw.1_1.rdf RDFOUT_2=99201.4k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99201.4k.raw.1.rdf -o 99201.4k.raw.rdf -x PRDX.OUT.s17 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 35 Total SC spectra: 35 Processing data... reason:/data/ast5/1999JM8/proc/cw < 35 > Here's the echo (0.244 Hz res'n): rows 504 505 506 507 508 509 510 511 512 513 514 515 516 517 ------------------------------------------------------------------------------------------------------ 1 1.48 3.57 5.75 40.87 88.19 181.57 253.08 221.25 254.49 191.20 126.01 27.13 6.78 1.89 rows 504 505 506 507 508 509 510 511 512 513 514 515 516 517 ------------------------------------------------------------------------------------------------------ 1 2.93 -0.27 5.27 11.20 30.58 32.38 41.70 36.70 39.54 27.37 21.28 4.79 1.06 0.11 Echo is in bins 506-516. 11 bins total, or 10 bins + com ==> bandwidth = 2.4 Hz. Previously I estimated 2.0 Hz, which is also what I get from the images (such as they are--less than two runs at MUCH weaker S/N than the CW data). dfreq OC S/N ----- ------ 0.244 253 1.0 469 1.2 497 1.4 512 1.5 517 1.6 519 1.7 520 <== 1.8 519 2.0 513 ======= DOY 202 ======= sampling: 1 kHz ==> 4 k FFT reason:/data/ast5/1999JM8/proc/cw < 35 > dofft -d 5 -p 162 -f 4096 -i VOLT99202.1999JM8 -o 99202.4k.raw.rdf -x PRDX.OUT.s19 contents of ast_spec control file: 4096, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99202.1999JM8 RDFOUT_1=99202.4k.raw.1_1.rdf RDFOUT_2=99202.4k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99202.4k.raw.1.rdf -o 99202.4k.raw.rdf -x PRDX.OUT.s19 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 16 Total SC spectra: 16 Processing data... reason:/data/ast5/1999JM8/proc/cw < 36 > Forge ahead with tkrdfreduc... only 16 looks. Lots of chi-sq effects and self noise. The impulse response is really obvious in this spectrum. rows 510 511 512 513 514 515 516 517 518 519 520 521 522 jsnr1 jsnr2 --------------------------------------------------------------------------------------------------------------- 1 4.37 5.27 17.12 80.11 376.13 277.56 270.83 633.58 256.47 41.68 9.47 2.35 1.78 506.0 519.0 rows 510 511 512 513 514 515 516 517 518 519 520 521 522 jsnr1 jsnr2 --------------------------------------------------------------------------------------------------------------- 1 0.20 -0.07 7.70 36.53 46.21 81.17 56.14 54.41 60.34 9.54 0.01 1.03 1.43 506.0 519.0 dfreq S/N ----- ---- 0.244 634 Echo is between bins 511-520, or 9 bins of echo. 9*(0.24414) = 2.2 Hz. Previously I got 1.2 Hz. Yikes! How does 2.2 Hz compare with the bandwidth in the images? The images suggest a bandwidth of about 1.7 Hz. Hmm... 0.5 Hz is a significant difference. Of course, the FFT that I chose is a factor of 2.4 times as coarse as the one we used with the imaging, so that could account for the difference, plus the much greater strength of the cw data. OK, this doesn't take long, so let's check the bandwidth using an 8 k FFT (dfreq = 0.122 Hz). reason:/data/ast5/1999JM8/proc/cw < 43 > dofft -d 5 -p 162 -f 8192 -i VOLT99202.1999JM8 -o 99202.8k.raw.rdf -x PRDX.OUT.s19 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99202.1999JM8 RDFOUT_1=99202.8k.raw.1_1.rdf RDFOUT_2=99202.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 Note: the following IEEE floating-point arithmetic exceptions occurred and were never cleared; see ieee_flags(3M): Inexact; Invalid Operand; Sun's implementation of IEEE arithmetic is discussed in the Numerical Computation Guide. /usr/local/bin/jurg2spec -i 99202.8k.raw.1.rdf -o 99202.8k.raw.rdf -x PRDX.OUT.s19 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 7 Total SC spectra: 7 Processing data... reason:/data/ast5/1999JM8/proc/cw < 44 > Hmm...check the spectrum: rows 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 ----------------------------------------------------------------------------------------------------------------------------------------- 1 1.29 4.68 42.03 46.29 107.43 250.74 144.55 175.66 254.98 383.63 314.80 485.03 182.84 257.69 54.88 13.50 5.61 1.84 0.35 rows 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 ----------------------------------------------------------------------------------------------------------------------------------------- 1 3.15 2.27 12.60 48.70 26.12 30.27 37.28 55.80 53.48 31.65 27.52 57.90 54.50 36.89 23.34 2.13 3.16 0.10 2.32 There aren't any obvious problems. Lots of chi-sq noise, as expected. Again adopt the 5-sigma level as a threshold. There are 15 bins above that level, or 14 + the COM. (14)*(0.122 Hz/bin) = 1.7 Hz. Bingo. That's consistent with the bandwidth in the delay-Doppler images. So the apparent increase in the bandwidth was a function of frequency resolution. So... to get more robust estimates of the bandwidths I need to use 0.122 Hz res'n in order to put more pixels on the target. This could have implications for 1999 GU3. NEED TO USE LONGER FFTs TO GE THE BANDWIDTHS AND OC S/N ESTIMATES. dfreq S/N ----- --- 0.122 485 0.244 574 1.0 814 1.2 831 <== 1.3 831 <== 1.4 826 1.5 820 1.6 811 2.0 768 ================= DOY 201 REVISITED ================= Sampling = 1 kHz ==> Use an 8192-point FFT to get dfreq = 0.122 Hz. There are two runs. reason:/data/ast5/1999JM8/proc/cw < 6 > dofft -d 5 -p 162 -f 8192 -i VOLT99201.1999JM8 -o 99201.8k.raw.rdf -x PRDX.OUT.s17 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99201.1999JM8 RDFOUT_1=99201.8k.raw.1_1.rdf RDFOUT_2=99201.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99201.8k.raw.1.rdf -o 99201.8k.raw.rdf -x PRDX.OUT.s17 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 17 Total SC spectra: 17 Processing data... reason:/data/ast5/1999JM8/proc/cw < 7 > At this res'n there are only 17 looks. Here's the echo: ows 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 ---------------------------------------------------------------------------------------------------------------------------------- 1 3.52 31.25 60.50 69.46 58.57 142.28 128.82 165.31 133.45 174.50 134.45 194.70 147.04 157.94 140.63 104.17 64.64 9.31 rows 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 ---------------------------------------------------------------------------------------------------------------------------------- 1 2.37 4.80 8.68 20.85 29.48 26.28 37.85 17.67 37.71 34.84 21.52 28.46 38.36 21.39 23.29 10.99 6.98 1.95 There are 17 points above the 5-sigma level, so the bandwidth is: 16*(0.122 Hz/bin) = 1.953 Hz = 2.0 Hz. That matches the bandwidth in the delay-Doppler image. dfreq OC S/N ----- ------ 0.122 195 0.244 250 1.0 446 1.5 499 1.6 501 1.7 503 1.8 504 <== 1.9 502 ================= DOY 199 REVISITED ================= Sampling = 4 kHz, so we need a 32 k FFT to get 0.122 Hz resolution. There are seven runs, so this will be slow. The raw file will be quite large. reason:/data/ast5/1999JM8/proc/cw < 13 > dofft -d 5 -p 162 -f 32768 -i VOLT99199.1999JM8 -o 99199.32k.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 32768, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199.1999JM8 RDFOUT_1=99199.32k.raw.1_1.rdf RDFOUT_2=99199.32k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 Note: the following IEEE floating-point arithmetic exceptions occurred and were never cleared; see ieee_flags(3M): Inexact; Invalid Operand; Sun's implementation of IEEE arithmetic is discussed in the Numerical Computation Guide. /usr/local/bin/jurg2spec -i 99199.32k.raw.1.rdf -o 99199.32k.raw.rdf -x PRDX.OUT.s15 -p 162 -d 5 Bus Error reason:/data/ast5/1999JM8/proc/cw < 14 > Great. Now what...? There's still plenty of space on /data/ast5, so that shouldn't be the problem. Maybe it's a RAM problem? OK, use file 99199B: it has only 3 runs with 1 kHz sampling, so we can use an 8 k FFT. First delete all the 32 k FFT files... reason:/data/ast5/1999JM8/proc/cw < 23 > dofft -d 5 -p 162 -f 8192 -i VOLT99199B-8k.1999JM8 -o 99199B.8k.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199B-8k.1999JM8 RDFOUT_1=99199B.8k.raw.1_1.rdf RDFOUT_2=99199B.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199B.8k.raw.1.rdf -o 99199B.8k.raw.rdf -x PRDX.OUT.s15 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 4 Total OC spectra: 26 Total SC spectra: 26 Processing data... reason:/data/ast5/1999JM8/proc/cw < 24 > rows 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 ------------------------------------------------------------------------------------------------------------- 1 2.92 27.37 124.15 95.35 148.20 118.89 123.45 110.43 77.49 98.11 58.22 62.83 31.98 18.32 2.77 rows 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 ------------------------------------------------------------------------------------------------------------- 1 -0.82 1.16 16.40 7.69 19.80 18.11 11.05 19.89 30.78 13.00 16.38 10.46 8.79 0.22 2.13 There are 13 Doppler bins above the 5-sigma level, so the bandwidth is 12(0.122 Hz/bin) = 1.46 Hz. That's only about 1/2 of what I got using coarser res'n spectra from the first file on this date. However, this estimate is the same as the one I have from last fall using the same data. For the S/N estimate, ideally I'd prefer to have it for file 99199, not file 99199B. The S/N per run will be somewhat different because the elevation (and thus Tsys and the gain) were different during acquisition of file 99199B: the elevation was much lower. However, in the interest of not wasting any more time, use the estimate from file 99199 with a 16 k FFT (dfreq = 0.244 Hz). The S/N from that file should be very similar to what I'd get using 99199B and adjusted for the different number of runs. Result: 935 sigma ======= DOY 204 ======= We did one CW run with 1 kHz sampling, so use an 8 k FFT: Note: we used two hops. reason:/data/ast5/1999JM8/proc/cw < 32 > dofft -d 5 -p 162 -f 8192 -i VOLT99204.1999JM8 -o 99204.8k.raw.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99204.1999JM8 RDFOUT_1=99204.8k.raw.1_1.rdf RDFOUT_2=99204.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99204.8k.raw.1.rdf -o 99204.8k.raw.rdf -x PRDX.OUT.s21 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 7 Total SC spectra: 7 Processing data... reason:/data/ast5/1999JM8/proc/cw < 33 > There are only 7 looks at 0.122 Hz resolution. There's a very large spurious spike at the extreme negative edge of the spectrum. It's about 4 times stronger than the echo. Obviously chisq noise is very strong. rows 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 -------------------------------------------------------------------------------------------------------------------- 1 2.98 23.06 68.79 242.72 143.45 236.40 104.19 226.97 149.48 54.86 449.94 109.65 69.58 170.01 6.17 3.94 rows 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 -------------------------------------------------------------------------------------------------------------------- 1 1.06 -0.13 9.07 35.29 23.59 30.63 25.69 44.65 31.50 23.93 8.90 32.11 11.46 12.73 10.81 0.39 Adopt 5-sigma as a threshold. There are 14 Doppler bins, so the echo bandwidth is: 13*(0.122 Hz/bin) = 1.59 Hz. The bandwidth from the delay-Doppler image is 1.5 Hz, so the results are consistent. dfreq OC S/N ----- ------ 0.122 450 1.0 530 1.4 579 1.5 581 <== 1.6 581 <== ======= DOY 205 ======= Sampling = 1 kHz, runs = 2, hops = 2 Go for the bandwidth and S/N first and then for the cross sections & ratio. Use an 8 k FFT. reason:/data/ast5/1999JM8/proc/cw < 39 > dofft -d 5 -p 162 -f 8192 -i VOLT99205.1999JM8 -o 99205.8k.raw.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99205.1999JM8 RDFOUT_1=99205.8k.raw.1_1.rdf RDFOUT_2=99205.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99205.8k.raw.1.rdf -o 99205.8k.raw.rdf -x PRDX.OUT.s21 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 12 Total SC spectra: 12 Processing data... reason:/data/ast5/1999JM8/proc/cw < 40 > There are 12 looks. At the 0.122 Hz res'n the echo strength is about 500 sigma. There is a lot of chi-square noise. There's also another strong spike at about -209 Hz that may be chi-sq noise, but it's very strong: about 80 sigma. Of course, sigmas don't have much meaning with only 12 FFTs... The feature appears to be only 1 bin wide so my guess is that it's just chi-sq noise. I used an 8 k FFT so there should be several rather strong noise spikes. rows 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 -------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 1.76 5.77 15.26 34.10 78.27 104.50 185.33 221.35 498.12 417.50 414.06 383.51 429.98 323.79 240.75 97.00 468.97 53.70 17.60 16.75 8.42 3.56 rows 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 -------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 1.18 0.73 0.52 12.22 35.93 26.86 46.28 60.71 153.71 88.35 69.24 152.06 132.82 35.90 89.27 62.71 1.83 5.95 2.35 -0.76 -1.02 16.11 Adopt 5-sigma as a threshold, even though that could widen the bandwidth due to chi-sq noise. There are 20 bins, so the bandwidth = (19)*(0.122 Hz/bin) = 2.32 Hz I count 22 Doppler bins in the image, so the bandwidth is 22(0.075) = 1.65 Hz. Why such a large difference? Chi-square noise? The image has much less chi-sq noise because we did 49 runs. The bandwidths would be consistent if we ignored the two most negative and three most positive points. Those adjacent points are probably part of the impulse response--there aren't many noise points above 10 sigmas elsewhere in the spectrum. dfreq OC S/N ----- ------ 0.122 498 1.0 1068 1.4 1124 1.5 1125 <== 1.6 1122 2.0 1087 Estimate the cross sections =========================== The raw rdf file with 1.95 Hz res'n already exists: 99205.nocal.corrected.rdf There are 236 looks. Currently Tsys ch1 = 17.1, ch2 = 17.9 Those are valid temps for elevation = 40 deg. The tx/rcv log didn't record temps on this day, but they aren't likely to be very different because the elevation increased by less than 1.5 degrees. ==> Adopt these Tsys values. e/m values in both channels for the first 74 hops are quite low: <= 0.2. ?? Something is wrong with those hops. Randy's notes indicate that we were using new GSSR software that had some problem, so they switched to the old software. Perhaps that's the cause of the bad spectra. ==> Delete them. e/m values still aren't uniformly great but the systematic bad values are gone. There are 162 looks. change jsnr1,2 = 123,135 rows 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 -------------------------------------------------------------------------------------------------- 1 0.77 3.68 2.64 2.48 10.70 18.93700.66109.87 11.88 3.00 2.18 3.10 0.95 123.0 135.0 rows 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 -------------------------------------------------------------------------------------------------- 1 1.34 -1.27 0.03 0.33 0.68 4.67 96.39 18.98 5.20 0.74 0.14 -0.31 -1.18 123.0 135.0 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99205.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 1-oc 16:59:05 00:00:00 17:01:53 0.0 3.27e-03 2.85e+00 ± 4.0e-03 2.9 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99205.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/24 1-sc 16:59:05 00:00:00 17:01:53 0.0 3.42e-03 4.31e-01 ± 4.4e-03 3.2 0.151333 0.152884 0.149783 OCxsec = 2.85 km^2 SCxsec = 0.43 km^2 SC/OC = 0.15 Check the noise statistics: they look fine. ================ DOY 208: July 27 ================ 2 runs, 2 hops, 1 kHz sampling ==> use an 8 k FFT. reason:/data/ast5/1999JM8/proc/cw < 46 > dofft -d 5 -p 162 -f 8192 -i VOLT99208.1999JM8 -o 99208.8k.raw.rdf -x PRDX.OUT.s21 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99208.1999JM8 RDFOUT_1=99208.8k.raw.1_1.rdf RDFOUT_2=99208.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99208.8k.raw.1.rdf -o 99208.8k.raw.rdf -x PRDX.OUT.s21 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 10 Total SC spectra: 10 Processing data... reason:/data/ast5/1999JM8/proc/cw < 47 > We got 9 looks. Expect lots of chi-sq noise again. rows 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 1.5 8.0 51.7 119.1 46.9 78.9 195.1 233.2 107.6 120.5 104.8 98.0 204.9 135.7 210.9 83.6 36.1 157.9 72.6 93.4 48.2 18.5 16.8 0.8 rows 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 3.9 -1.0 6.1 14.2 16.1 21.5 39.0 41.6 24.3 37.1 34.1 46.5 32.2 16.6 18.8 28.6 20.3 13.7 18.1 7.9 4.0 1.4 -0.3 -0.1 The echo is clearly wider than on previous days. If we use 5 sigma as the threshold, then the bandwidth is (21 bins)(0.122 Hz/bin) = 2.56 Hz. How does that compare with the bandwidth from the images? 67-18 = 49 bins, so 48(0.05 Hz/bin) = 2.4 Hz. We did 30 runs with the 1/4 us x 0.05 Hz setup and the echo edges aren't well defined, so these bandwidth differences are not a big deal. dfreq OC S/N ----- ------ 0.122 233 1.0 416 2.0 516 2.2 519 2.3 520 2.4 519 2.6 515 Note that the S/N is down by more than a factor of two relative to the previous day. The delay-doppler image is weak too. Possible reasons are that the pointing was bad, although we don't have any way to check for that a posteriori. The image suggests that we were seeing a pointed end and that there wasn't as much projected area as on the previous day. Estimate the cross sections --------------------------- file = 99208.512.raw.corrrected.rdf There are 216 looks. Tsys ch1 = 18.2 K ch2 = 19.5 K The tx/rcv log indicates that correct values are: ch1 = 18.4 K ch2 = 19.6 K Close enough. The values above were obtained at a slightly different elevation immediately prior to the commencement of the observations. the other tags look fine. Change jsnr1 and 2: rows 122 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 0.21 3.37 2.83 0.33 2.33 6.98 19.08 382.51 131.39 9.09 2.18 2.64 4.46 -0.77 122.0 135.0 rows 122 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 ---------------------------------------------------------------------------------------------------------------------- 1 0.40 1.20 1.16 -0.62 0.01 1.32 4.77 67.72 18.50 2.32 -1.02 -1.56 0.17 -1.25 122.0 135.0 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99208.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-oc 01:31:16 00:00:00 01:34:22 0.0 1.90e-03 1.08e+00 ± 2.7e-03 3.8 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99208.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/27 1-sc 01:31:16 00:00:00 01:34:22 0.0 2.04e-03 1.90e-01 ± 2.7e-03 3.4 0.176074 0.178611 0.173539 OCxsec = 1.08 km^2 SCxsec = 0.19 km^2 SC/OC = 0.18 Wow! The cross section is WAY down relative to those on previous days. That's in keeping with the generally weak image and lower S/N from above. Check the noise statistics: OC histogram looks fine. SC has a slight excess of points near 0 sigma. I used different numbers of histogram bins but that didn't really change much. ================ DOY 209: July 28 ================ Sampling = 1 kHz, hops = 2, runs = 1, osod = 23 => use 8 k FFT reason:/data/ast5/1999JM8/proc/cw < 50 > dofft -d 5 -p 162 -f 8192 -i VOLT99209.1999JM8 -o 99209.8k.raw.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99209.1999JM8 RDFOUT_1=99209.8k.raw.1_1.rdf RDFOUT_2=99209.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99209.8k.raw.1.rdf -o 99209.8k.raw.rdf -x PRDX.OUT.s23 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 4 Total SC spectra: 4 Processing data... reason:/data/ast5/1999JM8/proc/cw < 51 > Only 4 looks! Yikes! The echo strength is WAY up relative to the previous day. Obviously there's considerable self noise at echo-containing frequencies too. These echoes were obtained near the closest approach. There are 25 contiguous bins exceeding 5-sigma, so with that threshold the bandwidth is (24)(0.122) = 2.93 Hz. However, chi-sq noise and the impulse response could easily have broadened the echo, so let's compare it with the delay-Doppler image: 62-7 = 55 bins => (54)*(0.05 Hz/bin) = 2.7 Hz. Note that the images also have finer Doppler resolution than the CW spectra by slightly more than a factor of two. What will happen when we smooth this spectrum? ==> I tried doubling dfreq from 0.122 Hz -> 2.0 Hz and found that the echo smooths into something reasonable when dfreq = 0.5 Hz. Mike Nolan and I briefly discussed this last year during the JM8 experiment when he ran a very long FFT on one of the JM8 cw spectra. The FFT was so long that we had only one look, so the echo was riddled with self noise. Mike claimed you could smooth it and recover a "normal" looking echo and he was right. I hadn't experimented with such extreme FFTs before so I wasn't sure. dfreq OC S/N ----- ------ 0.122 5353 1.0 5340 1.5 5569 2.0 5686 2.1 5705 2.2 5701 2.4 5656 2.5 5607 This is about 10 times stronger than the returns from the previous day. It's hard to believe that there was that much change in the object's orientation combined with an odd shape, so perhas there were pointing problems on July 27. Estimate the cross sections --------------------------- There are only 80 hops: I did only one run. I should have done at least one more to be safe. file: 99209.nocal.512.new.rdf Tsys: ch1 = 15.6, ch2 = 16.7 Those are the values we measured immediately prior to transmitting so they're fine. The actual values for the one run were not recorded: My notes indicate that the one cw run was accidentally truncated. e/m values are highly variable with the usual pattern. The hops are also highly variable but they look OK. change jsnr1,2 = 124, 134 rows 122 123 124 125 126 127 128 129 130 131 132 133 134 135 ------------------------------------------------------------------------------------------------------ 1 2.6 3.1 2.1 4.8 10.9 19.8 134.8 1050.5 204.9 21.3 8.4 5.1 1.8 1.7 rows 122 123 124 125 126 127 128 129 130 131 132 133 134 135 ------------------------------------------------------------------------------------------------------ 1 -0.4 0.5 0.4 2.2 -0.4 3.5 20.8 154.0 42.5 3.3 5.7 0.1 0.1 -0.3 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99209.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-oc 17:14:29 00:00:00 17:15:14 0.0 2.06e-03 3.02e+00 ± 2.8e-03 3.6 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99209.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/28 1-sc 17:14:29 00:00:00 17:15:14 0.0 2.22e-03 5.15e-01 ± 3.2e-03 4.1 0.170468 0.171537 0.169399 OCxsec = 3.02 km^2 SCxsec = 0.52 km^2 SC/OC = 0.17 So what happened on the day before? It's not obvious whether everything was weaker on July 27 because the pointing was bad (which is possible), because of the shape of the object and its shape (perhaps more likely), some other undocumented system problem, or some combination of these factors. We may should get some constraints from the shape modeling. ================ DOY 212: JULY 31 ================ Sampling = 1 kHz, hops = 2, osod = 23, runs = 2. reason:/data/ast5/1999JM8/proc/cw < 54 > dofft -d 5 -p 162 -f 8192 -i VOLT99212.1999JM8 -o 99212.8k.raw.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99212.1999JM8 RDFOUT_1=99212.8k.raw.1_1.rdf RDFOUT_2=99212.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 Note: the following IEEE floating-point arithmetic exceptions occurred and were never cleared; see ieee_flags(3M): Inexact; Invalid Operand; Sun's implementation of IEEE arithmetic is discussed in the Numerical Computation Guide. /usr/local/bin/jurg2spec -i 99212.8k.raw.1.rdf -o 99212.8k.raw.rdf -x PRDX.OUT.s23 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 8 Total SC spectra: 8 Processing data... reason:/data/ast5/1999JM8/proc/cw < 55 > rows 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 2.4 50.2 70.9 164.9 226.5 149.9 242.8 241.0 200.0 99.0 389.8 237.2 585.9 157.4 172.7 427.7 425.1 174.8 240.9 349.9 760.3 377.1 198.6 484.2 124.8 92.7 83.5 131.8 17.2 3.6 rows 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 6.7 15.1 27.6 33.3 80.4 20.0 14.9 183.7 80.9 47.4 18.7 33.6 236.4 32.0 22.8 27.9 51.7 26.5 40.1 25.0 106.3 50.1 48.7 101.3 58.1 34.4 11.3 6.9 6.9 0.3 There are 28 bins, so the bandwidth = (27)(0.122 Hz/bin) = 3.30 Hz Compare that with the image: ~65*(0.05 Hz/bin) = 3.25 Hz. Good agreement. dfreq OC S/N ----- ------ 0.122 760 1.0 1085 1.5 1196 2.0 1321 2.2 1348 2.5 1376 2.8 1396 3.0 1398 <== 3.2 1393 Estimate the cross sections --------------------------- There are 180 looks. The raw file already exists: 99212.nocal.512.rdf Tsys ch1 = 15.3, ch2 = 16.4 Should be: 15.2, 16.2 The difference is less than 2% so leave Tsys values as the are. e/m values are about normal, perhaps a shade closer to unity in some cases. rows 122 123 124 125 126 127 128 129 130 131 132 133 134 135 ------------------------------------------------------------------------------------------------------ 1 0.9 2.8 3.1 4.7 10.8 25.4 375.2 748.7 90.9 15.3 6.8 3.2 2.3 2.0 rows 122 123 124 125 126 127 128 129 130 131 132 133 134 135 ------------------------------------------------------------------------------------------------------ 1 1.7 -0.7 0.8 0.4 3.0 4.9 77.5 151.2 19.6 2.7 0.3 4.0 -0.4 2.0 change jsnr1,2 = 122, 135. Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99212.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/31 1-oc 17:01:12 00:00:00 17:04:03 0.0 1.50e-03 1.94e+00 ± 2.3e-03 4.6 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99212.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/31 1-sc 17:01:12 00:00:00 17:04:03 0.0 1.61e-03 4.29e-01 ± 2.5e-03 4.7 0.220968 0.222285 0.219651 OCxsec = 1.94 km^2 SCxsec = 0.43 km^2 SC/OC = 0.22 Noise statistics look OK, although there's another slight excess of points near zero standard deviations in the SC spectrum. ================= DOY 213: AUGUST 1 ================= Sampling = 1 kHz, hops = 2, runs = 2, osod = 23 reason:/data/ast5/1999JM8/proc/cw < 58 > dofft -d 5 -p 162 -f 8192 -i VOLT99213.1999JM8 -o 99213.8k.raw.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 8192, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99213.1999JM8 RDFOUT_1=99213.8k.raw.1_1.rdf RDFOUT_2=99213.8k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99213.8k.raw.1.rdf -o 99213.8k.raw.rdf -x PRDX.OUT.s23 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 10 Total SC spectra: 10 Processing data... reason:/data/ast5/1999JM8/proc/cw < 59 > There are 10 looks. Here's the OC component of the echo: rows 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 3.2 10.0 68.5 55.3 77.8 69.4 121.8 145.1 33.5 141.1 167.1 149.1 281.7 167.5 110.9 347.6 111.8 228.2 219.1 224.3 170.0 365.2 410.9 85.1 121.5 97.3 211.0 108.7 22.2 8.4 1.9 There are 29 bins exceeding 5 standard deviations. Bandwidth = 28*(0.122 Hz/bin) = 3.42 Hz. Compare with the bandwidth of the echo: 84-22 = 62 bins (61 bins)(0.05 Hz/bin) = 3.05 Hz. That's a pretty big difference, but perhaps it results because the images have more than twice the resolution of the CW spectra. I could go up to a 16 k FFT to check... reason:/data/ast5/1999JM8/proc/cw < 66 > dofft -d 5 -p 162 -f 16384 -i VOLT99213.1999JM8 -o 99213.16k.raw.rdf -x PRDX.OUT.s23 contents of ast_spec control file: 16384, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99213.1999JM8 RDFOUT_1=99213.16k.raw.1_1.rdf RDFOUT_2=99213.16k.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 Note: the following IEEE floating-point arithmetic exceptions occurred and were never cleared; see ieee_flags(3M): Inexact; Invalid Operand; Sun's implementation of IEEE arithmetic is discussed in the Numerical Computation Guide. /usr/local/bin/jurg2spec -i 99213.16k.raw.1.rdf -o 99213.16k.raw.rdf -x PRDX.OUT.s23 -p 162 -d 5 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 4 Total SC spectra: 4 Processing data... reason:/data/ast5/1999JM8/proc/cw < 67 > Only 4 hops! There are several noise spikes exceeding 50 sigmas. 5 sigma is not an appropriate threshold for so few looks. Self noise is also horrible so forget it. The image is more robust since it has almost 100 runs and probably about that number of looks. Return to the 0.122 Hz spectra and get S/N estimates dfreq OC S/N ----- ------ 0.122 411 2.0 849 2.5 877 2.7 880 2.8 881 3.0 880 3.2 3.5 867 Estimate the cross sections =========================== The raw file with 1.95 Hz res'n already exists: 99213.nocal.512.rdf I was not at Goldstone for this track so the electronic log is very sparse. There are 192 FFTs. The tx/rcv log indicates that Tsys should be: ch1 = 16.95, ch2 = 18.0 Check Tsys: ch1 = 15.1, ch2 = 16.1. These temps are about 2 K too high. I changed them to the values above. The other tags look fine. Of course, irun = 1, but I'm grouping into a file so that's fine. run the raw file the rest of the way through /dev1/wart/bin/tkrdfreduc... e/m values aren't so great... with the usual discrepancy between OC and SC. rows 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------------------------------------------ 1 1.56 -0.12 3.45 4.15 5.39 5.61 13.31 27.07 218.73 885.29 125.17 31.11 13.60 6.32 3.58 3.09 122.0 135.0 rows 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 jsnr1 jsnr2 ------------------------------------------------------------------------------------------------------------------------------------ 1 0.68 0.46 -0.75 -0.09 0.85 1.15 4.39 6.99 53.62 190.63 26.24 1.47 1.73 3.63 0.87 3.35 122.0 135.0 jsnr1 and 2 are set generously wide. They include some of the impulse response but it's low enough to be down in the standard errors. Noise histograms look good for both channels. Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99213.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/08/01 1-oc 12:03:22 00:00:00 12:06:16 0.0 1.35e-03 1.81e+00 ± 2.0e-03 4.2 Target unknown from file /data/ast5/1999JM8/proc/cw/new_cw_files/99213.512.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/08/01 1-sc 12:03:22 00:00:00 12:06:16 0.0 1.43e-03 4.20e-01 ± 2.1e-03 4.2 0.23204 0.233227 0.230853 OCxsec = 1.81 km^2 <== Before I got 1.6 km^2 SCxsec = 0.42 km^2 SC/OC = 0.23 Why is the cross section so low? On July 31 the apparent rotation phase is very similar to the one on July 24 when the cross sections and ratio were: OCxsec = 2.85 km^2 SCxsec = 0.43 km^2 SC/OC = 0.15 What's going on? The images on July 24 and August 1 look very similar. The main difference is that there appears to be more echo power from inside the large concavity in the July 24 image. There's also a modest rotation in Doppler between the two images. Is this another example of Goldstone's unreliability? ======================================= Between July 18 and August 1 we got cross sections and ratios on 9 days. The cross sections varied between 1.1 km^2 and 3.5 km^2 and SC/OC varied between 0.15 and 0.23. The means are 2.5 km^2 and 0.19. Some of the variation in the cross sections is probably real: the asteroid has a peculiar shape that was oriented differently from day to day, but the distinct difference in the cross sections on July 24 and 31 makes me suspicious that there are substantial undocumented systematic errors, perhaps in the pointing. ======================================================================== 2001 April 19 & 20 ======================================================================== I have resumed work on JM8. We decided to postpone the shape modeling because Scott's efforts to constrain the spin state weren't converging. He turned everything over to me. So we'll publish a paper describing as much about the object as possible without the shape. - - - - - - - - - - - - - - - - - I have prepared collages of OC, SC, and SC/OC images. The OC and SC collages use the same Doppler and range extents in each frame and I set the number of horizontal pixels so the Doppler axes in the Goldstone and Arecibo images can be directly compared. I also created a 3-panel sequence of the doy 220 (Aug 8) Goldstone images that show very subtle rotation. Steve suggested animating some gifs to show the rotation. The sequence on that day spans more than 7 hours and it clearly shows that the rotation is very slow. It's so slow that sky motion could have contributed significantly to the apparent rotation. - - - - - - - - - - - - - - - - - Spin state ========== Images on July 24 and Aug. 1 show nearly the same part of the asteroid but the bandwidths are distinctly different: on July 24 the bandwidth is about 1.7 Hz but on Aug. 1 it's about 3.0 Hz. Clearly the apparent subradar latitude has moved closer to the apparent equator. The Aug. 8 image is also similar to the other two (but with some rotation). Steve points out that we can use the very similar appearance of the images to test hypotheses about the spin state. We strongly suspect NPA rotation; in the absence of shape modeling results, we're going to search for contradictions to the PA rotation hypothesis. Ideas ----- 1. Assume PA rotation and do a 3-D spin state grid search over lat, long, period. See if there are any viable candidates using the images from Jul 24, Aug 1, and Aug 8. 2. Plot RA and DEC on a globe to psych out the sky motion better. Try to get a transluscent globe that can be split into two hemispheres. 3. Prove that the asteroid is in fact rotating. That's easy: we see it directly in the images, despite the considerable sky motion. Get a cheap globe and put small stickers on it to show the asteroid's positions. 4. Try to visualize JM8's motion across the sky. 5. Create new image collages that interweave the Goldstone and Arecibo images; leave blanks at the locations of dates when we didn't observe. Jul 20 Jul 21 Jul 22 blank Jul 23 Jul 24 Jul 25 blank Jul 26 blank Jul 27 Jul 28 Jul 29 blank Jul 30 blank Jul 31 Aug 1 Aug 2 Aug 3 Aug 4 Aug 5 Aug 6 Aug 7 Aug 8 Aug 9 blank blank blank 21 days total==> make three 8-panel images 6. Use one of the PRDX files to compute the angular rate vs. time. Difference pairs of lines. 7. Use bandwidths and visible range extents to estimate period, check results for consistency. Expect significant differences. 8. Check for rotation during the Arecibo tracks: look at groups of images at the beginning and end of each day. Use the Aug. 5 track: it's the longest (1.37 h) and it appears to be one of the days that showed the most rotation relative to surrounding days. We estimate that we're seeing about 50 deg of rotation between Aug 5 and 6. The sky motion was about 4 deg, so apparent rotation is slightly more than 10x larger than sky motion. If we adopt 50 deg of rotation as our estimate, then JM8 rotated about 2 deg/h if the rotation is constant. Over 1.37 h, we might see 2.7 deg of rotation. That's not much but it's potentially detectable with such fine resolution and high SNR. I grouped the first and last five runs on Aug. 5. There is a modest amount of rotation that appears consistent with 2-3 degrees predicted by the simple calculation above. The SNR is high enough that to check the first and last runs without any summing. ==> The Doppler frequencies of features at the positive and negative edges differ by several bins. The leading edge of the prominent feature at positive freqs changed by about 9 gates or about 135 meters. We also checked by printing reverse grayscale figures, making viewgraphs, and overlaying them. The rotation is evident at the locations mentioned above. One could go even farther by giving the viewgraphs different colors, but that's not necessary. Set up the script next. contradiction between daily apparent rotation on Aug 4-5-6 and the very small rotation seen during 7.5 h on Aug. 8. Pole Search ----------- Still want to test PA rotation using radpole for a suite of rotation periods and pole directions. Search over the whole sky and search a range of rotation periods at small intervales. The bandwidths to test are from Jul 24 and Aug 1 and 8. Use relatively coarse resolution in lat & long--say, no more more than 5 degrees. Start with periods of roughly 5-9 days. This will produce figures suitable for viewing with Spyglass Transform, giving chisq as a function of long and lat. This type of search could be very time-consuming. Even viewing the results will be time consuming. Perhaps write another Perl script to search the output files to locate the minima? That would make a lot more sense than inspecting each figure. View a few figures to get a sense of the chisq structure/number of minima and then automate it. I used Horizons to compute an ephemeris for Goldstone from 1999 July 16-August 12 at hourly intervals. I input bandwidths and error estimates at three epochs corresponding to the midpoints of the Goldstone observations on July 24, Aug. 1, and August. 8. The mean visible range extent of all the images is 3.3 km, but I suspect that the true range extents are somewhat less than twice the visible range extents on at least some of the days, so I adopted Deff = 5 km as an educated guess. Each pole search at 5 deg resolution will take roughly a few minutes. Perhaps we should reduce the resolution to 10 degrees... done. Write a script to scan through a range of rotation periods. reason:/data/ast5/1999JM8/analysis/pole_search < 94 > polesrch jm8.ephem jm8.epochs jm8.search jm8.residuals jm8.chisq The first chisq plot was weird--chisq varied from ~0.1 to about 3.6. ?? Recall Keith's instructions on the internal software pages. ======================================================================== 2001 April 22 & 23 ======================================================================== I found some bugs in Keith's polesrch documentation: It turns out that his polesrch Perl script ignores long = 0 deg if the 0 is placed first in the search file, so place 0 after 355 instead: # 1999JM8.search # # Pole search space for 1999 JM8, diameter = 5000 meters. # # 2001 April 22 # #----------------------------------------------------------------------------------------- # 5-degree all-sky search: betas: 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 betas: -5 -10 -15 -20 -25 -30 -35 -40 -45 -50 -55 -60 -65 -70 -75 -80 -85 -90 lambdas: 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 lambdas: 105 110 115 120 125 130 135 140 145 150 155 160 165 170 175 180 185 190 195 200 lambdas: 205 210 215 220 225 230 235 240 245 250 255 260 265 270 275 280 285 290 295 300 lambdas: 305 310 315 320 325 330 335 340 345 350 355 0 diameters: 5000 Oddly, beta = 0 works fine. This appears to be Perl parsing issue. I could delve into Keith's script but it's probably not worth my time (yet). We should change Keith's online documentation, though. Furthermore, when plotting with Transform don't use linear interpolation to fill the array-- leave the array as it is. However, it's probably necessary to set the dimensions of the array (i.e. the "target matrix") manually because Spyglass' defaults are usually wrong. Otherwise Transform is likely to ignore some of the columns. - - - - - - - - - - - - - - - - - - - - I ran some test cases over the weekend to figure out 1) how to plot with Transform (see above) and 2) how to tackle this problem in general. It's my intent to scan a range of sidereal rotation periods and to search the entire sky at 5 or 10 deg resolution. The question is: how to interpret the results? polesrch outputs 2 text files: one with residuals to each estimate and the other with chisq values. It's possible to get small chisq (< 1.0) if two bandwidth estimates are fit well even if the other is fit only at the 2-3 sigma level, so be careful. My script is going to parse the chisq file to identify the best fits to all three bandwidths and then parse the other file to output the individual residuals. I'll write another script to sweep through a range of rotation periods automatically. Be careful not to fill the partition; the residual files can be large. (~0.5 meg). I also double checked the bandwidth estimates and errors that I have assigned and I modified them slightly. I tightened the errors on doy 220 and I increased the bandwidth estimate on doy 213 by using the Arecibo images to estimate the bandwidth instead of the Goldstone images. That increased the bandwidth by about 0.1 Hz. In the script, after identifying the best candidates, use the estimated errors to compute the magnitude of the residuals in standard deviations for each measurement. To speed things up, adopt a resolution of 10 deg in lambda and beta. Another idea: use radpole/radgeo to predict longitudes at different epochs given bandwidth measurements...but that requires a pole. My thinking is to see if we can assume PA rotation and see the same side of JM8 on July 24, Aug 1, and Aug 8. With only 3 bandwidth measurements, the one-sigma level of statistical significance is rather large (as a percentage over the minimum)... - - - - - - - - - - I wrote a Perl script to run through a range of periods: jm8.polesearch.pl Presently I'm using 10 deg resolution. Each run takes roughly 100 seconds (based on only 2 runs, though). If this is representative, then searching periods between 5.0 - 9.0 days at 0.1 day intervals will take just over 1 hour. To speed things up, run this on rhyme, freeing up reason for other jobs (Steve and I tend to use reason a lot more than rhyme). I wrote another Perl script to parse the residuals and chisq files, identify poles with chisq < some threshold, and output the results to a new file. jm8.pole.pl I set jm8.polesearch.pl running overnight on rhyme using 5 degree resolution and a period increment of 0.05 days (1.2 hours). A significant concern: how reliable is the bandwidth on August 8? The phase is similar to the ones on Jul 24 and Aug 1 but the match isn't as good as the match between the other two days. What's the best way to display the best fits? 1. Tabulate them 2. Plot minimum chisq vs period, similar to the plots Pravec makes for lightcurves. Do this regardless of the pole direction. That is, pick the best fit for any pole direction for each rotation period. Need to write another script to extract that information... or modify jm8.pole.pl to keep track of it. Yes; do the latter. That will be easy. Output the results to a new file. ======================================================================== 2001 April 24 & 25 ======================================================================== I modified jm8.pole.pl to record the minimum chisq for each rotation period and to output the results to a file. Using a period resolution of 0.1 days (2.4 h), there is a broad minimum: Period chisq ------ ----- 5 0.380 5.1 0.343 5.2 0.299 5.3 0.250 5.4 0.211 5.5 0.179 5.6 0.155 5.7 0.137 5.8 0.125 5.9 0.109 6 0.096 6.1 0.076 6.2 0.058 6.3 0.046 6.4 0.039 6.49999999999999 0.033 6.59999999999999 0.020 6.69999999999999 0.009 6.79999999999999 0.003 6.89999999999999 0.001 <== ! 6.99999999999999 0.003 7.09999999999999 0.006 7.19999999999999 0.006 7.29999999999999 0.002 7.39999999999999 0.000 <== ! 7.49999999999999 0.001 <== ! 7.59999999999999 0.004 7.69999999999999 0.006 7.79999999999999 0.006 7.89999999999999 0.006 7.99999999999999 0.007 8.09999999999999 0.011 8.19999999999999 0.018 8.29999999999999 0.025 8.39999999999999 0.032 8.49999999999999 0.036 8.59999999999999 0.042 8.69999999999999 0.050 8.79999999999999 0.060 8.89999999999999 0.071 8.99999999999999 0.079 Perhaps principal axis rotation will work... We could use these periods as seeds and start the shape inversion. Of course, let the rotation period float. Or, the broadness of the minimum (close to one day) might instead be evidence that there's no single rotation period that matches. I made a plot: chi2min.5deg.tpl The visible range extents and the bandwidths suggest a range of upper bounds on the rotation period from about 7 days to about 21 days, assuming that the true range extent is twice the visible range extent. Consequently, run the calculations for a larger range of rotation periods in both directions--say, from about 1 day to about 21 days. The output files are taking up a lot of space, and since /data/ast5/ is almost full, let's move them to /data/ast1/ It turns out that time resolution of 0.05 days was overkill, so I backed off and set it = 0.1 days and set jobs running on rhyme (p = 9.0 - 21.0 days) and reason (1.0 - 5.0 days) using 5 deg resolution. For the global minima it would be helpful to extract the pole coordinates--are they similar for the different periods? I modified jm8.pole.pl to do that. One reasonable interpretation from work thus far is that there are pole directions and periods that fit the data very well for the assumed diameter of 6 km and based on bandwidth measurements from only 3 days. Steve suggested checking the predicted bandwidth predicted from each good candidate pole direction and rotation period against measurements from the other dates. Yikes. Need the pole directions and rotation periods... There will be a range of pole directions for each period (not just the minimum) that works well. This will be a large number of pole direction/rotation period combinations to search... Meanwhile, let the searches running finish, just in case there are other comparably good global minima. Should we search over diameters too? Eek... the parameter space is too large. ideas ----- create a list of measured bandwidths, errors, and epochs (convert to X-band as necessary) Establish a cutoff chisq below which to consider, above which to ignore. Expand the chisq results retained--not just the minima because there will probably be multiple pole directions per period that need to be checked parse exsiting chisq files to create a list of candidate periods, lambdas, and betas. For each spin state, compute bandwidths, residuals, and chisq values following Keith's lead. For now, assume JM8 is spherical with D = 6 km. This is a weak link. Test all this on a small subset of the files--the first two for example--then the 10-deg files, and finally the files with 5 deg resolution. questions --------- 1. write new code to compute bandwidths, residuals, and chisq....or input to polesrch? if input to polesrch, expect chisq to increase substantially due to JM8's shape. Note, however, that JM8 doesn't appear very elongated--that will help make this work. If I simply modify existing code, save the current versions and change the name of the modified software. Running the measurements back through polesrch looks like the best way to go--save time by not duplicating Keith & Scott's code. Use the bandwidth from the first July 18/19 too. The total #of bandwidths is 17. I already have bandwidth estimates; need to estimate uncertainties. More ideas ---------- Steve wants to run the best candidate PA spin states through Scott's shape software to test for contradictions. What he hasn't realized is that it's not just the ratios of the bandwidths at similar phases that matter, but also the size of the object. What I've done so far utilized my best guess for the diameter, namely 6 km. Although JM8 clearly isn't spherical, it's not obviously highly elongated either--for example, the sequence of Arecibo images, obtained when the sky motion was only a few tens of degrees, have a ratio of the maximum to minimum bandwidth of about 1.2. We may need to expand the search to include a range of diameters. So... forge ahead with utilizing the bandwidths from all the days first. See if that will enable us to narrow the space of acceptable PA spin states. Be conservative with that space of possible solutions so we can justify them. Then pick at least one (or many if time permits) to run through Scott's software by fixing the spin state and seeing if we can fit the shape. The quick way to do that would be to use ellipsoids. There are a huge number of points, so it would help to decimate the data by either ignoring the Arecibo images and/or averaging adjacent points (don't toss points as I did with Nyx). Due to the enormous size of the parameter space, drop back to 10 deg resolution in lambda and beta. What's an appropriate threshold for chisg using calculations conducted thus far? Adopt something conservative--say, chisq large enough that the calculated bandwidths are within some small number of standard deviations relative to the stated uncertainties. We could adopt the two-sigma limit...yes, that seems reasonable. I checked the 5-deg res'n chisq minima so far--that type of limit seems to work better than some chisq threshold, where some values might be fine but others could be bad. So I need to change the search strategy of the residuals output files--instead of going for chisq, search for examples within 2 standard deviations. That will be straightforward to implement. Do this for the calculations that are already complete. Expect multiple "good" poles for some rotation periods and (of course) none for others. Doing this for all the bandwidth measurements and for a range of diameters might not produce as many possible spin states as I originally feared. The real question is how meaningful it will be to use the estimated bandwidth errors given that JM8 is not spherical. ======================================================================== 2001 April 26-29 ======================================================================== I got the modified Perl script working. It parses the residuals files to identify cases when all the residuals/errors for a given spin state are less than a specified tolerance, and then the program outputs those results to a file and to the screen. The program is: jm8.pole.new.pl Run this using the 10-deg sky search first (periods = 5 - 9 days), then start new calculations using the viable candidates with all 18 bandwidth measurements. I scanned the 10-deg search and saved all the poles with resid/error <= 2.5 standard deviations. The number is rather modest. file = ../10_deg/minimum.residuals.2.5sig.dat Check the 5-deg search using periods between 6-9 days (other periods clearly fail). ...done. file = ../5_deg/minimum.residuals.2.5sig.dat I also did test runs using all 18 bandwidth measurements. In those cases, I didn't adopt the best matches using only 3 measurements--I simply ran the calculations for all 18. I used D = 6 km and p = 7, 7.5, and 8 days and 10 deg sky resolution. I had to relax the tolerance to about 6 standard deviations to get results that matched, leading me to suspect that there aren't going to be huge numbers of viable pole candidates if I first use the 3 measurements as a "filter." Range of diameters ------------------ 1. Run the three points for a wider range of diameters--a range that clearly encompasses Deff. 2. Then run jm8.pole.new.pl on those output files to identify viable candidates. 3. Run the viable candidates using all 18 bandwidth measurements. Comparison of objects observed at both Arecibo and Goldstone since 1998 demonstrates that visible range extents at Arecibo are often larger than at Goldstone due to the higher SNR. Previously we have often assumed (with justification from the modeling) that the true range extent is about twice the visible range extent. If that's true, then JM8's true range extent is between 6 and 7 km using the Goldstone images and between 8 and 9 km using the Arecibo images. So a safe range of diameters is between 5 - 10 km. Let's adopt a diameter increment of 1.0 km to start; if the results identify a lot of viable poles, then I'll improve the diameter resolution. (Going to higher diameter resolution will raise the issue of the size of the files-- may need to change how they're formatted.) Start with 10-deg searches to keep things tractable. Hey--to speed execution, run jobs on imagine--it has perl and it should be faster than rhyme and reason. It shouldn't have any problems with disk space. imagine would be a good place for backups too... there's 1.12 gig of space. Unfortunately that won't work because Scott's software isn't available on imagine. CALCULATIONS ============ pole res'n parse for d (km) P (d) res'n (d) (deg) status 3 bandwidths ------ ----- --------- ---------- ------ ------------ 5.0 4.0-9.0 0.1 10 done done OK 5.5 4.0-9.0 0.1 10 done done OK 6.0 1.0-5.0 0.1 5 done ignore 6.0 5.0-9.0 0.1 10 done done OK 6.0 5.0-9.0 0.05 5 done ignore 6.0 9.0-21.0 0.1 5 done ignore 6.5 6.0-12.0 0.1 10 done done OK 7.0 6.0-12.0 0.1 10 done done OK 7.5 6.0-18.0 0.1 10 done done OK 8.0 6.0-18.0 0.1 10 done done OK 8.5 6.0-18.0 0.1 10 done done OK 9.0 6.0-18.0 0.1 10 done done OK 9.5 6.0-12.0 0.1 10 done done OK 10.0 6.0-18.0 0.1 10 done done OK Check these for chisqmin as a function of diameter. Then check for residuals below a certain threshold. The d = 7 km and d = 8 km runs show a clear shift toward good fits with longer periods. That is probably a simple consequence of the bandwidth equation since P and D are directly proportional to each other if B is constant. So if we consider the D, P, chisqmin space, the minimum is a trough that's probably linear between D and P. Go for contradictions between radar results and lightcurves: when radar results are done, compare admissible periods from Pravec's lightcurves with radar periods. If they disagree, we have another contradiction. April 29 -------- I modified a Perl script to parse the minimum.residuals.$tol.dat files, extract the rotation periods, lambda, and beta, and then run those spin states through polesrch using all 18 bandwidth measurements. I did that for all of the diameters (5.5 - 10.0 km in 0.5 km increments). Next step: make minor modifications to the script that scans the new files to identify the best fits with normalized residuals less than some value. ======================================================================== 2001 April 30 & May 1 & 2 ======================================================================== check these by rotation period too--how do they compare with Pravec's period? New Perl script: jm8.pole.new2.pl Minimum normalized residuals that matches all 18 bandwidth measurements: diameter resid/error -------- ----------- 5.0 km 6.5 5.5 km 6.5 6.0 km 7.1 6.5 km 6.5 7.0 km 6.4 7.5 km 6.4 8.0 km 6.4 8.5 km 6.5 9.0 km 6.4 9.5 km 6.4 10.0 km 6.3 One of the surprising things about this is that the worst fitting measurement among these best examples is from July 31, when the aspect was similar to the one on Aug. 1. The Aug. 1 normalized residuals are also among the largest, typically about 4.5. Damn! I made a mistake--I used the wrong bandwidth on July 31, so of course it was off. It's presently listed as 1.7 Hz but it should be 3.4 Hz. I double checked ALL the days: the others are fine. Run polesearch.new2.pl again. Fortunately all the software exists; just need to crank through it and move files around. I wrote shell scripts to crank through the "good" cases automatically. This should be done within about 30 minutes. Minimum normalized residuals that matches all 18 bandwidth measurements: diameter resid/error -------- ----------- 5.0 km 2.4 ! Much smaller than before 5.5 km 2.3 6.0 km 2.3 6.5 km 2.4 7.0 km 2.4 7.5 km 2.3 8.0 km 2.3 8.5 km 2.3 9.0 km 2.4 9.5 km 2.4 10.0 km 2.3 This is working better than I expected in the sense that more poles work. Try to constrain the admissible PA period range and pole directions. tabulate them. compatible with Pravec? What about Pravec within a factor of two? Consistent with Scott's preliminary Deff and spin state? Hard to believe that Scott's preliminary results are right because the average Goldstone visible range extents are almost as large (3.3 km) as Scott's Deff (3.4 km); average Arecibo visible range extents are even larger: 4.2 km. Scott stated that the shape and spin state were very preliminary; I worry that we're putting too much stock in them. That preliminary modeling utilized 6 images from July 20-28; among those images, the average visible range extent is 3.1 km, (excluding the distant arc of points visible on July 24 that were confirmed on subsequent dates) yet Scott estimates that the equivalent spherical diameter is 3.4 km. I don't think we should put much stock in Scott's preliminary modeling. What his modeling _does_ strongly suggest is that JM8 isn't a PA rotator given that Scott's attempts to understand the rotation state failed. May still be useful to run calculations (full sky searches at 10 deg res'n and over a range of periods) using just the three measurements for D as small as 3.5 km. lower bound on maximum dimension = 5.3 km (Aug 5) lower bound on minimum dimension = 2.6 km (Jul 23) CHECK SKY POSITIONS: WHAT CAN WE EXCLUDE? Go back to the three measurements. Parse the files and output just the period, lambda, and beta. It's a 4-D space: D, P, lambda, beta. Within each diameter directory, could output files of lambda and beta for each admissible period and then plot them using tkgraph. That will be a lot of plots... Make tables first but with less information than the minimum*.dat files. use jm8.pole.new.pl Steve and I discussed this over lunch. We're close to the point of stopping because it doesn't appear that we're getting much farther. I plotted (lambda, beta) for each diameter that I checked (5.0 - 10.0 km in 0.5 km increments). The admissible solutions vary as a function of rotation period, but by inspection it is clear that there's considerable overlap as the rotation period increases, so I plotted all the pole directions. That meant that many were plotted multiple times. It quickly became obvious that the admissible pole directions occupy the same two regions regardless of D and P, which makes sense. As one would expect, the solutions are separated by about 180 degrees. Both are centered at high ecliptic latitudes of about 60 degrees. A modified version may be worth showing in the paper. Plot on a globe... first need JM8's positions in ecliptic coordinates (instead of RA and DEC). degrees date RA (deg) RA (h) DEC (deg) lambda beta ---- -------- ------ --------- ------ ---- Jul 18/19 186.9 12.46 59.9 149.87 54.85 20 182.5 12.17 61.3 145.53 54.42 21 173.5 11.57 63.5 137.80 53.23 23 163.5 10.90 64.9 130.82 51.52 24 146.1 9.74 65.5 120.93 47.97 27 118.4 7.89 62.0 106.97 40.22 28 101.4 6.76 55.6 97.60 32.45 31 81.7 5.45 38.7 83.33 15.45 Aug 1 78.3 5.22 33.9 80.13 10.85 2 74.8 4.99 28.4 76.65 5.65 3 72.0 4.80 23.2 73.50 0.78 4 69.5 4.63 18.3 70.48 -3.77 5 67.6 4.51 14.1 68.15 -7.67 6 65.9 4.39 10.2 65.77 -11.23 7 64.1 4.27 6.2 63.15 -14.87 8 63.0 4.20 3.5 61.67 -17.33 9 62.1 4.14 1.3 60.28 -19.32 Image sequence contradiction ---------------------------- Arecibo images obtained on Aug. 4-6 show several tens of degrees of rotation between individual days. Using hardcopies of the Aug 5 and 6 images, a ruler, and a protractor, the angle between the flat leading edge on the negative side of the echo rotated about 50 degrees between these two days. The mid-epochs of those days are (UTC hours): Aug 5 (11.97 + 13.33)/2 = 12.65 Aug 6 (12.57 + 13.07)/2 = 12.82 The difference is: (24 + 12.82) - 12.65 = 24.17 hours That implies rotation of about (50 deg/day)*(1 day/24.2 h) = 2.1 deg/h The Aug. 5 observations spanned 1.37 h so we might see (1.37 h)*(2.1 deg/h) = 2.7 deg of rotation. Sky motion between the two days was about 4 degrees so during the Aug 5 track it was only about (4 deg)*(1.37 h)/(24 h) = 0.2 deg, which is about 12 times less than the estimate rotation. I grouped the first and last five runs on Aug. 5. There is a modest amount of rotation that appears consistent with 2-3 degrees predicted by the simple calculation above. I checked the first and last runs on Aug 5 (they're strong enough to look at without summing over multiple runs). The Doppler frequencies of features at the positive and negative edges differ by several bins and the leading edges of the prominent feature at positive freqs changed by about 9 gates (about 135 meters). I also printed reverse grayscale figures, made viewgraphs, and overlaid them. The rotation is clearly evident at the locations mentioned above. To my eye this rotation this rotation is comparable to that evident in Aug. 8 0.25 us images that spanned about 7.5 hours. On Aug 8 the sky motion was only about 3 deg/day. compare rotation in images on Aug.5 w/Aug 8 images shown at the same scale. Another idea: if PA rotation works, we expect that (using only the 3 bandwidths obtained at very similar orientations) on several dates we were close to the equator. Thus, the rotatation from day to day should be regular. That seems to be the case between about July 31-August 6, so perhaps those days are consistent with PA rotation. If that's true, then I'm puzzled about why the July 24 and Aug. 1 images are so similar despite about 50 deg of sky motion between those dates. If those images are so similar, then isn't it reasonable to expect that images on July 23 would closely resemble those obtained on July 31? Well, perhaps not: there was about 12 deg of sky motion between July 23 and 24. Aug 8 images ------------ mid epochs file 3: (11.90 + 14.38)/2 = 13.14 file 7: (17.55 + 19.33)/2 = 18.44 difference 5.30 hours If the rotation seen on Aug 5/6 also applies to Aug. 8, then we expect to see about (2.1 deg/h)*(5.3 h) = 11 deg of rotation. (360 deg)/(50 deg/day) = 7.2 days The Aug. 8 image seems to have a component of rotation about the line of sight; have not noticed such rotation on other days. I colored the echo edges on the view graphs and also a one prominent feature inside the echo on Aug. 8. That facilitates comparing the orientations. The Aug 5 image rotation is (apparently) mostly about the normal to the page; the rotation measured with a protractor is about 3 degrees, in good agreement with the expectation above of 2.7 deg. My best attempt to align the Aug 8 images worked better than I first realized-- I can match the leading edges pretty well but the elliptical feature at positive frequencies doesn't align as well. Using my best match, the angle between the images is about 11-12 degrees, which _is_ consistent with the expectations from Aug 5/6 assuming PA rotation. Perhaps JM8 is a PA rotator after all. Thus, we're left in the situation where we really DON'T have compelling evidence for NPA rotation or even in the situation where we have a strong suggestion of it, unless there's something else that I've missed. Jul 31 and Aug 1 tracks span 2.5 and 3.4 h; they should be long enough to detect rotation. They are the longest Goldstone tracks other than the one on Aug 8. The Jul 24 track is next longest with a duration of 1.95 h, but when I checked that earlier I couldn't convince myself that I could see rotation. I just checked again: no obvious rotation. OK, let's assume PA rotation. Sky motion between Jul 24-Aug 1 was toward smaller RA, that is, toward the west. (I double checked this by looking at the April centerfold sky chart in Sky and Telescope.) Celestial long increases toward the east, but long on the globe I'm using increases the west. We're still left with a potential discrepancy between our rotation period (ignoring sky motion) and Pravec's: he got 5.8 days but we see almost the same phase at an interval of about 8 days. Compute the mid-epochs on Jul 24 and Aug 1 to refine the interval estimate: Jul 24: mid epoch = 19.0146 h doy 205 => 205.7923 Aug 1: mid epoch = 14.1703 h doy 213 (Goldstone) => 213.5904 interval = 7.7981 days I've been playing around with models in my hands, and given that the orientation on the two days was so similar, it looks like the sky motion was approximately parallel to subradar latitude. If so, then there shouldn't be much synodic rotation about the spin axis; instead, the rotation will be about one of the other axes. That means we might see features in on image near the LE or the TE that aren't evident in the other. There seems to be a modest amount of rotation about the line of sight between images on the two days--the Aug 1 image shows more stuff at negative frequencies. The comparison is hampered by the significant differences in resolutions. The leading edges are different: the Aug 1 image has an abrupt change in the LE at neg freqs but the Jul 24 image is more rounded and continuous. There's a modest indentation on the LE close to zero Hz on Aug 1 that isn't evident on Jul 24. Two other images that look very similar are those on Jul 31 and Aug 8. The Jul 31 image more closely resembles the Aug 8 image than does the Aug 1 image. That is also an interval of about 8 days. There is rotation evident between those two days but it's not about an axis perpendicular to the page; rather, it appears to be about an axis oriented parallel to the page extending from the upper left corner to the lower right corner. Sky motion between Jul 31 and Aug 8 was about 35 deg; however, the bandwidths are nearly the same (3.35 Hz vs. 3.38 Hz). If JM8 is a PA rotator, that suggests the subradar latitude was very similar on both dates; perhaps it was on opposite sides of the equator. Sky motion was nearly 7 deg/day on July 31 (near the peak for this object) but only about 3 deg/d on Aug. 8. Sky motion between Jul 31 and Aug 8 was about 35 deg. Following the logic of the last paragraph, we might expect the Aug 1 and Aug 9 images to be very similar. It's possible to match features in both but there has been substantial rotation about an axis roughly parallel to the page and bisecting the echo through the middle of the LE. Can we reconcile our rotation period with Pravec's? Before the radar experiment began Sarounova and Pravec estimated the period was roughly 12-13 days. At that time Pravec stated that a ~7 day period was unlikely. Later, but still before radar observations began, Pravec emailed again that his best estimate for the period was 7.6 +/- 0.2 days. He also stated then that he couldn't rule out twice that period (15.2 days). On the UTC day that radar observations began Pravec revised the estimated period to 14.1+/-0.5 days; in this case, the lightcurve has two peaks. Shortly after the experiment ended Pravec estimated P = 6.76+/-0.2 days on the website. In the winter of 2000 he estimated P = 5.7 days and now he estimates P = 5.8 +/-0.06 days. The data he's using were obtained between 1999 July 3.0-21.9 UTC at high solar phase angles. There is also one night availble from Aug. 16 that Pravec did not include. The P = 5.8 d period has three minima/maxima per period. Based on the appearance of JM8 in the images on July 24, 31, Aug 1, and Aug 8 I don't see how P = 5.8 d or P > 12 d can be correct, but P = 7.6 days seems plausible. Can we reconcile the early images with the images after July 31? Rotation from Jul 23 to 24 seems reasonable but I don't understand July 27-28. One might be able to match features if the apparent rotation was close to 90 degrees, which is larger than rotation evident on other days. How might that come about? Sky motion between the observations on Jul 27 and 28 was about 13 deg despite _daily_ sky motion of only about 6-7 deg. The reason is that the mid epoch of the Jul 27 was at 2.5 h UTC and the mid epoch on Jul 28 was at about 18.25, a difference of about 40 hours or nearly two days. Consequently, if the rotation of about 50 deg seen on other days is correct, then we should have observed about 80 deg of rotation. Sky motion could easily account for the rest. The situation on Jul 20/21 is similar to the situation just described for Jul 27-28 in that the difference between the mid epochs was closer to two days than to one day. Jul 20 mid epoch = 3.67 UT Jul 21 mid epoch = 18.425 UT difference = 38.8 hours. It's tough to tell on those two days--the Jul 20 image is weak and we can't see much other than gross shape attributes. What about the similarity between July 24 and Aug 1? It's puzzling. If JM8 is a PA rotator, that will simplify the shape inversion considerably...and we might be able to do it without much help from Scott. How much did Scott really work on this object? He never really indicated... The initial suspicion of NPA rotation came about 1) because the rotation was slow and 2) there weren't that many images when Scott started and 3) the correspondence among them was difficult to notice. If the rotation period is close to 8 days then the 6 images Scott used in his preliminary shape inversion should have covered most of the object's surface area. If I were going to invert the shape, I'd start with ellipsoids and explore a range of slow rotation periods from somewhat less than Pravec's to Jul 28 (doy 209) data span about 1.5 h--perhaps that's enough to see rotation. - - - - - - - - - - I presented this to Steve. He commented that NPA rotation is difficult to prove but that the evidence for PA rotation looks strong. If JM8 is a PA rotator, and if the Arecibo observations straddle the equator as I think they do, then that means we can do a hull estimation. We did a quick first pass at that by copying the images that were prepared at the same scale, cutting them out, aligning them on top of each other, and taping them down. That gives a first pass pole-on silhouette. The elongation is rather modest, much of the silhouette is rounded, there's a prominent protrusion, and adjacent to the protrusion there's a large planar feature in the silhouette. So it looks like Ellen Howell was on the right track with her first pass at JM8 last fall. I wish we had gone through the exercise in January that we just did because if we had we might have a 3D shape model by now. Publishing this paper strongly suspecting PA rotation but not including the shape model may not go over well--the question may arise why we didn't include the model in the paper. Steve took a first pass at the km/Hz conversion estimated from the silhouette. Need to refine that -- we want better estimates of Deff and P. Hey--use Scott's software radpole/radgeo (whatever the correct name is) to try different periods, predict longitudes, etc. By concentrating on the days when the subradar latitude was apparently close to equatorial it may be possible to narrow the range of admissible sidereal rotation periods. Steve also suggested using an a posteriori ephemeris to locate the ephemeris range and Doppler in each image and see how it evolves from day to day. If the COM rotates then there's a problem. Jon said he would provide one by May 4. ======================================================================== 2001 May 3 & 4 ======================================================================== Scott handed off the JM8 modeling to me in December, 2000. He provided a pgm file that shows images, modeled images, and POS views. The July 24 and August 1 images are so similar that the POS views of the asteroid should also be almost the same, but they aren't. TILT. Scott's modeling had NPA rotation--the spin file clearly shows rotation about all three axes. What was going on? Maybe Scott wasn't paying much attention... - - - - - - - - - - - - - - - Use similar delay-Doppler images on different days to constrain the rotation period ----------------------------------------------------------------------------------- mid epoch mid epoch interval sky motion date doy UTC h UTC days (days) (deg) ---- --- -------- --------- -------- ---------- Jul 24 205 19.0146 205.7923 7.76 ~50 Aug 1 213 13.3718 213.5572 Jul 31 212 18.6713 212.7780 7.77 ~35 Aug 8 220 13.1367 220.5474 The orientations of the images aren't perfect matches on these pairs of days but these results are close enough to suggest strongly that we're in the right ballpark. The true sidereal rotation period could easily be a few tens of a day in either direction. ==> Use Scott's software to refine this estimate. For radar observations spanning significant sky motion, which is the case here, the sidereal rotation period and pole direction are coupled. The question is how... polesrch will take input rotation periods, diameters, pole directions, and bandwidth measurements and compute residuals and chisq. consider rdfphase too--it seems less complicated and it assigns rotation phases to cw rdf files...which we have on July 24, 31, and Aug 1 (but not on Aug 8). One could try to get the rotation phases to match. I'm unaware of other software that outputs rotation phase (longitude). Presumably rdfphase utilizes Scott's software. reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 73 > rdfphase Usage: rdfphase -i infile -o outfile -e ephemeris_file -E epoch -l pole_lon -L pole_lat -b bias -p period -t time_tag [-h] -i infile specifies the name of the input file, a '-' implies the use of stdin -o outfile specifiles the name of the output file a '-' implies the use of stdout -e eph_file Ephemeris File -t time_tag time_tag to use for spectrum times (defaults to rcsta) -b bias Value to add (seconds) to all spectrum times -E epoch Epoch (yyyy/mm/dd/hh:mm:ss) -p period sidereal spin period (hours) -l pole_lon Pole Longitude in ecliptic coordinates -L pole_lat Pole Latitude in ecliptic coordinates -h help radgeo should work too but something is wrong: reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 74 > radgeo usage - radgeo ephemeris_file times_file output_file reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 75 > radgeo jm8.ephem.7.8 jm8.epochs.test results.dat ERROR: time is out of ephemeris time base I don't understand--the ephemeris begins on July 16 and ends on August 12, dates that are well outside the ones in the epochs file. reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 76 > cat jm8.epochs.test 4 {number of lines below} {YY MO DD HH MM SS BB er} 1999 7 24 19 1 0 1.7 0.15 1999 7 31 18 41 0 1.7 0.15 1999 8 1 14 16 0 3.3 0.1 1999 8 8 15 37 0 3.4 0.15 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 77 > cat results.dat JD YY MO DD HH MM SS LAT LON PHASE RATE 11384.292361 1999 7 24 19 1 0 67.50 152.84 207.16 17.22 Here's an excerpt of the ephemeris file: reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 78 > more jm8.ephem.7.8 310 {hudson pole longitude (degrees)} -70 {hudson pole latitude (degrees) } 187.2 {hudson spin period (hours) } 1999 07 18 00 00 00 {reference time YY MO DD HH MM SS min before obs } { ref time is when x axis crosses ecliptic } 649 {number of entries below } {YY MO DD HH RA DEC DIST} 1999 07 16 00 195.52896 56.13293 0.1170670631 1999 07 16 01 195.43463 56.17974 0.1168126500 . . . 1999 08 11 21 59.90391 -4.03706 0.1045380884 1999 08 11 22 59.87274 -4.11641 0.1047871351 1999 08 11 23 59.84291 -4.19541 0.1050354250 1999 08 12 00 59.81424 -4.27411 0.1052824184 Perhaps try different zero-phase epochs? 1999 07 19 00 00 00 ==> same error 1999 07 16 00 00 00 ==> same error 1999 07 20 00 00 00 ==> same error 1999 07 24 00 00 00 ==> same error Perhaps the ephemeris needs even more days on either side of the epochs file? I expanded the dates to July 10 and August 18. When I ran radgeo I got a new error message: reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 106 > radgeo jm8.ephem.test jm8.epochs.test results.dat ERROR: no valid string available OK, that error was caused because I had the wrong number of lines in the ephemeris file header relative to the number that were actually there. When I fixed it I recovered the other error. This isn't working so try using rdfphase instead. I checked a version of the source code in: reason:/dev1/rosema/release/src/rdfprogs/rdfphase.cc Yikes! This is a complicated program but it appears to do everything on its own without invoking Scott's software. rdfphase.cc was written by Keith. reason:/data/ast5/1999JM8/proc/cw/new_cw_files/99205.512.file.rdf reason:/data/ast5/1999JM8/proc/cw/new_cw_files/99213.512.file.rdf This works but it's really slow. Steve and I discussed this over lunch--he suggested using radpole: its output includes the subradar latitudes _and_ longitudes and so is more useful than rdfphase. - - - - - - - - - - - - - - - - - - - - - - - - Try using radpole directly (w/o polesrch). ========================================== reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 157 > radpole radpole.c - version 2.0 May 1, 1998 5/1/98 - rosema - fixed bug where inputs not converted to radians 2/25/98 - rosema - modified (again) to allow input of the pole on the command line, to accept and pass extra data. usage - radpole ephemeris_file epoch_file output_file pole_lon pole_lat Radpole doesn't check to see if the bandwidths work, it simply takes the input information and computes the subradar latitude and longitude and rotation rate. I used poles I found in my search using D = 7.0 km, P = 9.0 days. The pole directions were pretty consistent over all the periods I searched and over all the diameters. I chose this period because it gave the most candidates for this diameter. Here are the poles I checked: lambda beta 100 80 110 80 120 80 130 70 130 80 140 70 140 80 150 40 150 50 <== best candidates 150 60 <== 150 70 160 40 160 50 <- 160 60 <== 160 70 280 -80 290 -80 300 -80 310 -10 310 -20 310 -80 320 -10 320 -20 320 -80 40 70 50 60 50 70 60 60 60 70 70 70 70 80 80 70 80 80 90 70 90 80 Here are the best pole directions by far using P = 7.8 days: reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 256 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 150 50 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 257 > cat results.dat JD YY MO DD HH MM SS LAT LON RATE BW ERR 11384.292361 1999 7 24 19 1 0 -70.82 318.29 19.43 1.70 0.15 11392.094444 1999 8 1 14 16 0 -21.13 331.85 42.40 3.30 0.10 11399.150694 1999 8 8 15 37 0 12.19 10.26 44.43 3.40 0.15 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 258 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 150 60 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 259 > cat results.dat JD YY MO DD HH MM SS LAT LON RATE BW ERR 11384.292361 1999 7 24 19 1 0 -69.27 345.86 19.80 1.70 0.15 11392.094444 1999 8 1 14 16 0 -19.33 335.49 44.21 3.30 0.10 11399.150694 1999 8 8 15 37 0 14.18 7.96 44.58 3.40 0.15 Need to explore more pole directions and periods. Other candidates: reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 279 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 160 50 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 280 > cat results.dat JD YY MO DD HH MM SS LAT LON RATE BW ERR 11384.292361 1999 7 24 19 1 0 -64.46 312.78 24.13 1.70 0.15 11392.094444 1999 8 1 14 16 0 -14.73 324.01 43.89 3.30 0.10 11399.150694 1999 8 8 15 37 0 18.54 2.87 43.02 3.40 0.15 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 281 > radpole jm8.ephem.7.8 jm8.epochs.test results.dat 160 60 reason:/data/ast5/1999JM8/analysis/pole_search/temp2 < 282 > cat results.dat JD YY MO DD HH MM SS LAT LON RATE BW ERR 11384.292361 1999 7 24 19 1 0 -64.48 333.89 23.47 1.70 0.15 11392.094444 1999 8 1 14 16 0 -14.38 326.62 45.26 3.30 0.10 11399.150694 1999 8 8 15 37 0 19.15 359.45 43.41 3.40 0.15 OK, after doing this multiple times it's clear I need to write a script to run through the permutations. Do it in Perl: use different output file names... or take each output file, store it, the period, lambda, and beta, and then output everything at the end into a new file. Since computer time is cheap, do this over the whole sky and over a range of rotation periods. Then scan the results visually for cases that worked. The key thing is to look for longitudes that are very similar on July 24 and Aug 1, a longitude on Aug. 8 that is within a few tens of deg of the other two; very similar subradar latitudes on Aug 1 and 8 (probably on either side of the equator), and a high subradar latitude (either N or S) on July 24. read in an ephem file template and store it in an array loop over rotation periods: use small time resolution; say, 0.5 h loop over latitudes (5 deg res'n) loop over longitudes (5 deg res'n) update the period & output it to a new ephem file--use the same ephem file name to avoid creating tons of new files that take up a lot of space run radpole using the same output name each time read the radpole output file and append it to another file that contains all the outputs: system("cat results.dat >> all_results.dat"); also write the pole direction, lambda, and beta to the big output file. end of loops Perl script: jm8.radpolesearch.pl I set it running on rhyme to scan periods between 5.0 and 9.0 days at 0.1 day intervals and to search the entire sky for each period at 5 deg intervals in lambda and beta. This will may take a few hours. One problem with this approach is that radpole (of course) doesn't output the residuals for the bandwidths computed from each pole direction. So it will be possible to get longitudes and latitudes that fit the expected pattern but the bandwidths may not match. The unknown factor is the diameter. So... we could return to the previous searches using different diameters, periods, and pole directions (using finer resolution for the sky search, diameters, and periods). Or... proceed as we are now, parse the results for admissible spin states, and then run them through polesrch as a function parse the output file for examples when the July 24 and August 1 longitudes are close to each other and when the longitude on August 8 isn't more than a few tens of degrees from either of the other two. The Jul 24 lat should be high and the other two should be close to and straddle the equator, but it may not be necessary to search for that. I'm working in reason:/data/ast5/1999JM8/analysis/pole_search/temp2 Goals: rotation period pole direction km/Hz conversion pole-on silhouette of JM8--not just the hull. Similar to Geographos. ======================================================================== 2001 May 6 & 7 ======================================================================== Parse the output text file -------------------------- There are groups of 5 lines per spin state. open results.dat stick it in an array close the file get the number of lines in the file for($i = 1; $i <= $num; $i=$i+5) # Parse in groups of four lines get the period, lambda, and beta get the lat and long computed for each epoch if the first two longitudes match within about 15 deg, then check the third one. If it's within about 50 deg of the other two, then save it and output the results. Inspect the latitudes to see if they work; if not, increase the sophistication of the parsing. output the spin state, longitudes, and latitudes Of course, there are instances where the longitudes on July 24 and Aug 1 are similar but they cross the 360 deg boundary, so I modified the code to deal with that and to deal with having the third longitude across the boundary. Searching over all the cases that I started on Friday (5 deg spacing, 0.1 day res'n, periods between 5.0 and 9.0 days), there are 8100 matches based solely on the longitudes. To determine which spin states work, we need to compute bandwidths and that requires that we estimate diameters. So... for each spin state, run polesrch through a range of diameters to search for ones that produce acceptable bandwidth residuals. Ugh! Won't this ever end? Note that so far I haven't made use of the subradar latitudes... First, impose latitude restrictions: delta 1 (Jul 24) needs to be >= 60 deg so the bandwidth ratios can equal 0.5. That will exclude many cases and save time. That shrinks the possibilities considerably. Also search over ratios of cos(delta) on Jul 24 and Aug 1 within a specified range. Use raterr to determine the bounds: reason:/data/ast5/1999JM8/analysis/pole_search/temp2/5_deg_search < 560 > /home/ostro/bin/raterr ENTER OUTPUT FORMAT. (E/F) f ENTER: X1,EX1, X2,EX2, CC 1.73, 0.15, 3.27, 0.15, 0.0 0.478 < RATIO < 0.582 RATIO = 0.529 PLUS 0.053 MINUS 0.051 I am not sure I did that correctly--what is CC? Steve's documentation is cryptic. reason:/data/ast5/1999JM8/analysis/pole_search/temp2/5_deg_search < 563 > /home/ostro/bin/raterr ENTER OUTPUT FORMAT. (E/F) f ENTER: X1,EX1, X2,EX2, CC 1.73, 0.15, 3.27, 0.10, 0.0 0.481 < RATIO < 0.578 RATIO = 0.529 PLUS 0.049 MINUS 0.048 ENTER: X1,EX1, X2,EX2, CC 1.73, 0.15, 3.27, 0.10, 1.0 0.498 < RATIO < 0.558 RATIO = 0.529 PLUS 0.029 MINUS 0.031 0.48 <= ratio <= 0.60 looks safe. Implementing this in combination with the other constraints narrowed the acceptable spin states from 8100 to 513. At present I don't deal with the bandwidth ratios between Aug 1 and 8. Their ratio is 3.27/3.38 = 0.97. A difference of more than about 6% would be significant... ENTER OUTPUT FORMAT. (E/F) f ENTER: X1,EX1, X2,EX2, CC 3.27, 0.15, 3.38, 0.15, 0.0 0.908 < RATIO < 1.031 RATIO = 0.967 PLUS 0.064 MINUS 0.060 Let's build this in too... that excludes a lot more cases. Now there are only 241. The periods extend from 6.6 - 7.5 days and 8.1 - 8.5 days. Those periods exclude my estimate by inspection of 7.8 days and Pravec's estimate of 5.8 days from lightcurves. The minimum subradar latitude on July 24 that is admissible is about 56 degrees. The maximum subradar latitude (in absolute value) is about 63 degrees. As expected, the latitudes on Aug 1 and 8 are on opposite sides of the equator. Plot the candidate pole directions. Use grace and read in as block data. reason:/data/ast5/1999JM8/analysis/pole_search/temp2/5_deg_search/jm8.poles.grace The poles are very similar to the ones I identified earlier but their distribution is somewhat smaller. Next step: run polesrch for each spin state over a range of diameters. Our constraints on the diameter and bandwidths should be sufficient to rule out some of the spin states. Thus far I am not using bandwidths on any of the other days. The results to date indicate that the subradar latitude was close to the equator during the Arecibo observations, so we could use the bandwidths directly... they vary from 3.1 to 3.6, implying a pole-on elongation of about 1.2. Save this idea for later. Here are the admissible spin states: From left to right, the values tabulated are: subradar subradar lambda <--latitude-----> <--longitude----> P (d) beta 7/24 8/1 8/8 7/24 8/1 8/8 ----- ---- ---- --- --- ---- --- --- 6.60 150 25 -57.5 -22.6 5.8 264.3 249.5 242.8 6.60 260 -75 58.0 25.8 -3.1 351.1 341.1 333.9 6.60 265 -75 59.1 25.8 -3.5 357.2 346.6 338.6 6.60 270 -75 60.0 25.6 -4.1 3.5 352.0 343.4 6.60 275 -75 60.9 25.3 -4.7 10.1 357.5 348.1 6.70 150 25 -57.5 -22.6 5.8 265.0 256.5 255.6 6.70 150 30 -61.3 -22.7 7.2 270.5 258.6 255.0 6.70 260 -75 58.0 25.8 -3.1 351.7 348.1 346.6 6.70 265 -75 59.1 25.8 -3.5 357.8 353.6 351.4 6.70 270 -80 56.2 20.6 -8.5 9.4 358.6 356.4 6.70 270 -75 60.0 25.6 -4.1 4.2 359.0 356.1 6.70 275 -80 56.7 20.5 -9.0 15.4 3.9 1.2 6.70 275 -75 60.9 25.3 -4.7 10.7 4.5 0.9 6.70 280 -80 57.1 20.2 -9.4 21.5 9.1 6.0 6.70 280 -75 61.6 24.8 -5.4 17.5 9.9 5.6 6.70 285 -80 57.5 19.8 -10.0 27.7 14.3 10.8 6.70 285 -75 62.1 24.3 -6.2 24.5 15.2 10.3 6.70 290 -80 57.7 19.4 -10.6 33.9 19.5 15.6 6.70 290 -75 62.6 23.7 -7.1 31.7 20.6 15.1 6.70 295 -75 62.8 22.9 -8.1 39.0 25.9 19.8 6.80 150 25 -57.5 -22.6 5.8 265.6 263.3 267.9 6.80 150 30 -61.3 -22.7 7.2 271.1 265.4 267.4 6.80 155 30 -58.3 -18.4 11.4 273.9 262.9 265.1 6.80 260 -75 58.0 25.8 -3.1 352.3 354.9 359.0 6.80 265 -75 59.1 25.8 -3.5 358.4 0.4 3.7 6.80 270 -80 56.2 20.6 -8.5 10.0 5.4 8.7 6.80 270 -75 60.0 25.6 -4.1 4.8 5.8 8.5 6.80 275 -80 56.7 20.5 -9.0 16.0 10.7 13.6 6.80 275 -75 60.9 25.3 -4.7 11.4 11.2 13.2 6.80 280 -80 57.1 20.2 -9.4 22.1 15.9 18.4 6.80 280 -75 61.6 24.8 -5.4 18.2 16.6 18.0 6.80 285 -80 57.5 19.8 -10.0 28.3 21.1 23.2 6.80 285 -75 62.1 24.3 -6.2 25.2 22.0 22.7 6.80 290 -80 57.7 19.4 -10.6 34.5 26.3 28.0 6.80 290 -75 62.6 23.7 -7.1 32.3 27.4 27.4 6.80 295 -80 57.9 18.9 -11.3 40.8 31.5 32.8 6.80 295 -75 62.8 22.9 -8.1 39.6 32.6 32.1 6.80 300 -80 57.9 18.4 -12.0 47.1 36.6 37.6 6.80 300 -75 62.9 22.1 -9.1 47.0 37.9 36.8 6.80 305 -80 57.9 17.8 -12.7 53.4 41.8 42.4 6.80 305 -75 62.9 21.2 -10.2 54.3 43.1 41.5 6.80 310 -80 57.8 17.1 -13.5 59.7 46.9 47.3 6.80 310 -75 62.7 20.2 -11.4 61.6 48.2 46.3 6.80 315 -80 57.6 16.4 -14.3 66.0 51.9 52.1 6.90 150 25 -57.5 -22.6 5.8 266.2 269.9 279.9 6.90 150 30 -61.3 -22.7 7.2 271.7 272.0 279.4 6.90 155 30 -58.3 -18.4 11.4 274.5 269.5 277.1 6.90 155 35 -61.6 -18.5 12.5 281.1 271.2 276.1 6.90 160 30 -55.1 -14.1 15.6 276.5 267.1 274.8 6.90 160 35 -58.3 -14.4 16.6 282.4 268.4 273.4 6.90 260 -75 58.0 25.8 -3.1 352.9 1.5 11.0 6.90 265 -75 59.1 25.8 -3.5 359.1 7.0 15.8 6.90 270 -80 56.2 20.6 -8.5 10.6 12.0 20.8 6.90 270 -75 60.0 25.6 -4.1 5.4 12.4 20.5 6.90 275 -80 56.7 20.5 -9.0 16.6 17.3 25.6 6.90 275 -75 60.9 25.3 -4.7 12.0 17.9 25.2 6.90 280 -80 57.1 20.2 -9.4 22.7 22.5 30.4 6.90 280 -75 61.6 24.8 -5.4 18.8 23.2 30.0 6.90 285 -80 57.5 19.8 -10.0 28.9 27.7 35.2 6.90 285 -75 62.1 24.3 -6.2 25.8 28.6 34.7 6.90 290 -80 57.7 19.4 -10.6 35.1 32.9 40.0 6.90 290 -75 62.6 23.7 -7.1 32.9 34.0 39.4 6.90 295 -80 57.9 18.9 -11.3 41.4 38.1 44.8 6.90 295 -75 62.8 22.9 -8.1 40.2 39.2 44.1 6.90 300 -80 57.9 18.4 -12.0 47.7 43.2 49.6 6.90 300 -75 62.9 22.1 -9.1 47.6 44.5 48.9 6.90 305 -80 57.9 17.8 -12.7 54.0 48.4 54.5 6.90 305 -75 62.9 21.2 -10.2 54.9 49.7 53.6 6.90 310 -80 57.8 17.1 -13.5 60.3 53.5 59.3 6.90 310 -75 62.7 20.2 -11.4 62.2 54.8 58.3 6.90 315 -80 57.6 16.4 -14.3 66.6 58.5 64.1 6.90 315 -75 62.3 19.1 -12.6 69.4 59.9 63.0 6.90 320 -80 57.2 15.7 -15.1 72.8 63.6 69.0 6.90 320 -75 61.8 18.0 -13.8 76.5 64.9 67.7 6.90 325 -80 56.9 14.9 -16.0 78.9 68.6 73.9 6.90 325 -75 61.1 16.8 -15.1 83.3 69.9 72.5 6.90 330 -80 56.4 14.1 -16.8 84.9 73.6 78.8 6.90 335 -80 55.8 13.2 -17.7 90.8 78.6 83.7 6.90 340 -80 55.2 12.4 -18.6 96.6 83.6 88.6 6.90 345 -80 54.5 11.5 -19.4 102.3 88.5 93.6 7.00 150 25 -57.5 -22.6 5.8 266.8 276.3 291.6 7.00 150 30 -61.3 -22.7 7.2 272.3 278.4 291.1 7.00 155 30 -58.3 -18.4 11.4 275.1 275.9 288.7 7.00 155 35 -61.6 -18.5 12.5 281.6 277.6 287.7 7.00 160 30 -55.1 -14.1 15.6 277.1 273.5 286.5 7.00 160 35 -58.3 -14.4 16.6 283.0 274.8 285.1 7.00 160 40 -61.0 -14.6 17.4 290.2 276.1 283.5 7.00 260 -75 58.0 25.8 -3.1 353.5 7.9 22.6 7.00 265 -75 59.1 25.8 -3.5 359.6 13.4 27.4 7.00 270 -80 56.2 20.6 -8.5 11.2 18.4 32.4 7.00 270 -75 60.0 25.6 -4.1 6.0 18.8 32.2 7.00 275 -80 56.7 20.5 -9.0 17.2 23.7 37.2 7.00 275 -75 60.9 25.3 -4.7 12.6 24.2 36.9 7.00 280 -80 57.1 20.2 -9.4 23.3 28.9 42.0 7.00 280 -75 61.6 24.8 -5.4 19.4 29.6 41.6 7.00 285 -80 57.5 19.8 -10.0 29.5 34.1 46.8 7.00 285 -75 62.1 24.3 -6.2 26.4 35.0 46.4 7.00 290 -80 57.7 19.4 -10.6 35.7 39.3 51.6 7.00 290 -75 62.6 23.7 -7.1 33.5 40.4 51.1 7.00 295 -80 57.9 18.9 -11.3 42.0 44.5 56.5 7.00 295 -75 62.8 22.9 -8.1 40.8 45.6 55.8 7.00 300 -80 57.9 18.4 -12.0 48.3 49.6 61.3 7.00 300 -75 62.9 22.1 -9.1 48.1 50.9 60.5 7.00 305 -80 57.9 17.8 -12.7 54.6 54.8 66.1 7.00 305 -75 62.9 21.2 -10.2 55.5 56.1 65.2 7.00 310 -80 57.8 17.1 -13.5 60.9 59.9 70.9 7.00 310 -75 62.7 20.2 -11.4 62.8 61.2 69.9 7.00 315 -80 57.6 16.4 -14.3 67.2 64.9 75.8 7.00 315 -75 62.3 19.1 -12.6 70.0 66.3 74.7 7.00 320 -80 57.2 15.7 -15.1 73.3 70.0 80.7 7.00 320 -75 61.8 18.0 -13.8 77.1 71.3 79.4 7.00 325 -80 56.9 14.9 -16.0 79.5 75.0 85.5 7.00 325 -75 61.1 16.8 -15.1 83.9 76.3 84.2 7.00 330 -80 56.4 14.1 -16.8 85.5 80.0 90.4 7.00 330 -75 60.3 15.6 -16.3 90.6 81.3 88.9 7.00 335 -80 55.8 13.2 -17.7 91.4 85.0 95.3 7.00 335 -75 59.4 14.3 -17.6 97.0 86.2 93.7 7.00 340 -80 55.2 12.4 -18.6 97.2 90.0 100.3 7.00 340 -75 58.4 13.0 -18.9 103.2 91.1 98.6 7.00 345 -80 54.5 11.5 -19.4 102.9 94.9 105.2 7.10 150 30 -61.3 -22.7 7.2 272.9 284.6 302.4 7.10 155 30 -58.3 -18.4 11.4 275.7 282.1 300.1 7.10 155 35 -61.6 -18.5 12.5 282.2 283.8 299.1 7.10 160 30 -55.1 -14.1 15.6 277.7 279.7 297.8 7.10 160 35 -58.3 -14.4 16.6 283.6 281.0 296.4 7.10 160 40 -61.0 -14.6 17.4 290.8 282.3 294.9 7.10 270 -80 56.2 20.6 -8.5 11.8 24.7 43.8 7.10 275 -80 56.7 20.5 -9.0 17.8 29.9 48.6 7.10 280 -80 57.1 20.2 -9.4 23.9 35.1 53.4 7.10 285 -80 57.5 19.8 -10.0 30.1 40.3 58.2 7.10 285 -75 62.1 24.3 -6.2 26.9 41.2 57.7 7.10 290 -80 57.7 19.4 -10.6 36.3 45.5 63.0 7.10 290 -75 62.6 23.7 -7.1 34.1 46.6 62.4 7.10 295 -80 57.9 18.9 -11.3 42.6 50.7 67.8 7.10 295 -75 62.8 22.9 -8.1 41.4 51.9 67.1 7.10 300 -80 57.9 18.4 -12.0 48.9 55.9 72.6 7.10 300 -75 62.9 22.1 -9.1 48.7 57.1 71.8 7.10 305 -80 57.9 17.8 -12.7 55.2 61.0 77.5 7.10 305 -75 62.9 21.2 -10.2 56.1 62.3 76.6 7.10 310 -80 57.8 17.1 -13.5 61.5 66.1 82.3 7.10 310 -75 62.7 20.2 -11.4 63.4 67.4 81.3 7.10 315 -80 57.6 16.4 -14.3 67.7 71.2 87.1 7.10 315 -75 62.3 19.1 -12.6 70.6 72.5 86.0 7.10 320 -80 57.2 15.7 -15.1 73.9 76.2 92.0 7.10 320 -75 61.8 18.0 -13.8 77.6 77.6 90.7 7.10 325 -80 56.9 14.9 -16.0 80.0 81.2 96.9 7.10 325 -75 61.1 16.8 -15.1 84.5 82.6 95.5 7.10 330 -80 56.4 14.1 -16.8 86.1 86.2 101.8 7.10 330 -75 60.3 15.6 -16.3 91.2 87.5 100.3 7.10 335 -80 55.8 13.2 -17.7 92.0 91.2 106.7 7.10 335 -75 59.4 14.3 -17.6 97.6 92.4 105.1 7.10 340 -80 55.2 12.4 -18.6 97.8 96.2 111.6 7.10 340 -75 58.4 13.0 -18.9 103.8 97.3 109.9 7.10 340 -70 61.1 13.6 -19.1 111.0 98.5 108.2 7.10 345 -80 54.5 11.5 -19.4 103.5 101.1 116.6 7.20 155 30 -58.3 -18.4 11.4 276.2 288.2 311.1 7.20 155 35 -61.6 -18.5 12.5 282.8 289.9 310.1 7.20 160 30 -55.1 -14.1 15.6 278.2 285.8 308.8 7.20 160 35 -58.3 -14.4 16.6 284.2 287.0 307.4 7.20 160 40 -61.0 -14.6 17.4 291.4 288.3 305.9 7.20 290 -80 57.7 19.4 -10.6 36.9 51.6 74.0 7.20 295 -80 57.9 18.9 -11.3 43.1 56.8 78.8 7.20 300 -80 57.9 18.4 -12.0 49.4 61.9 83.6 7.20 300 -75 62.9 22.1 -9.1 49.3 63.1 82.9 7.20 305 -80 57.9 17.8 -12.7 55.8 67.0 88.5 7.20 305 -75 62.9 21.2 -10.2 56.6 68.3 87.6 7.20 310 -80 57.8 17.1 -13.5 62.0 72.1 93.3 7.20 310 -75 62.7 20.2 -11.4 64.0 73.5 92.3 7.20 315 -80 57.6 16.4 -14.3 68.3 77.2 98.2 7.20 315 -75 62.3 19.1 -12.6 71.2 78.6 97.0 7.20 320 -80 57.2 15.7 -15.1 74.5 82.3 103.0 7.20 320 -75 61.8 18.0 -13.8 78.2 83.6 101.8 7.20 325 -80 56.9 14.9 -16.0 80.6 87.3 107.9 7.20 325 -75 61.1 16.8 -15.1 85.1 88.6 106.5 7.20 330 -80 56.4 14.1 -16.8 86.6 92.3 112.8 7.20 330 -75 60.3 15.6 -16.3 91.7 93.6 111.3 7.20 335 -80 55.8 13.2 -17.7 92.5 97.3 117.7 7.20 335 -75 59.4 14.3 -17.6 98.1 98.5 116.1 7.20 340 -80 55.2 12.4 -18.6 98.4 102.2 122.6 7.20 340 -75 58.4 13.0 -18.9 104.3 103.4 120.9 7.20 340 -70 61.1 13.6 -19.1 111.5 104.5 119.2 7.20 345 -80 54.5 11.5 -19.4 104.1 107.2 127.6 7.30 155 35 -61.6 -18.5 12.5 283.3 295.8 320.8 7.30 160 30 -55.1 -14.1 15.6 278.8 291.7 319.5 7.30 160 35 -58.3 -14.4 16.6 284.7 292.9 318.1 7.30 160 40 -61.0 -14.6 17.4 291.9 294.2 316.6 7.30 310 -75 62.7 20.2 -11.4 64.5 79.4 103.0 7.30 315 -80 57.6 16.4 -14.3 68.8 83.1 108.9 7.30 315 -75 62.3 19.1 -12.6 71.7 84.5 107.7 7.30 320 -80 57.2 15.7 -15.1 75.0 88.2 113.7 7.30 320 -75 61.8 18.0 -13.8 78.7 89.5 112.5 7.30 325 -80 56.9 14.9 -16.0 81.1 93.2 118.6 7.30 325 -75 61.1 16.8 -15.1 85.6 94.5 117.2 7.30 330 -80 56.4 14.1 -16.8 87.2 98.2 123.5 7.30 330 -75 60.3 15.6 -16.3 92.2 99.5 122.0 7.30 335 -80 55.8 13.2 -17.7 93.1 103.2 128.4 7.30 335 -75 59.4 14.3 -17.6 98.7 104.4 126.8 7.30 340 -80 55.2 12.4 -18.6 98.9 108.1 133.3 7.30 340 -75 58.4 13.0 -18.9 104.8 109.2 131.7 7.30 340 -70 61.1 13.6 -19.1 112.1 110.4 129.9 7.30 345 -80 54.5 11.5 -19.4 104.6 113.1 138.3 7.40 160 35 -58.3 -14.4 16.6 285.2 298.7 328.6 7.40 160 40 -61.0 -14.6 17.4 292.4 299.9 327.1 7.40 325 -75 61.1 16.8 -15.1 86.1 100.2 127.7 7.40 330 -75 60.3 15.6 -16.3 92.8 105.2 132.4 7.40 335 -75 59.4 14.3 -17.6 99.2 110.1 137.2 7.40 340 -80 55.2 12.4 -18.6 99.4 113.8 143.8 7.40 340 -75 58.4 13.0 -18.9 105.4 115.0 142.1 7.40 340 -70 61.1 13.6 -19.1 112.6 116.2 140.3 7.40 345 -80 54.5 11.5 -19.4 105.1 118.8 148.7 7.50 160 40 -61.0 -14.6 17.4 292.9 305.5 337.2 7.50 340 -75 58.4 13.0 -18.9 105.9 120.5 152.2 7.50 340 -70 61.1 13.6 -19.1 113.1 121.7 150.5 8.10 160 70 -61.1 -13.6 19.1 353.7 343.8 22.7 8.10 340 -40 61.0 14.6 -17.4 173.8 160.0 196.0 8.20 150 75 -60.3 -15.6 16.3 13.9 359.4 39.1 8.20 155 75 -59.4 -14.3 17.6 7.5 354.5 34.3 8.20 160 70 -61.1 -13.6 19.1 354.1 348.5 31.2 8.20 160 75 -58.4 -13.0 18.9 1.3 349.6 29.5 8.20 340 -40 61.0 14.6 -17.4 174.3 164.7 204.5 8.30 140 75 -61.8 -18.0 13.8 27.9 13.9 56.9 8.30 145 75 -61.1 -16.8 15.1 21.0 8.9 52.2 8.30 150 75 -60.3 -15.6 16.3 14.3 4.0 47.4 8.30 150 80 -56.4 -14.1 16.8 19.4 5.2 45.9 8.30 155 75 -59.4 -14.3 17.6 7.9 359.1 42.6 8.30 155 80 -55.8 -13.2 17.7 13.5 0.3 41.0 8.30 160 75 -58.4 -13.0 18.9 1.8 354.2 37.8 8.30 160 80 -55.2 -12.4 18.6 7.7 355.3 36.1 8.30 165 80 -54.5 -11.5 19.4 2.0 350.4 31.1 8.30 340 -35 58.3 14.4 -16.6 181.9 170.5 211.3 8.40 130 75 -62.7 -20.2 11.4 42.5 28.5 74.5 8.40 130 80 -57.8 -17.1 13.5 44.4 29.8 73.5 8.40 135 80 -57.6 -16.4 14.3 38.2 24.8 68.6 8.40 140 80 -57.2 -15.7 15.1 32.0 19.7 63.8 8.40 145 80 -56.9 -14.9 16.0 25.9 14.7 58.9 8.40 150 80 -56.4 -14.1 16.8 19.8 9.7 54.0 8.40 155 80 -55.8 -13.2 17.7 13.9 4.7 49.1 8.40 335 -35 61.6 18.5 -12.5 183.7 172.1 216.7 8.40 340 -30 55.1 14.1 -15.6 188.2 176.2 217.9 8.50 115 80 -57.9 -18.9 11.3 63.7 49.5 95.8 8.50 335 -30 58.3 18.4 -11.4 190.6 178.1 223.6 I modified an existing perl script to read these examples, create the search file, ephemeris file, and run polesrch. The results get appended to an existing file after each time. I'm running pole search over a range of diameters between 4.0 and 9.0 km in 0.1 km increments. Based on the range extents in the images that should be a safe range; the real diameter is likely in the 6-8 km range. Modify one of the _other_ scripts to read in the results New file: pole.new3.pl I ran it on all the cases above. The regions of acceptable pole directions is almost the same as before although they did shrink a bit. If we adopt normalized residuals = 2.0 (on the bandwidths) as a threshold (on top of the bandwidth ratio and longitude thresholds already adopted), then the results are: rotation periods between 6.6 - 7.5 days and 8.1 - 8.5 days are admissible. Diameters between 5.6 km and 7.0 km are admissible (in the absence of other information). I'm surprised that the range of admissible solutions is so large and I'm a bit surprised that periods of about 7.8 days aren't allowed. This excludes Pravec's period. It doesn't look like we're going to get the rotation period (and diameter) without shape modeling. This also means that getting the km/Hz conversion isn't going to work as well as I had hoped. Does it make sense that rotation periods as small as 6.6 days could match the longitudes so well? Inspect those results more carefully. Double check results for periods between 7.5 and 8.1 days. Did I miss some? Were the bandwidth ratios and longitude difference tolerances too high? DOUBLE CHECK THE PERL SCRIPTS The rotation tolerances of 15 deg (between Jul 24 and Aug 1) and 40 deg (between Aug 8 and the average on Jul 24 & Aug 1) are pretty conservative; it would be appropriate to decrease them to 10 deg and 30 deg. That won't change the fundamental results much, though, just the number of admissible spin states and diameters. We could improve the rotation period constraints by considering the phases on dates other than Jul 24, Aug 1, and Aug 8. For example, the phase on Jul 31 is close to the one on Aug. 8. ======================================================================== 2001 May 8 ======================================================================== Perl scripts used to constrain the JM8 spin state and their function: ===================================================================== 1. jm8.radpolesearch.pl ----------------------- Use radpole to scan the entire sky (in 5 deg increments) and a range of rotation periods between 5.0 and 9.0 days (in 0.1 day increments) to compute subradar latitudes and longitudes for JM8 observations on July 24, Aug 1, and Aug 8. Output the results to a text file named: results.dat (a huge file) 2. radpoleparse.pl ------------------ Parse the results of running radpole over the entire sky and a range of rotation periods. Get the computed subradar longitudes and latitudes, select cases when the Jul 24, Aug 1, and Aug 8 longitudes are similar and when the ratios of the bandwidths between Jul 24/Aug 1 and Aug 1/Aug 8 are within specified ranges computed using raterr. The program actually computes the cosines of the latitudes and takes their ratios. Spin states that satisfy these criteria are output to a file named: output.dat This is the most complicated program of all four Perl scripts used to constrain JM8's spin state due to all the conditional statements necessary in order to select admissible candidates. 3. polesearch.new3.pl --------------------- Run polesrch over a range of diameters for the spin state candidates identified using radpoleparse.pl (one file for each spin state; each file contains labels indicating the diameter). The output files contain the measured and computed bandwidths and residuals. Output the results to files named: jm8.residuals.$period.$lambda.$beta.new 4. pole.new3.pl --------------- Parse the polesrch output files (jm8.residuals.$period.$lambda.$beta.new) and select cases in which the residuals/uncertainties from all three bandwidth measurements are less than a specified tolerance. Output the period, lambda, beta, and diameter to a new text file: new.minimum.residuals.$tol - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Explore implications of the diameter bounds ------------------------------------------- H = 15.2 (Pravec et al.) Deff (km) pv --------- ---- 7.0 0.03 5.6 0.05 ==> JM8 is optically dark, as I've been claiming all along. These diameter bounds are consistent with the average visible range extents in the delay-doppler images. The mean 3.5 cm OCxsec = 2.5+/-0.77 km^2 (mean +/- rms dispersion) Radar albedo (D=5.6 km) = 4*(2.5 km^2)/(pi*5.6*5.6) = 0.10 (D=7.0 km) = 4*(2.5 km^2)/(pi*7.0*7.0) = 0.065 Clearly JM8 isn't radar bright and it could be radar dark. So this analysis establishes preliminary bounds on the radar albedo of 0.065 - 0.10. As such, JM8 is among the darker NEAs observed by radar. These bounds on radar albedo are closer to BFGP and C-type MBAs than to most NEAs. NEAs with comparable radar albedos include: NEAs ==== Radar Rank Object albedo +/- Class ---- ------ ------ --- ----- 12 1620 Geographos 0.12 2.56 S Equivalent spherical albedo from shape model 13 2062 Aten 0.12 0.94 S Deff from Cruikshank et al. (1977) 14 1862 Apollo 0.11 1.5 Q 15 1915 Quetzalcoatl 0.10 0.5 S 16 1580 Betulia 0.09 7.4 C 1989 X-band obs'ns 17 1036 Ganymed 0.064 38.5 S 1988 S-band Obs'ns 18 3757 1982 XB 0.06 0.6 S 19 1566 Icarus 0.04 1.27 S Deff from Harris (1998) MBAs ==== 23 4 Vesta 0.12 0.04 V 24 7 Iris 0.11 0.03 S 41 Daphne 0.11 0.04 C 144 Vibilia 0.11 0.04 C 27 8 Flora 0.10 0.03 S 27 Euterpe 0.10 0.05 S 29 532 Herculina 0.09 0.05 S 694 Ekard 0.09 0.04 CP 31 19 Fortuna 0.076 0.027 G 32 2 Pallas 0.075 0.011 B 33 46 Hestia 0.074 0.024 P 34 324 Bamberga 0.066 0.008 CP 35 139 Juewa 0.061 0.025 CP 36 1 Ceres 0.041 0.005 G - - - - - - - - - - - - - - - - - - Steve and I had another discussion over lunch: 1. The similarity of the images on July 24 and August 1 in both longitude and latitude has been on my mind but I hadn't mentioned it to Steve. He finally noticed the apparent latitude similarity. The question is: why are the images so similar? Is there enough of a difference in latitude? The similarity could be evidence for NPA rotation. Need to dilate the Jul 24 image in Doppler and overlay it on the Aug 1 image to see if there was much latitude motion. The bandwidth differences suggest the latitude motion was about 30-45 deg. If we can't convince ourselves that we see that much of a difference, then that's necessary (but not sufficient) evidence for NPA rotation. This raises the prospect that JM8 is an NPA rotator but in a different sense from Toutatis: with JM8, most of the rotation appears to be about the short axis. If the rotation is NPA, then perhaps the apparent spin axis is precessing at a small angle about the angular momentum vector (and possibly over long time scales). That would make NPA rotation difficult to detect. If correct, then this is very different NPA rotation from that of Toutatis. The first thing I did was to double check my bandwidth estimates. I got results very similar to the ones I've been using: 1.72 Hz on Jul 24 and 3.28 Hz on Aug 1. When scaled appropriately so that the edges align (done by expanding the July 24 image), it's clear that there is a modest amound of longitude difference between the images. The crater-like features have moved--rapidly blinking between them makes this obvious particularly when I remove my glasses The right way to do this is using reverse grayscale viewgraphs. That's not necessary--inspection makes the conclusion obvious. 2. Check the contribution to the apparent rotation produced by sky motion on Jul 24 and Aug 1. Check both the magnitude and the direction on each day, not the displacement between them. Some of this information is output by radpole. Well, it turns out that we already did this: The apparent rotation evident from the images is about 50-60 deg/day for a period of about 1 week. The maximum sky motion per day was 7 degrees so the rotation caused solely by sky motion is on the order of 360/7 = 50 days, which is clearly wrong. Therefore the contribution to the spin vector by the angular rate is too small to matter. 3. Start drafting the logic to explain this to ourselves and co-authors. Run drafts by Steve and then post them on a website for comments from co-authors. 4. Check the Perl scripts again to make sure they didn't omit cases that should have been included. At some point, run radpoleparse.pl again with tighter bounds on the ratios. One could change the bound on the longitude difference between Aug 8 and the average of the Jul 24 and Aug 1 images. I've read background information the force-free rotation of rigid bodies in four different books on mechanics. I have also reviewed work on Toutatis, which I now understand MUCH better. With Toutatis, the spin vector is displaced by a constant angle relative to the long axis (i.e., Toutatis rotates in long axis mode). Toutatis rotates about the spin vector every 5.4 days. The spin vector rotates about the angular momentum vector (which isn't parallel to either a principal axis or to the spin vector) every 7.35 days. As is illustrated in the books, this can be visualized as one cone rotating without slipping on the surface of another cone. See Barger and Olsson, Classical Mechanics: A Modern Perspective (McGraw-Hill, 1973), pp. 232-239 (especially p. 238). For a more detailed discussion, see Goldstein. Toutatis is in long axis mode so the angle between the spin vector and the angular momentum vector is relatively large, making NPA rotation easier to detect than with JM8. With JM8 our suspicion is that the rotation is in short axis mode. That means that the angle between the spin and angular momentum vectors could be smaller than it is for Toutatis but the angle between the spin vector and the principal axis would be much larger. Symmetric top ------------- Let alpha = angle between the spin axis and the symmetry (principal) axis Let theta = angle between the spin axis and the angular momentum vector tan(alpha) = (I3/I)*tan(theta) oblate shape: I3 > I (Earth) prolate shape: I3 < I (Toutatis...although Toutatis isn't really symmetric) Where (in this case) I1 = I2 = I (symmetric object) The rate of precession of the spin vector about the angular momentum vector is omega = (I3-I/I)*(w), where w = rotation rate. Depending on the sign, the precession could be in the same sense as the rotation (oblate spheroid; Earth) or in the opposite sense (prolate spheroid; Toutatis). No, that is incorrect for Toutatis: the senses of precession and rotation are the same. Why? With Toutatis, Ishort/Ilong = 3.19 and Iintermediate/Ilong = 3.01 so Ilong < the other two. If Toutatis were symmetric, then the precession period would be less than the rotation period. But Hudson and Ostro (1995) report that the precession period is _longer_ than the rotation period. Is that because Toutatis isn't symmetric? I don't understand this yet; ask Steve. Hey--if the object is prolate, then , thus making the images appear more regular from day-to-day if the period of rotation about Wint is substantially shorter than the period of precession about L (Wint is the intrinsic spin vector and L is the angular momentum vector). Let Wint = the spin vector and Omega = the precession rate For a symmetric object with I1 = I2 = I (i.e. Earth), omega = Wint*(I3 - I)/I so the rotation period and precession periods are linear functions of each other with the ratios of the moments being the proportionality constant. Since JM8 is an NPA rotator, that means our attempts to solve for the rotation period and pole direction cannot succeed. At best, we might get values close to the rotation about an axis and perhaps a region of space that bounds the precession of the spin vector. We want to get the two periods but that will probably require shape modeling. It would be sweet if we could provide an estimate of the precession period. In any event, our premise that the bandwidth differences on Jul 24 and Aug 1 were due to motion of the subradar latitude is incorrect, so the analysis where I tried to pin the rotation period is invalid. Is it even worth presenting? Given that we have compelling evidence for NPA rotation, that negates the PA rotation stuff. We could state that we did extensive PA rotation searches to test for PA rotation Draft of evidence for NPA rotation ---------------------------------- In images obtained between July 31 and August 8, several prominent features are evident that rotate in a regular manner by about 50+/-15 degrees from day to day, suggesting that the subradar latitude was close to the apparent equator during that interval and that the apparent rotation period Wapp is on the order of one week. Sky motion (Wsky) was less than 7 degrees/day so the contribution to apparent rotation has a minimum period of about (360 deg)/(7 deg/day) = 51 days, which is much longer than the apparent rotation period in the images. Therefore the contribution by Wsky to the apparent rotation is negligible. Images obtained on July 24 and August 1 show nearly the same orientation of the asteroid but the velocity dispersion on August 1 is about two times larger. The change could be caused by motion of the subradar latitude toward the apparent equator; if so, then the factor of two difference in the velocity dispersions constrains the subradar latitude on July 24 to exceed about 60 degrees due to the behavior of the cosine(latitude) function. We expanded the Doppler axis of the July 24 image to facilitate comparison of the images and found that the prominent crater-like features show subtle differences in Doppler frequency that represent modest rotation in apparent longitude. These and radar-bright features on both days show differences in range relative to the leading edge of less than 2 usec, placing a very conservative upper bound on the difference in the subradar latitudes of 10 degrees. To satisfy the difference in the subradar latitudes and velocity dispersions the subradar latitude on July 24 must have exceeded about 80 degrees. If the subradar latitude on July 24 was at least 80 degrees, then the bandwidth on that day and the apparent rotation period of about 1 week requires that the diameter is at least 16 km, which is much larger than is observed. Consequently, the subradar latitude on July 24 cannot be 80 degrees and JM8 cannot be a PA rotator. The change in the bandwidths was not caused by a difference in the subradar latitude; instead, it must have been caused by a change in the intrinsic spin vector Wint, indicating that JM8 is a non-principal axis rotator. - - - - - - - - - - - - - The regularity of the images during the interval above suggests that the rotation period about the spin vector is on the order of about one week and that the subradar latitude was close to the apparent equator during that interval. Burns (1971) suggested that the period of precession of Wint about L is much longer than rotation about Wint by up to a factor of ten. If the object is axisymmetric then theory predicts that the precession period will be longer than the rotation period. Discuss aspects of NPA rotation and allude to Toutatis. Cannot go far with analysis until the shape model is done (future paper). Mention the angle between the spin axis and the principal axis about which the rotation occurs and the angle between them and the angular momentum vector. The spin vector Wint precesses about the momentum vector with a period that we don't know yet and may not be able to obtain until the shape modeling is done. Angle between L and Wint could be small; if so, then rotation would be difficult to distinguish from PA. Period of precession could be much longer than the rotation period but not necessarily: with Toutatis the periods are in the ratio of 1.36. Show that the subradar latitude isn't at very high values where small differences in latitude could produce factor of ~2 (1.9) differences in bandwidth. cos(60) = 0.5, so the minimum latitude on Jul 24 was about 60 deg if the latitude on Aug 1 was zero. can any point on the curve be reconciled with the rest of the dataset? If not, NPA rotator. Then revise text, post on the web, and contact co-authors. Quantify "nearly" the same latitudes using locations of features in the images relative to the LE. A quick conservative estimate would be < 10 deg. Range resolutions Jul 24 0.5 us Aug 1 0.1 us So range differences of ~0.5 us are consistent given the differences in range res'n. range diff from LE (us) feature freq Jul 24 Aug 1 ------- ---- ------ ----- bright spot "inside" crater - 7.5 8.0 bright spot inside smaller crater (neg of other one) - 10.5 10.8 center of top lineament 0 2.5 3.2 center of small dark crater 0 7.5 8.6 near 0 Hz So there may have been some latitude rotation--but almost certainly less than about 10 deg. Features in the images are within about 1 us of each other or ~150 m in range. If JM8 were a 6 km spheroid then 10 deg of latitude movement could produce a range difference of 150 m. Small differences in ranges of features in Jul 24 and Aug 1 images indicate that latitude motion between those dates was small--less than about 10 degrees. For there to be less than 10 deg of latitude motion and a factor of 1.9 difference in bandwidth the subradar latitudes would have to be at least 80 deg on Jul 24 and 70 deg on Aug 1. In other words, the view was close to a pole on both days. However, other evidence contradicts this: 1. The regular rotation of prominent features in the images between Jul 31 and Aug 9 is indicative of subradar latitudes close to the equator, not close to the pole. 2. There are pole directions consistent with the bandwidths on Jul 24, Aug 1, and Aug 8, based on the search I did earlier assuming PA rotation (over a range of rotation periods), but that search indicates that the maximum subradar latitude on July 24 is 63 deg, so there's a contradiction. That search also constrained the subradar latitude on Aug 1 to be between 12-26 deg. 3. If the subradar latitude on July 24 was 80 degrees, then that implies that the diameter of JM8 is: D = B*P/[100*cos(delta)] = (1.7 Hz)*(7 days)*(24 h/day)/[100*cos(80 deg)] = 16.4 km That is several times larger than the range extent we observe on July 24, so the subradar latitude cannot be 80 degrees. Thus, JM8 cannot be a PA rotator. ---------------------------------------------------------------------------- 1. July 31-August 9 images suggest Wapp ~ 1 week (~50 deg/day). 2. Assume principal axis rotation 3. Wapp = Wint + Wsky 4. Sky motion <= 7 deg/day so contribution by Wsky to Wapp is negligible 5. July 24 and August 1 images have very similar longitudes but Bjul24/Baug01 = 0.52+/-0.05 6. JM8 moved 50 deg between July 24 and August 1 7. nu = (Wapp x r).e/(lambda/2) (Wapp, r, e are vectors). Can also be written as B = 100 D cos(d)/P 8. Bjul24/Baug1 = cos(djul24)/cos(daug1) = 0.52+/-0.05 9. Bjul24/Baug1 is due to change in cos(d) 10. |daug1| >= 0 deg, so djul24 = acos[(0.52)*cos(daug1)] >= 59 degrees. 11. Features in the July 24 and August 1 images differ by less than 10 deg of latitude: | djul24 - daug1 | <= 10 deg 12. If djul24 - daug1 <= 10 deg, then djul24 = daug1 + 10 but cos(djul24) = (0.52)*cos(daug1) so cos(daug1 + 10) = (0.52)*cos(daug1) and cos(daug1)cos(10) - sin(daug1)*sin(10) = (0.52)*cos(daug1) sin(10)*sin(daug1) = (cos(10) - 0.52)*cos(daug1) tan(daug1) = (cos(10) - 0.52)/sin(10) daug1 = atan(cos(10) - 0.52)/sin(10) = 69.5 deg therefore djul24 = 69.5 + 10 = 79.5 deg 13. If djul24 >= 79.5 deg, then D >= B*P/100*cos(djul24) >= (1.7 Hz)*(~7 d)*(24 h/d)/[100*cos(79.5)] >= 15.7 km 14. visible range extents (~ 1/2 of true range extents) average 3.6 km, which is inconsistent with D >= 15.7 km 15. Bjul24/Baug1 was not caused by change in delta; must be a change in Wapp. So JM8 cannot be a PA rotator =================================================== 2001 May 16 =================================================== I asked Ray and Marty to estimate the subradar longitude and latitude differences between the July 24 and August 1 images. They preferred to estimate differences in pixels; both concluded the differences in Doppler were larger than the differences in range. Marty estimated range differences of about 0.5-0.6 us, which are consistent with the estimates I got above. He used two features; I checked more. - - - - - - - - - - - - - Using the measured displacements of features in range relative to the leading edges on July 24 and August 1, what angles would those displacements correspond to if JM8 were spherical? This is a simple trig exercise. Recall that y = r sin(delta). dy = y1 - y2 = 0.15 km. r is about 3.0 - 4.0 km; 3.5 km is my best estimate. Vary delta1 between 0 - 90 deg and compute delta 2 and their difference. It turns out that the difference is less than 15 deg and exceeds 10 deg only if one of the latitudes is about 81 deg. So my estimate of 10 deg is reasonable; in fact, it's very conservative unless we were very close to the pole, which we couldn't have been due to the diameter contradiction. - - - - - - - - - - - - - I prepared a website and then we sent a modified version of the statements above to Mike, Ellen, and Jean-Luc. They replied within a day and I'm now drafting a response. =================================================== 2001 August 23 =================================================== Reduce file VOLT99199-8k with a 256-point FFT to get dfreq = 1.95 Hz -------------------------------------------------------------------- I had to fix the link to the raw file: all the VOLT file links in /data/ast5/1999JM8/proc/cw/ are wrong. Deal with the others later if necessary. reason:/data/ast5/1999JM8/proc/cw < 85 > dofft -d 7.0 -p 168 -f 256 -i VOLT99199-8k.1999JM8 -o 99199-8k.256fft.raw.rdf -x PRDX.OUT.s15 contents of ast_spec control file: 256, 1, 1, /home/wart/bin/ast_spec_1.25 variables: DATAIN=VOLT99199-8k.1999JM8 RDFOUT_1=99199-8k.256fft.raw.1_1.rdf RDFOUT_2=99199-8k.256fft.raw.1_2.rdf CONTROL=specs_in.dat Running /home/wart/bin/ast_spec_1.25 /usr/local/bin/jurg2spec -i 99199-8k.256fft.raw.1.rdf -o 99199-8k.256fft.raw.rdf -x PRDX.OUT.s15 -p 168 -d 7.0 Using .data1 as temporary storage for OC data Using .data2 as temporary storage for SC data Total hop states: 2 Total OC spectra: 1576 Total SC spectra: 1576 Processing data... reason:/data/ast5/1999JM8/proc/cw < 86 > Note: I previously reduced the PSD file but it used an 8192 FFT giving dfreq =0.061 Hz and only 21 looks. I used dfreq = 1.95 Hz to estimate OCxsec and SC/OC for the other dates, so that's why I'm using FFT=256 for this file. This file has the most runs of any CW file in the whole dataset. dfreq = 1.95 Hz nearly match-filters the echo in Doppler. There are 1576 looks. Wow. irun tags are all set = 1. Block into a file. Tsys: ch1 = 15.2, ch2 = 16.5 ==> close enough. gain and trpwr are OK. I reduced the data. So far so good. I change jsnr1, 2 = 60, 70 in order to completely encompass the echo, which has a large enough Doppler correction that jsnr1,2 were offset from the echo by about 1 Doppler bin. A weighted sum of all the runs has an OC SNR of about 550. Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-oc 01:44:05 00:00:00 02:15:37 0.0 3.84e-03 2.46e+00 ± 4.6e-03 2.7 Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.file.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-sc 01:44:05 00:00:00 02:15:37 0.0 4.17e-03 5.20e-01 ± 4.9e-03 2.7 0.211576 0.213629 0.209524 OCxsec = 2.46 km^2 SCxsec = 0.52 km^2 SC/OC = 0.21+/-0.01 Earlier on the same track (about 4.5 hours earlier) I got OCxsec = 2.96 km^2, a difference of 19% despite the fact that the asteroid rotated by perhaps (4.5 h/24 h/d)*(50 deg/d) = 9 deg. This is another good illustration of why we don't quote Goldstone cross section uncertainties of less than 25%. I plotted the noise histograms: There aren't many points due to the short FFT and small bandwidth, but the noise is clearly Gaussian. Let's take a closer look at OCxsec by blocking into runs. There are about 160 looks/run so the noise statistics will still be Gaussian. change jsnr1,2 again: 60,70 Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-oc 01:44:05 00:00:00 01:45:35 0.0 1.22e-02 1.82e+00 ± 1.5e-02 2.9 2 1 1999/07/19 2-oc 01:47:24 00:00:00 01:48:58 0.0 1.25e-02 2.69e+00 ± 1.4e-02 2.6 3 2 1999/07/19 3-oc 01:50:45 00:00:00 01:52:19 0.0 1.22e-02 4.25e+00 ± 1.4e-02 2.6 4 2 1999/07/19 4-oc 01:54:05 00:00:00 01:55:35 0.0 1.22e-02 2.13e+00 ± 1.4e-02 2.7 5 3 1999/07/19 5-oc 01:57:26 00:00:00 01:59:00 0.0 1.24e-02 2.12e+00 ± 1.5e-02 2.7 6 3 1999/07/19 6-oc 02:00:47 00:00:00 02:02:21 0.0 1.21e-02 2.93e+00 ± 1.4e-02 2.6 7 4 1999/07/19 7-oc 02:04:07 00:00:00 02:05:37 0.0 1.21e-02 2.59e+00 ± 1.5e-02 2.9 8 4 1999/07/19 8-oc 02:07:27 00:00:00 02:09:01 0.0 1.24e-02 2.49e+00 ± 1.5e-02 2.8 9 5 1999/07/19 9-oc 02:10:47 00:00:00 02:12:21 0.0 1.21e-02 3.30e+00 ± 1.4e-02 2.6 10 5 1999/07/19 10-oc 02:14:07 00:00:00 02:15:37 0.0 1.20e-02 2.44e+00 ± 1.5e-02 2.9 Target unknown from file /data/ast5/1999JM8/proc/cw/99199-8k.256fft.runs.rdf # PR YY/MM/DD RUN-POL TXSTART RCSTART RCEND PHASE KMSQ/SDEV Radar Cross Section Width RATIO HIERR LOERR 1 1 1999/07/19 1-sc 01:44:05 00:00:00 01:45:35 0.0 1.33e-02 5.90e-01 ± 1.6e-02 2.8 0.324156 0.333318 0.315038 2 1 1999/07/19 2-sc 01:47:24 00:00:00 01:48:58 0.0 1.36e-02 5.69e-01 ± 1.5e-02 2.5 0.211214 0.217045 0.205394 3 2 1999/07/19 3-sc 01:50:45 00:00:00 01:52:19 0.0 1.32e-02 4.30e-01 ± 1.4e-02 2.1 0.101291 0.10451 0.0980736 4 2 1999/07/19 4-sc 01:54:05 00:00:00 01:55:35 0.0 1.32e-02 5.15e-01 ± 1.6e-02 3.0 0.241562 0.249383 0.233763 5 3 1999/07/19 5-sc 01:57:26 00:00:00 01:59:00 0.0 1.35e-02 6.58e-01 ± 1.6e-02 2.7 0.310348 0.318126 0.302599 6 3 1999/07/19 6-sc 02:00:47 00:00:00 02:02:21 0.0 1.32e-02 5.65e-01 ± 1.6e-02 2.9 0.192957 0.198487 0.187436 7 4 1999/07/19 7-sc 02:04:07 00:00:00 02:05:37 0.0 1.31e-02 5.29e-01 ± 1.8e-02 3.7 0.204698 0.211781 0.197629 8 4 1999/07/19 8-sc 02:07:27 00:00:00 02:09:01 0.0 1.34e-02 4.89e-01 ± 1.6e-02 2.6 0.196124 0.202463 0.189799 9 5 1999/07/19 9-sc 02:10:47 00:00:00 02:12:21 0.0 1.31e-02 6.56e-01 ± 1.7e-02 3.1 0.199146 0.204234 0.194065 10 5 1999/07/19 10-sc 02:14:07 00:00:00 02:15:37 0.0 1.31e-02 5.31e-01 ± 1.6e-02 3.1 0.217838 0.224726 0.210967 Wow! The variation is enormous. Substantial variations in OCxsec are obvious in the spectra due to differences in the SNR. Why do the cross sections differ by so much? So OCxsec varies from 1.82 -> 4.25 km^2, a factor of 2.3, and SC/OC varies from 0.10 -> 0.32, a factor of 3.2. Not good. Good thing we did 10 runs...but that raises the disturbing question of the reliability of OCxsec and SC/OC on the other days, when we usually did only 1-2 runs... In the future, if time permits, try to do at least 10 cw cycles prior to imaging and be sure to get enough looks to achieve Gaussian noise statistics. More fuel for the fire: Date file runs looks OC SNR B OCxsec SC/OC (Hz) (km^2) (+/-0.01) ________________________________________________________ Jul 18 99199 7 1270 940 1.5 2.96 0.19 Jul 19 99199-8k 10 1576 540 1.5 2.46 0.21 Note that the SNR also varied considerably between the time when we obtained 99199 and 99199-8k. - - - - - - - - - - - - - - - - - - - - DIFFERENCE IMAGES ================= Mike and Ellen suggested we use difference images to show rotation instead of a sequence. That's a great suggestion: I hadn't considered it. It turns out that Spyglass Transform can do this using the Notebook. The trick is to get two images with different names (if they're both Untitled, the default, then the difference = 0). An easy way to get the file names is to create a new file, set the file name and the number of rows and columns, and then paste in the data. The Aug 8 difference image is striking: the regions of the most difference are black and white and they stand out well. On Aug. 5 the difference is more subtle due to the shorter time between the images and due to the smaller number of looks, but it's good enough to make the point that JM8 rotated during the track. =================================================== 2001 August 27 =================================================== COLLAGES, revisited ------------------- Back in April I didn't document very well how I vignetted the Arecibo images that I used to create the grand collage (1.02 Hz x 40 us; S-band). It turns out that I modified the script used to create the SC/OC images--that is, that script has the number of columns x rows and the center points. For reference, here they are: Date #cols #rows colcen rowcen Hz x us ---- ----- ----- ------ ------ -------------- Aug 1 105 400 150 1000 0.009807 x 0.1 Aug 2 109 400 169 619 0.009435 x 0.1 Aug 3 115 400 145 415 0.008929 x 0.1 Aug 4 123 400 196 446 0.008335 x 0.1 Aug 5 132 400 135 361 0.007814 x 0.1 Aug 6 140 400 167 350 0.007354 x 0.1 Aug 9 171 400 224 364 0.006025 x 0.1 Ratio images with the Doppler frequency increasing from right to left: reason:/data/ast5/1999JM8/arecibo/proc/rng/ratio_images < 29 > ls -l *s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990801.scoc.3.s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990802.scoc.3.s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990803.scoc.3.s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990804.scoc.3.s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990805.scoc.3.s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990806.scoc.3.s.tiff -rw-r--r-- 1 lance staff 41746 Aug 27 2001 jm8.990809.scoc.3.s.tiff Likewise for files with *gif extensions. These are ready to assemble into an SC/OC collage. The range and Doppler extents match. For purely grayscale images, Scott's program pgmstack (on his system) is the fastest way to create a collage. For a collage that mixes grayscale and color figures, use our tkgraph software (unless Scott has more software than he's made available). We can create collages using tkgraph. Don't use the HDS terminals--the grayscale images will dither. Instead, prepare the collage on the console on rhyme or reason. tkgraph requires that the figures be gifs and they can be b & w and/or color. When the collage is done, write it to a postscript file and then use alchemy to convert it to a gif. At their present sizes (200 x 200 pixels), the individual gifs are too large to fit onto one or even two vertical pages. Use XV to shrink them. If that introduces artifacts, then recreate them at smaller sizes using Spyglass Transform to make tiffs and then alchemy or XV to make gifs. The tkgraph template measures 760 pixels down and 588 pixels across in the portrait orientation (or vice versa for landscape). So... there are images from 7 days, so 760/7 = 108.6. Another option: Create gifs, ftp them to the Mac down the hall, and use Photoshop to create the collage. Or... Is it possible to make a collage using html and then print it to a file? That might be faster than using tkgraph. Here's what I did ----------------- I used XV to change each SC, OC, and SC/OC image to 100 x 100 pixels. I used tkgraph to create the collage. I loaded the Spyglass Transform collage with Transform, used XV's screen grab feature to grab the color bar, and then imported it into the SC/OC collage using tkgraph. I printed the collage to a PostScript file. I used alchemy to convert the PostScript file to a gif. I used XV to resize the final image so it would fit on the draft manuscript website. I also used XV to adjust the size of the color bar so it would fit on the page. With tkgraph I iterated on the location of the color bar to center it. Here's the alchemy command line that I used: alchemy jm8.scoc.collage.ps jm8.scoc.collage.gif -o -g -Zm2 -Zb 2.10i 1.25i 3.08i 1.27i The last four items specify white space to cut off of the left, bottom, right, and top in inches. -Zm2 indicates that it's a color figure. -g specifies a gif file, and -o overwrites previous copies of the output file. - - - - - - - - - - I adjusted the Aug. 5 difference image using jm8proc on intruder. I changed the vignetting to match the extents in the other figures. =================================================== 2002 May 15 =================================================== The manuscript has been accepted by MAPS. I am modifying the OC image collages to include A and G to indicate the observatory. It turns out that MAPS can accept only tiffs. Originally I sent PostScript files. I used alchemy to convert the files but they didn't look good--they were pixelated. Ultimately I asked the Photolab for help and Steve Benskin did a very nice job. Emails about this are in the JM8 paper notebook. The key for converting PostScript to really nice tifs is to use antialiasing. Steve Benskin pointed that out to me. Here's what I did for the JM8 difference image figure: alchemy input.ps output.tif -t -Za4 -Zm1 -Zc -o where -Za4 sets the antialiasing to its highest (best) value, -Zm1 selects a grayscale figure, -Zc clips white space around the margins, and -o overwrites "input.tif" if it already exists in the working directory. Today I changed text on the OC collages and I'm trying to convert the new PostScript files to tifs without using the Photolab (due to their exhorbitant prices). Need to experiment with the resolution in DPI. Previously we used 600 DPI. Output an image with 300 dpi: alchemy input.ps output.tif -t -Za4 -Zm1 -Zc -Zd 300 300 -o That took just under 3 minutes. Producing a file with 600 dpi took about 12 minutes. What we really need is PhotoShop... =================================================== 2002 May 17 =================================================== New files: rhyme:/data/ast5/1999JM8/paper/temp < 20 > ls jm8.oc.collage.aug02_aug09.new.ps jm8.oc.collage.jul20_aug01.new.ps jm8.oc.collage.aug02_aug09.new.tif jm8.oc.collage.jul20_aug01.new.tif There are some things that have bothered me about the OC image collages: 1. Using tkgraph seems to have sacrificed some resolution. some details are missing. 2. The stretches on some days make the images too dark and lose detail. 3. The aspect ratios compress the images too much vertically, which also sacrifices details. My original plots were created using Spyglass Transform with echoes saturated at some percentage of the maximum. To make this figure I didn't saturate at all used Transform to make tifs and then XV to adjust the stretches. However, when I did the stretches all I didn't use any clipping or saturation, which I had forgotten is easy to do using XV, so I'm tinkering with that. I may reassemble the images. Ideally I think these figures would have been better with the vertical dimension increased by about 50%. Three parts with 6 panels each would work better than two panels with 8 images each. I have modified the stretches of each panel using XV. That has improved the images significantly. Installing the modified gifs into the tkgraph figure is straightforward: since the tkgraph figure has lines of text, just replace the lines for each previous figure with the new one. I copied the old file into a different name and modified the new one. reason:/data/ast5/1999JM8/paper/oc_collage < 55 > cp jm8.oc.collage.aug02_aug09.new.tpl jm8.oc.collage.aug02_aug09.maps.tpl reason:/data/ast5/1999JM8/paper/oc_collage < 56 > cp jm8.oc.collage.jul20_aug01.new.tpl jm8.oc.collage.jul20_aug01.maps.tpl The new figures are MUCH better than the old ones, which had low contrast and were too dark. The new ones have more contrast, the echoes are brighter, and they're downright striking. reason:/data/ast5/1999JM8/paper/temp < 73 > alchemy jm8.oc.collage.jul20_aug01.maps.ps jm8.oc.collage.jul20_aug01.maps.tif -t -Za4 -Zm1 -Zc -Zd 600 600 -o Image Alchemy PS (v1.10) - Copyright (c) 1990-97, Handmade Software, Inc. Reading PostScript file jm8.oc.collage.jul20_aug01.maps.ps Writing TIFF file jm8.oc.collage.jul20_aug01.maps.tif (compression type 1) Interpreting PostScript file / Saving image........................................ (00:15:27) rhyme:/data/ast5/1999JM8/paper/temp < 33 > alchemy jm8.oc.collage.aug02_aug09.maps.ps jm8.oc.collage.aug02_aug09.maps.tif -t -Za4 -Zm1 -Zc -Zd 600 600 -o Image Alchemy PS (v1.10) - Copyright (c) 1990-97, Handmade Software, Inc. Reading PostScript file jm8.oc.collage.aug02_aug09.maps.ps Writing TIFF file jm8.oc.collage.aug02_aug09.maps.tif (compression type 1) Interpreting PostScript file | Saving image........................................ (00:13:49) I loaded and printed the tifs using XV. The resolution of the text is a bit worse than with the PostScript files but it's good enough. Steve Benskin at the Photolab is able to do something that I don't know about to make the figures even better. The revised figures still look great. - - - - - - - - - The SC/OC collage in the MAPS pdf file has a blue tint. Steve likes the blue but I do not and I want to get rid of it. I tried to check the tifs we sent to MAPS but I cannot find them. Those are the files provided to us by the Photo Lab. I even checked four backup cdroms. Where are those files...? They were very large, so perhaps I thought they were backed up and deleted them. Rats... Instead, let's go to the PostScript file, use Alchemy to convert it to tif, and then see how it looks. If necessary, I can use XV to remove the blue. rhyme:/data/ast5/1999JM8/paper/temp < 35 > alchemy jm8.scoc.collage.ps jm8.scoc.collage.tif -t -Za4 -Zm2 -Zc -Zd 600 600 -o Image Alchemy PS (v1.10) - Copyright (c) 1990-97, Handmade Software, Inc. Reading PostScript file jm8.scoc.collage.ps Writing TIFF file jm8.scoc.collage.tif (compression type 1) Interpreting PostScript file / Saving image....................................... (00:15:21) rhyme:/data/ast5/1999JM8/paper/temp < 36 > ls -l total 60176 -rw-r--r-- 1 lance staff 2938705 May 17 15:22 jm8.oc.collage.aug02_aug09.maps.ps -rw-r--r-- 1 lance staff 3027714 May 17 15:40 jm8.oc.collage.aug02_aug09.maps.tif -rw-r--r-- 1 lance staff 2938705 May 15 16:05 jm8.oc.collage.aug02_aug09.new.ps -rw-r--r-- 1 lance staff 2899812 May 15 17:05 jm8.oc.collage.aug02_aug09.new.tif -rw-r--r-- 1 lance staff 2940126 May 17 15:22 jm8.oc.collage.jul20_aug01.maps.ps -rw-r--r-- 1 lance staff 3208566 May 17 15:42 jm8.oc.collage.jul20_aug01.maps.tif -rw-r--r-- 1 lance staff 2940126 May 15 16:05 jm8.oc.collage.jul20_aug01.new.ps -rw-r--r-- 1 lance staff 2973386 May 15 17:06 jm8.oc.collage.jul20_aug01.new.tif -rw-r--r-- 1 lance staff 1429986 May 17 17:23 jm8.scoc.collage.ps -rw-r--r-- 1 lance staff 5413658 May 17 17:47 jm8.scoc.collage.tif This file is enormous: 5.4 Meg. jm8.scoc.collage.tif looks fine when viewed with XV: the background is white, not pale blue. I'm going to send them the new figure electronically just in case. Just in case the pale blue version was an artifact of viewing xv at the same time as running Netscape on an 8-bit monitor, I also checked the tif on rhyme's console w/o Netscape and found that the background is white. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Still to do: 1. Apply dofft to some of the data from the first track to get 1.95 Hz resolution. Use either file 99199B (1000 Hz sampling, 3 runs, and four hops), or file 99199-16k (4000 Hz sampling, 4 hops, 6 runs). 99199-16k would be better because we should get twice as many looks. ==> DONE using 99199B-8k. There is no voltage file for 99199-16k. 2. Check the tags in the Goldstone rdf files: DONE 3. Verify the acunorm normalization in the Goldstone images: IT'S WRONG. ==> I fixed it. 4. Correct the normalization in the Goldstone images using corrected tags: DONE 5. Check for delay drift in the Goldstone images: checked DOY 212 and 213--see evidence of rotation but no obvious drift. Ephemeris was good. 6. Tabulate TXoffsets in the images, the delay-Doppler sign convention, and the range/bin for the COM of the OSOD solution for each image. Tabulate the LE locations and center freqs. ==> DONE 7. Verify that Mike Nolan's rdf conversion worked. DONE 8. Check the Arecibo image tags (whichever version we end up using). DONE 9. Check for delay drift in the Arecibo images: DONE... hard to tell because of jitter in eph_row due to software problems, especially on Aug 1 and 2. Any drift is at a level of only a couple of gates. 10. Write a preliminary draft of a full-length manuscript: say as much as possible without the shape modeling. 11. Look over the Arecibo SC images. 12. Create ratio images. To do this, we'll need to vignette the images to speed calculation and we'll need to clip the levels to avoid division by zero. Prepare one ratio image per day...work with images that are already weighted sums. For Toutatis, Keith ignored pixels below certain thresholds of 5 or 10 sigma. Keith mapped other pixels to black. So the ratios are taken only on pixels with echo power in both polarizations above a certain threshold. We have dual polarization images for seven days at Arecibo. There will still be chi-square effects due to the small number of looks on some days. Ratio images aren't as important as getting the data to Scott so postpone this until after Steve has commented on the draft. We have OC & SC images from 7 days at Arecibo. Check for SC/OC bright and dark spots, especially near crater rims. 13. Experiment with using GIMP and IDL. See if IDL can plot points on a sphere to show sky motion. 14. Verify that Jean-Luc's rdf conversion worked. 15. Examine Arecibo CW data. See if it's worthwhile to estimate radar cross sections (probably not) and check SC/OC. 16. Prepare updated Arecibo images and hardcopies 17. Prepare spiffy Arecibo SC/OC images...done 18. Backup the JM8 files onto a CD 19. Put SC, OC, and SC/OC images on a website 20. Tell Scott where SC images area...done ============================================================================== Future topics ============= 1. Correlation between the shape model and spectroscopic features. 2. Include lightcurves in the inversion and estimation of the spin vector. Illumination of the surface during the lightcurves. Photometric properties. 3. Combine 3-D shape model with thermal infrared results? 4. Do the crater sizes on JM8 cross the strength-gravity transition for an object of its size? If so, how does that effect crater morphology? Asphaug et al. (1996) state the large craters on Ida can have asymmetrical shapes due, in part, to Ida's non-spherical shape. So on small bodies, dimensions of relatively large craters may be a function of target gravity, which in turn can be distinctly non-uniform. That is, as a function of increasing crater size, we expect to see a transition of crater morphology from nearly circular in map view to more irregular shapes. ==> Ask Erik. 5. Radar-bright crater rim: Asphaug et al. (1996) also state that optically bright crater rims on intermediate-sized craters may not be ejecta but instead low-velocity surface disturbances. Presumably local seismic shaking could roughen the surface sufficiently to produce the radar bright returns. Radar bright crater rims are worth checking in the SC images and in ratio images.