Shift report A August 1 1999, 8:00am EDT, GMT 213:12:00 ACIS Activities this Shift 1. Third run through of the Internal Cal Source Measurement Spacecraft Activities - IPS burn 3, see Yousaf's report, we are cruising out to 140,000 km - Earth sensor scan, post IPS 3 - preparations for IPS 4 at GMT 214:05:00 - IU Load and Dumps [planned] requires FMT 3 for 3m45s Data Processing Activities Shanil spent a frustrating night learning about the intricacies of processing dump data from the DSN and JPL and GOT. See his note below. 1. Internal Cal Source Measurement FP temp = -117.3 Altitude ~ 60,000 km - Timed Exposure Faint Mode on the I array, no g7 events OBSID == 62741 Start science at GMT 213:04:58 Stop Science at GMT 213:09:20 ** NOTE, we had an SCS collision on this run !!!!!!! We loaded slot 143 and PCAD had loaded slot 143, executed it but not cleared and disabled it. We received no error on loading slot 143 but the OBC would not let us enable and activate the slot because it was already enabled and activated. This meant that the DUMP_TE_SLOTS command did not get executed for this run. This is no big deal but it emphasizes why we must watch each command execute because we can identify quickly problems which may be more serious for the spacecraft. Mark Bautz, the eminent project scientist, noted that there were ~850,000 events in this first science run. We have to thank the HRC for all this time. - Timed Exposure Faint Mode on the S array, no g7 events FP temp = -118.7 C Altitude ~ 90,000 km OBSID 62740 Start Science at GMT 213:09:20 Stop Science at GMT 212:?????? ************************************************************************** Shanil's note on the Dump data processing, with some editing from Paul Hi Paul, Ok, below is a rough timeline of issues that arose in my dealings with GOT/CCDM. The SSR dump file I was interested in was 1999_211_0523_211_1331_DUMP_EM_26200.gz. As we all know, that dump data contains data from the ACIS int cal measurements. Since there were realtime telem dropouts, we were interested in processing the dump data. In addition, since there were dropouts, the MIT folks don't have access to the complete data set and providing them with the dump data would have satisfied this requirement. Well, this is where the fun begins. SSR dump data is *suppose* to be placed in /dsops/GOT. When I looked at the contents of that directory, I saw dump files preceding and proceeding the file of interest but not the file itself! So I went and asked the folks who sit in the same office as the duty sci folks and they did not know what happened to that dump data or when it was to "appear" in /dsops/GOT. At that time, I can and told you about its MIA status. We talked to the CCDM people and they said they had it and it was "here". Sure enough, a few minutes later you came and told me that GOT in fact had it "but they put it in the wrong directory". At that point, I got an email from GOT stating that had put the file into /dsops/GOT but no subsequent email as to its data quality. During the last few days, whenever GOT places a dump data file into /dsops/GOT they email all concerned a "data quality summary". Ostensibly what this amounts to is the first VCDU, end VCDU, span of VCDUs, and hence number of VCDU gaps and number of VCDUs missing. Not knowing the data quality of the dump data and knowing from conversations with you that there were significant telem dropouts during that time span, I requested GOT to run their data quality software on the above mentioned dump file. It was determined that nearly 54% of the minor frames during that time span were missing!!!!! On top of that, I asked them if it was possible for them to retrieve the data elsewhere so that we could recover the missing minor frames. I was told that data was "irretrievably lost" and what we had is what we had. I expressed to them that this time span consisted of ACIS int cal measurements that are important to us but they once again said they could not do any better. After hearing this, I came and told you what they told me. After speaking with the CCDM people and understanding what is meant by "dump data" and what it means when CCDM says "we have dump data", we reiterated our concerns and what was told to me to Dan, the SOT Lead. Rob Cameron, fortunately has written his own perl scripts that can analyse SSR dump data to ascertain its data quality. We ran his script on the SSR dump data produced by GOT and on the dump data from JPL that was resident on Lucky. His analysis revealed that the GOT dump data does indeed have ~54% of its minor frames missing, however, the JPL data had **4** minor frames missing (compare this to the ~62000 frames that GOT maintains). I took these results took GOT and they once again claimed that "we" were wrong. After expressing their sentiment to Rob, Dan, and you, Dan called GOT lead. He came to the ACIS TST area and once again reiterated that he believes that there is very little that could be done. Even though Rob's analysis showed the JPL data was good, it may not be valid for other reasons. To which Rob stated based on personal experience with this script on previous data dumps, it was unlikely that JPL data was not good or usable. GOT lead finally agreed to look at that dump data once again and compare the quality of its dump data against the JPL data. And that's where things stand. Shanil UPDATE: GOT lead just came in confirmed Rob's analysis. The GOT dump data is unacceptably poor and the JPL data is good. That is, the data as telemetered down from Chandra is very good (4 minor frames missing) and does exist here in Cambridge. However, in taking that data and producing the dump data that is then given to the science center (ie, us), these errors creep in. GOT does not understand how this happened but are working on it and will provide us with SSR data that is good so that we can get our int cal measurements again! WHEW! Let's hope this does not happen again. Also, let me reiterate something else I have come to believe. If there is a problem with the dump data or the real time data, the duty sci folks are not yet aware that this processing needs to be monitored. Staff: ACIS: Mark Bautz, Royce Buehler, Paul Plucinsky SOT: LEAD: Dan Schwartz ACA: Rob Cameron EPHIN/PCAD: Eric Martin