reply notes by Boris Semenov, February 17, 2005. ------------------------------------ brief summary of corrections (08/11/05): -- the data file was not changed; -- none of the liens on the calibration document and those that seem to be related to interpretation of the data were addressed; these liens are are marked as "NOT RESOLVED YET" in the notes below. -- the following templates, text docs and labels were revised to address other liens: ./CATALOG/DATASET.CAT ./CATALOG/INST.CAT ./DATA/DFMIEDR.FMT ./INDEX/INDEX.LBL ./AAREADME.TXT ./VOLDESC.CAT ------------------------------------ SDDFMI_0002 =========== o When SPICE is used to generate geometry values in labels, the DATA_SET_ID should be referenced in the data label and the specific kernels used should be identified by filename. In cases where non-archived kernels were used, the kernel files themselves should be included in the data set archive. -> NO CHANGE: kernels are listed in dataset.cat. I'll add SPICE DS ID to that listing but will not put any SPICE into into the data labels. -> NO CHANGE aareadme.txt ------------ o Change the string '*.LBL' to '*.FMT' in the following line: DATA: | +-- *.LBL DFMI EDR table column format definition file(s). -> WILL CHANGE -> DONE o Since there is only one of each of these formats in the data directory, should the actual name of each file be given? -> NO CHANGE: is there a requirement to spell them out? :) -> NO CHANGE errata.txt ---------- o This file is not necessary. -> WILL CHANGE: will remove it and change AAREADME ... unless some errata will come out of this round. -> PENDING: we still don't know whether there is going to be some errata or not. voldesc.cat ----------- o Catalog file names are not the same as the names of the files in the catalog directory (data set and instrument). -> WILL CHANGE: this has been fixed already. -> DONE o Syntax error line 56: Comma following the DATA_SET_CATALOG value. -> WILL CHANGE -> DONE catalog/ -------- dataset.cat o Missing ABSTRACT_DESC and CITATION_DESC -> WILL CHANGE: need examples. -> DONE o Under the "Ancillary Data" heading, we should add the DATA_SET_ID of the Stardust SPICE data set for completeness and for user convenience. -> WILL CHANGE -> DONE o Under 'Processing' section, "striped" should be "stripped" -> WILL CHANGE -> DONE inst.cat o Need an attribution for the description section. -> WILL CHANGE: will add this. -> DONE data/ ----- o In the Acoustic Sensor values, particularly the high & low bumpers, the values around close approach do not seem reasonable - the "cumulative count" increases and decreases a number of times, but there is no documented instrument problem or rollover that might explain this. An explanation is needed. -> WILL CHANGE: .. at least will TRY. I'll refer this to T.Tuzzolino and T. Economou (Inst. Lead and his Deputy. ) I cannot predict if I'll receive anything from them. -> NOT RESOLVED YET: It seems that Simon Green has anwered this question in his e-mail from 06/14/05. Where in the data set should his answer be included (DATASET.CAT?) o Column heading definitions do not contain units. The appropriate units (or modified column headings) should be added. -> NO CHANGE: units are in .FMT. -> NO CHANGE o In the .fmt file, column 9, et al. descriptions should say that it is a low/high mass threshold, not just a low/high threshold. -> WILL CHANGE: will check and change, if needed. -> NO CHANGE: not sure that this request is justified. Current terminology is consistent with descriptions provided elsewhere in the data set. o .fmt file: Column 12 description says "low" where it should be "high" and "sensor 1" where it should be "sensor 2". -> WILL CHANGE: will check and change, if needed. -> DONE o fmt file: Columns 13-16, description should be reworded to refer to the lowest, second lowest, etc. - omitting the "large sensor threshold" terminology which is confusing. Propagate elsewhere in the file as appropriate. -> WILL CHANGE: will check and change, if needed. -> DONE o PVCF: Highest mass threshold of small area detector has zero counts. Is this a reasonable result given results on large area detector? Acoustic sensor - not clear whether cumulative counts or count rates. One bumper microphone drops way down - is this a reset? Is it saturation? Is it rollover? -> WILL CHANGE: .. at least will TRY. I'll refer this to T.Tuzzolino and T. Economou (Inst. Lead and his Deputy. ) I cannot predict if I'll receive anything from them. -> NOT RESOLVED YET: It seems that Simon Green has anwered this question in his e-mail from 06/14/05. Where in the data set should his answer be included (DATASET.CAT?) o Is there a temperature in the telemetry for the power supply? If so, put it in the table. -> NO CHANGE: This is not available, I checked. By the way, why is it needed? -> NO CHANGE o Documents say acoustic time resol = 1 sec and PVCF resol = 0.1 sec. What is the meaning of the millisec resolution in the table? -> WILL CHANGE: .. at least will TRY. I'll refer this to T.Tuzzolino and T. Economou (Inst. Lead and his Deputy. ) I cannot predict if I'll receive anything from them. -> NOT RESOLVED YET: I forgot to include this into the e-mail request that I sent to the instrument team. o Need good calibration data for impact sensors (density dependence, etc.). Provide guidance on which calibration to use and how much uncertainty there is in the calibration. (paper quoted uncertainty of factor 3!) -> WILL CHANGE: .. at least will TRY. I'll refer this to T.Tuzzolino and T. Economou (Inst. Lead and his Deputy. ) I cannot predict if I'll receive anything from them. -> NOT RESOLVED YET: It seems that Simon Green has anwered this question in his e-mail from 06/14/05. Where in the data set should his answer be included (DATASET.CAT?) *.lbl o I thought the HEADER_TYPE for CSV tables was going to be "COLUMN_LABELS" or something like that. Is "CSV" the right terminology? (Isn't that a table type that may or may not have a header?) -> WILL CHANGE: I don't know CSV doesn't sound right but I could change it to COLUMN_LABELS or TEXT if it's important. -> NO CHANGE o Column headings - clarify high and low what (and fix wrong ones). -> WILL CHANGE: will check and change, if needed. -> NO CHANGE: column headings correspond to the column names in the FMT file (not 1:1 match but close enough to understand). document/ --------- o The Small Sensor reported no impacts at the m4 threshold, but there is no mention of this in the documentation. The lack of results should be noted and explained. -> WILL CHANGE: .. at least will TRY. I'll refer this to T.Tuzzolino and T. Economou (Inst. Lead and his Deputy. ) I cannot predict if I'll receive anything from them. -> NOT RESOLVED YET: It seems that Simon Green has anwered this question in his e-mail from 06/14/05. Where in the data set should his answer be included (DATASET.CAT?) dfmical.asc and dfmical.pdf o Was this published someplace? If so, and assuming we have permission to reprint it, we should credit the publication in the label at least. If it was written for us (PDS), the label should contain a CITATION_DESC. o In tables 1 and 4, the "byte" references don't actually refer to the data file presented here, but rather the telemetry stream as it came down. This should be made clear. o The times recorded in the data file need some additional documentation. Specifically, we need to know the relationship between the reported time and the point of measurement. o Provide some additional explanation and guidance on how and when to apply the two different calibration constants. Add a discussion of the uncertainty in the calibration. o If the dfmical.pdf file is re-created, place the figures in-line if possible. o dfmical.asc: The word mirco is misspelled on line 24. o Should capture the figures in the pdf version and convert to png? Also copy the captions for the figures to the ascii version o Need to update reference to Tuzzolino paper -- change it to the 2003 reference in the REFERENCE.CAT file -> WILL CHANGE: I'll refer this to T.Tuzzolino and T. Economou (Inst. Lead and his Deputy. ) I cannot predict if I'll receive anything from them. I inherited .PDF and .ASC from Howard Taylor. They came with prototype DFMI volume. I have never seen this doc in other format, e.g. .doc. So, as I said I'll refer it to the instrument team and see what happens. -> NOT RESOLVED YET: Reply from Simon Green (e-mail from 06/14/05) covered some of the items in this list but since he did not have the document in question at that time what he provided was not complete. I don't know if Ludmilla forwarded document to him and he provided more feedback. Also, since I did not get any reply from T. Tuzzolino and, I believe that he was the one who provided the document to Howard Taylor for inclusion in to the first archive (SDDFMI_0001), it's highly unlikele that we will get this document in .doc or any other "editable" format. In this case, I guess, any reply we will get from Simon will have to go to DATASET.CAT or ERRATA.TXT. index/*lbl ---------- o Need formats on each entry. -> WILL CHANGE -> DONE ========================================================================== E-mail from Simon Green addressing some of the liens. ---------- Forwarded message ---------- Date: Tue, 14 Jun 2005 14:40:51 +0100 From: S.F.Green To: Ludmilla Kolokolova Cc: tony , Thanasis Economou Subject: RE: Stardust DFMI data Dear Ludmilla, Yes I do remember you. Sorry for the delay in replying, I was on holiday for the last two weeks. I have not been involved in the preparation of the PDS files (it was the responsibility of the PI institute and I believe Tom Economou prepared them) so I am not sure of the required formats or content but I'll try and help. I know that Tom is very busy with Mars mission work, and Tony McDonnell is now retired (although he is still active in dust research). I have worked on the acoustic sensor data so am confident about its operation. I am not so sure I can help with the details of the PVDF sensors, but I'll try. I don't have the attachment about calibration that is referred to in Boris' e-mail - could you forward it to me as it may help in answering some of the questions: o In the Acoustic Sensor values, particularly the high & low bumpers, the values around close approach do not seem reasonable - the "cumulative count" increases and decreases a number of times, but there is no documented instrument problem or rollover that might explain this. An explanation is needed. The acoustic sensor counters worked in a completely different way from the PVDF sensors (which were real event counters). Moreover, they were not impact counters. They counted the number of time intervals that the signal from the sensor exceeded a certain threshold. This meant that a large impact would produce a large number of counts and a small one a small number. Since the count rate was generally expected to be very low, the possibility of confusion (i.e. not knowing if the number of counts was due to one, two or more actual impacts) was not expected to be a major problem. The strength of this approach was that an indication of the mass of particles could be obtained even when the peak signal from the sensor saturated the instrument. The disadvantage was the possibility of multiple impacts in a counting period (0.1 to 1 sec depending on PVDF trigger) and the possibility of multiple counter overflow. As the acoustic subsystem was a last minute addition after the data rates had already been fixed, the counters had a full range of only 0 to 255. This explains the steps in the counts. The counters start at zero and increment each time there is an impact. Several times during the encounter (9 I think), the counters overflow. From my statistical analysis I am convinced that there are no multiple overflows (i.e. counts greater than 256 within a time interval). All this, combined with the fact that the readouts are only performed when the PVDF trigger has been activated, means that the data interpretation are a little tricky. The best place to get a detailed and I hope clear explanation of this is in our JGR results paper (see Journal Geophysical Research, 109, E12S04, 2004; PDF attached), which also contains the latest on the calibration of the acoustic sensors (I contributed a section to the original instrument paper which was excluded, but that's another story...). To convert the counts to impacts requires detailed examination of the timing of triggers, the counts received in each channel and the signals in preceding and following time intervals. I am not sure that Tom had enough information on all the intricacies involved so I suspect that your data do not contain any information on how this was done. o PVCF: Highest mass threshold of small area detector has zero counts. Is this a reasonable result given results on large area detector? Acoustic sensor - not clear whether cumulative counts or count rates. One bumper microphone drops way down - is this a reset? Is it saturation? Is it rollover? The area of the PVDF small area detector was such that the probability of an impact triggering the highest threshold was very small. The same is true of the PVDF large sensor which has a larger area but higher mass thresholds. This was part of the reason why the acosutic sensor was introduced. Although it is less sensitive (and more difficult to interpret) the large effective area meant the probability of an impact at any given mass was higher. I have looked at the derived fluxes and the upper limits from the PVDF sensors are entirely consistent with the acoustic data when converted to impacts. I hope the paper makes clear that Acosutic data are cumulative counts but are emphatically not numbers of impacts. I can provide a file with the number of impacts in each time interval that I have derived from these data if required - it will not be definitive since there is a degree of statistical interpretation involved). o Need good calibration data for impact sensors (density dependence, etc.). Provide guidance on which calibration to use and how much uncertainty there is in the calibration. (paper quoted uncertainty of factor 3!) As I don't have the document I can't answer this right now. The only thing I can say is that we cannot supply "good" calibration data for the acosutic sensors since it doesn't exist - for the very simple reason that there is no mechanism for obtaining it in the lab (limit of light gas gun capabilities and availability of targets which are destroyed with each test). A factor of 3 might sound bas to you but for anyone used to these types of sensors it is quite normal. For the acoustic sensors the inherent uncertainty in impact position introduces a large uncertainty in the derived impactor mass. Again, I hope this is clear from the paper. o The Small Sensor reported no impacts at the m4 threshold, but there is no mention of this in the documentation. The lack of results should be noted and explained. No impacts detected simply means a flux below the threshold (see above). o Was this [calibration document provided with the archive] published someplace? If so, and assuming we have permission to reprint it, we should credit the publication in the label at least. If it was written for us (PDS), the label should contain a CITATION_DESC. I need to see the paper, but I'm not sure of the source of the PVDF calibration data. o The times recorded in the data file need some additional documentation. Specifically, we need to know the relationship between the reported time and the point of measurement. I have some conversions from various time standards but don't know how they relate to what you have. Nominal encounter time of 2004 Jan 2nd 19h 21m 32s UTC corresponds to S/C time of 757538732.6 and DFMI time between 813 and 814. o Provide some additional explanation and guidance on how and when to apply the two different calibration constants. Add a discussion of the uncertainty in the calibration. Need to see the file to comment. I hope this is of some help for the moment. I will be around this week but am then away on research visits/vacation for several weeks. regards Simon