September 2019 Rosetta Review Notes Day 1 (9/3/19) American Reviewers OSIRIS Reviewer: Jian-Yang Li Reviewed level 4+ data, not previous (l3) data. Did not try to do calibration pipeline. Catalog and Documentation - Need to specify in ds.cat that "reflectance units" is radiance factor, or I/F. Need to be specific about what reflectance unit is in use. - Editorial problems submitted as RIDs Images - Not a problem, but FITS files do not have quality flag map or sigma map whereas IMG files do. - FITS files are saved in native readout order and are not in the correct orientation when displayed in DS9 following the default FITS display orientation (but that's FITS, not PDS). - Vertical line appears in some in-field stray light images when L4e subtracted from corresponding L4c. All in the same location, different brightness, but not every image. No description in the document. Quality map gives bad data but offset slightly (one pixel) from the line. Team: We changed corrections between CODMAC levels, so this is a problem of the previous dataset. We will describe this in the documentation. - Thumbnail images in browse directory are not in "standard orientation" for NAC and WAC datasets, off by 180 deg rotation. Tilden: This is explained in browseinfo.txt. Team: The JPGs match the "rosetta orientation," which is different from standard PDS keywords. Jian-Yang: Okay, missed that definition. Not a lien! Geometry Used spice data to verify geometry parameters in images, with small differences, max < 10 ms. - Need to remove all thumbs.db files in the document directory. Certification: Yes RSI Reviewer: David Hollibaugh-Baker Catalog Files - ds.cat - Some inconsistencies w/ data files. ds gives filename convention as rggttttlll_sss_yydddhhmm_qq.eee, but lvl2 data are missing a 0 based on this. l02, not l2. - lvl 2 data grouped into 3 directories, bsr, ptl, tml. ds.cat does not describe diff between them or what the directory names mean. - ds.cat suggests there should be lvl 2 dps, dpx, srg, or bistatic radar surface reflectance geom files, but not included. Are they missing or just hidden? - For example, r14r2a3l1a_rsr_142712215_02.dat has a data source identifier of 'r2a3', meaning RSR block 2A, subchannel 3, open loop. A meaningful description of what this means was not found in dataset.cat or TNF_SIS.TXT; or, if it does exist then it is not easily found. This is important for understanding the differences in the data products and their meaning. Further, Level 2 filenames have data source identifiers of 'R1Az', etc, but the dataset.cat document (File naming convention section) suggests that these are only for Level 1A and Level 1B data, and are not listed under Level 2. explained in labels, but not well in ds.cat. Takes too long to figure out. Document Files - Sometimes difficult to identify appropriate documents for bistatic radar doc. - dsn_doc/rose_bsr_20140928_d14.pdf seems important but not in docinfo.cat or referenced in any of the level 2 labels or data descriptions. - Data Filenames have 2A and 2A; should these columns be renamed 2A and 2B in doc file? - Discrepancies in dsn_doc: spelled out in presentation Calib Files - Level 1a data, labels have undefined record_type. calinfo suggests they should be ascii. ok? Tilden: in some cases, yes. Browse Files - In all files, label files state that lower right panels of images should have a particular feature, but it's blank. Data - lvl2 file names missing 'r' at start of name per ds.cat - lvl2 products have UDR product_type, when they should probably be "RDR" since data have been reduced through calibration. Tilden: Team concurs. - bsr data: are values across sub-channels supposed to be identical? Ask team tomorrow. Gerbs: Are they non-0?. David: yes. - bsr: need to describe difference between _00 and _01 files in labels. Thinks it's sampling rate. - lvl2 ptl, tml: are these power spectra data missing from lvl2? or derived from lvl 1a dsn files? - lvl2 tml: 1 file had ellipsis as a separator between start and stop time. 14r1b3l2_tml_142712215_00 - Did not see data as outlined in table 7-10. bsr data in lvl2 directory only contain time and power. Where is the rest of the data for the power spectra (power vs freq)? - No data in following directory: RORSI_4003_2014_284_V1.0/extras/ancillary/spice/spk Hard for novice to experiment or easily understand differences between level 2 products. Need consistency in documentation and improved direction to appropriate docs. Certification: looks good, but not until missing data cleared up. VIRTIS Reviewer: Adam McKay Reviewed lvl 5 maps of derived quantities: albedo, spectral slope, etc. (new) and lvl 3 previously reviewed. Able to reproduce albedo map w/ pds data matching published data Spectral Slopes - sl01 and sl03 should be the same, but have some kind of N/S flip, were produced using a (not described) "different algorithm" and are kind of different. similar issues w/ ba01*, bc02*, sl03*, sl04, wi01. Gerbs: Are the units different? Adam: Yes. sometimes /nm, sometimes, /micron Data Issues - BC01, BD01, SL01... some data files have random lines of 9 asterisks instead of data that could not be read in. similar issues on data issue page. No documentation if there's missing data or what have you, and they're not using the "missing constant" value. - image001.png (directory tree) needs to be higher resolution. - Inconsistencies in the docs noted in liens on eclipse - Albedo maps have many 0 values. Maybe shadowed area they can't measure, but seems unphysical to be 0 and not documented, and missing value is different. L3 Data - Same error as silvia's past review. readpds gives errors (that team says don't matter). But v_readpds (virtis) doesn't get them. - Mismatch between adjacent orders which is still an issue. Next order's beginning won't match previous order's ending. Team: stray light issue mentioned in docs, but not explicitly talked about for this mismatch. Should be spelled out. - Missing flux uncertainties. they're all 999.99, which is not useful. - Flagging off pointed data as coma. Either they didn't address, or there was no off-pointed data. - Other silvia errors resolved. Reviewer: Trent Hare Mostly a map review. Labels didn't have much "map like things" Tilden: Should there be map keywords? Trent: Optional. The way the team did it (as a table rather than raster) was fine. They could add map projection, but unnecessary. Not as friendly to use right out of the box. - Could read all data, view all tables, but there is still collusion (degenerate values). Certification: l5 not certified, a "work in progress." l3 depends on how they address these errors, okay as long as they're explicit in documents that the stray light problem connects to the mismatched orders. Must insert uncertainties, can't have rows of missing data. l3 not certified. RPC LAP Reviewer: Steve Joy All of the volumes share a large number of common files: cat files, docs, req files. most of these common files have been reviewed previously. Catalog Files - Some typos in rosetta_msn.cat, rosetta_insthost.cat - ds.cat files are sparse, but do point users to the critical docs that have the right info. Document rpc_user_guide - great document (now). _IES sections (not LAP) that are missing. - doc contains hyperlinks in ToC for example that are rotated 90 deg relative to page text (landscape vs. not?). No "back" button for inline links, have to scroll back. Anne: that's a software setting, not a problem with adobe generally or the files. Steve: Please show me! Index Files - browse_index.lbl - missing required keyword (index_type). Calib Files - These files list lots of calib files not in the individual volumes, which is not useful. Browse - Mismatch in the sign of i_pho_s and i_pho_60m values shown in the asw and pho data files and the values plotted in the corresponding browse plot. errors appears to be in the browse plot. probably off by a byte for a sign, indicating positive or negative charge of spacecraft. Flag in doc to say mismatch sign, that's okay. SRM Reviewer: Steve Joy Root Files - full_name in voldesc has a missing quote in full_name Catalog Files - lap (lap) has a different mission.cat name. They should be consistent. - Same typos in rosetta_msn and insthost.cat - ref.cat, consider removing consider removing [MOHAMMADZADEETAL2003] because it's not really about the instrument. - References disagree on energy response, should be made consistent. - insthost.cat is missing - instr_stream.cat (and other docs): same typo in energy range for channel s13: should be 542, not 532. - No instrument_Ref_info object for sandberg 2012 in these files, despite being in the reference text. - No discussion on the instrument mounting or the impact of spacecraft shielding. - Documentation is sparse, so lots of data taken from sandberg 2012, which is just about this common radiation monitoring instrument, not on rosetta. Not great doc for science dataset. 2012 states that srem model was supplemented with a mass model for the corresponding host spacecraft (integral). What is the mass model for rosetta and where is it described in the archive? (from Rudy Frahm) - ro-x-srem-2-ext3-mtp034-v1.0 – dataset.cat This catalog file “Data” description begins by stating: “One data product is provided per day of measurement”. It then goes on to describe two types of data tables, a count_rates_table and a standard_deviation_table. However, the description does not clarify that the two tables are provided sequentially in the one file. I wasted time looking for missing files when that data were all present. - Doesn't believe sandberg 2012 claim of 100 kHz detection rate and dead-time correction. Where is the discussion of downsampling? (from Rudy Frahm) Document eaicd_srem.pdf - doc does not discuss mounting description, FOV, channel response functions, dead-time, accumulation times, geom factor values and corrections, etc. doc should either describe the instrument calib, and include various eqns and param tables, or there should be a separate calibration doc with this info. It's not in sandberg 2012. sremdc_final_report - flowchart 4, describing data quality flags, does not show how an even can be assigned values of 2 (contaminated, do not use) in electron and proton channels. Update the figure or provide text to explain these values. Index Files - indxinfo.txt describes files not present in the volume. Calib Files - no directory on the l2 data volume and no files or docs provided. Previous reviewer (Frahm)'s liens still need to be corrected For most RIDs, team has either agreed to make requested changed or provided an explanation of the issue. Suggest that team update ds.cat ("important notes" section) to provide info to the science community. Just take RID response comments and put that in there. One issue not well addressed is data sampling (100 kHz, accumulation time, etc.). Can't get from counts to flux without knowing. Certification: not certified MUST Review (discussion) If the housekeeping data is only for navcam, strange that it's separated into its own thing instead of w/ navcam. Maybe if other instruments use this hk data. If this is real science, don't we need an external reviewer for it and not just internal tech review? Are we archiving? We won't sit on and "distribute" but not archive. We could "safe" it to the nssdca but no more then write a pdart to rescue it next year. Gerbs: this is supporting material that supports the science. Should be documentation if anything (if we want to archive it). Anne: No, because there are data tables. That hides the fact that it's data. Gerbs: Okay. safe it, send to nssdca. If used for science, needs full science review and we're not ready for that this time. Day 2 (9/4/19) Joint Review MUST Reviewer: Olivier Witasse Read user guide and eaicd Checked structure, browse images, and data 10 minor, 3 major RIDs, which have been addressed - Missing a browse plot from cruise phase - Missing rosetta user manual - In ds.ct, not much said about HK params - edac: missing information on reset, missing location of computers - Need to know location of temperature sensors, useful to assess behavior of spacecraft for other studies. - completeness. there are ~16000 hk parameters, but only a few included in the ds. discussion of what was selected? provide a way to access the rest (incl #). Larry: Chose the "key" ones. - Hard to open/handle binary files (vs. ASCII). Can there be both? Larry: Only certain sets are binary. Can do both where it is binary. Gerbs: What's the volume of binary files? Larry: ~GBs Anne: More than doubling because of characters and precision in ascii. 800 kb / file. total: 30 GB Gerbs: Looked at startracker. Can a user jump in and use it? Anne: Include separate directory w/ "original precision" of binary for users that want it. When thermal data put it, olivier will take a look. Anne: we'll have to check binary to ascii matching. Also we only have 1 external reviewer, which is a problem for presenting as a fully certified archive dataset. Larry: We assumed PDS would not want to archive because it's engineering data. Anne: That’s usually right because compressed telemetry is usually non-compliant (which we can just safe), but this data set is in simple ascii/binary formats. Because this is new, we do want it in the PDS, but don't want to set a bad precedent review-wise. Olivier: Huygens probe has archived HK data at atmospheres. Larry: When updated, get a pds external reviewer and have a telecon. Certification: (psa) yes OSIRIS Reviewer: Bjoern Grieger Reviewed 4 datasets, 2 from each camera. (NAC, WAC). User guide explains dataset name format Images - Tried to find smallest correlation between corrected and un-corrected for stray light image correction to see by eye what's going on. When looking at subtraction, there's a vertical line artifact, same as found by US reviewer. (Only applies to nac, not wac.) OSIRIS Team: Line does not originate w/ current dataset. Appears in an earlier dataset. Column 995 is a bad column, affects 994 and 996 too. Algorithm corrects the columns, but different algorithm used between datasets (newer is better), so the difference produces a line. Need to make sure same column correction algorithm used between datasets, then diff will remove. Header history explains there is an updated algorithm. Docs describe those algorithms. We can add description of config of pipeline to faq of sci user guide so users can see differences in pipeline and get it. They are flagged as bad pixels, so users must take care of course, but the newer correction is better. Jian-Yang: But quality map only covers 2 of the 3 bad columns (err, or a 1 pixel offset, but maybe my bad), and that's puzzling. If our subtraction is a common thing, users are going to find this line often, so it's important to point out that this is happening in the doc. Certification: yes, w/ resolution of RIDs. but no to the reflectance one. VIRTIS Reviewer: Frederic Schmidt - Problem of degradation of virtim_m_ir to be written: not in aareadme, not in docs VIRTIS Team: Not a degradation, just saturation of the detector. Should be a fixed number representing saturation. - 432 bands in virtis_m_ir so we need 432 wavelengths in the solar calib file. Still to be fixed. lvl 5 - Many products and MTPs are missing, for instance albedo at 55 nm only provided for mtp6,9. Team: Delivering only maps that have already been published. We're submitting another paper containing all the maps, will deliver those then. - If these are images, why ascii files? Team: lat and long not the best because comet is irregular. We'd rather use facet number (from the best shape models) in the future, then user can do any projection. ascii is flexible - Same 9 asterisk error. team: It's a variable format issue, can fix. - Trouble w/ eol character, so reading in gives wrong number of lines. - Proper description of the product is missing: units of albedo, def of spectral param. - Ambiguity between icarus and nature papers, lack of citation to ciarniello a&a 2015. team: sl03 (flipped) comes from the 2015 not referenced. Flipped latitude does need to be fixed and needs an inclusion in documentation. The file can't be flipped, but the representation can be. team: The 0 albedos should be explained or given a bad value value. team: For the mismatched orders, there is a better explanation in the new documentation. Adam: It's still an issue in the data, but if user knows what's up it's okay. team: For the missing uncertainties, it's hard to figure out because of various issues. so any s/n would be misleading before we're all done. team: For the off pointed data w/ coma target. Maybe we can do another keyword (not target itself) that can describe this, or maybe an index file Certification: lvl5 not certified, but delta review to check once asterisks are taken care of. Larry: lvl3 was just a "check w/ reviewers" review, not full or delta. Ludmilla: if you plan to add uncertainties, that's serious, needs review. Gerbs: why exclude uncertainty? Do systematic errors exceed stochastic? Then you need documentation stating so, specifically of the uncertainties (and they're missing). Larry: lvl3 same as lvl5. RPC-LAP Reviewer: Arnaud Masson - Previous rid, some efl files start w/ a leading spike of ~.5 V/m. Needs a fill value and a corresponding quality flag. this was partly but not entirely fixed. - Quality flags: improvement of description needed. eaicd description difficult to interpret. rpc-lap team: we have improved w/ more examples. Can't list all possible combinations of values. Tried to make text more pedagogical. - Special values mentioned in eaicd section 3.10 but not elsewhere in doc, so should be removed if not used. team: Special values are used for geometry. Larry: Please explain what they do. team: When we redeliver, the browse plots will be corrected. Their sign is wrong. Certification: lvl5, when RIDs corrected, we can certify w/ confirmation that changes made. SREM Reviewer: Elena Kronberg (discussion) SREM Team: For discussion of mission.cat references, the 2003 paper is for the instrument itself. new response functions have been derived since then, so more accurate stuff appears in 2012. Steve: If you're keeping both reference papers, make sure they're both in inst.cat, make sure it's clear where the numbers are coming from and what 2003 is doing. Team: We have more documents than have been currently presented. Wants to know what steve wants to see. Steve: We need to know the specific ways in which rosetta srem differs from the generic instrument. Anne: How will public get their hands on the sandberg paper? It's not in ADS. Could it be republished in the archive? Would prevent a lot of repeated information. Steve: Read the sandberg paper several times (and still had problems). Team: We should have a final report w/ more detail that is more distributable (instead of the sandberg paper). Team: (how get to 2m40s) instrument has a variable accumulation time. dead time is already included. Accumulation is time between successive measurements (delta t). Steve: Please, put something in ds.cat or eacid explaining the above. What does the timing mean? (Elena now) - Missing std dev for counts in data files. Please describe why there's no std dev for flux in eaicd doc. team: std dev is there, but unclear. redo format of ds.cat so that it's readable. - Calibration factors are missing or not described. team: Not calibrated w/ simple geometric factors. It's described in sandberg paper. New solving in each point. There are no simple calib factors. Elena: Please describe why calib factors are not present in docs. Team: For cross calibration btwn integral and rosetta, they were only in the same environment during testing in proton beam at psi, so hard to know. Larry: well, put that in the docs. explain the limitations. - values of fluxes. diff of 2 orders of mag when compared to other srem insts for similar energy values. Ludmilla: Steve mentioned no one knows where the instrument is mounted. team: Yes, we'll insert the doc describing that. Certification: Delta review needed b/c data changing w/ updated docs. RSI Reviewer: Roberto Orosei - Browse plots. Histograms between old and new version are different in a way that needs explanation. There are other changes, too, but data is not actually different. (no actual rids) Larry: Since you had to spend time figuring out that channels were mixed up and other things you have to spend time figuring out is not what users should need to do, so that's a problem. There needs to be a flag in the docs explaining all that. RSI Team: agreed - A little more text in the labels would spare the user a lot of trouble in trying to determine what the data content is. There are similar seeming plots that look different for reasons that aren't clear. (Overall signal power looks different from the separate channels that make it up.) - Not much done to enhance descriptions in docinfo.txt. - Info on how data produced still difficult to navigate for non-experts because of large num of docs. David: issue w/ lvl 2 bsr. Is this a data problem actually? Gerbs: Are the power spectra data missing from lvl 2? Certification: certified w/ liens fixed Earth-based, US Review Imaging Reviewer: Tony Farnham 2 datasets (lvl2 and 3), but each one has 27 individual observatories, so actually many more. Catalog Files - Minimal, but OK - Some grammar issues and typos (submitted as RIDs) Documents - PDFs are relevant to data listed. Issues with the observatory. Some useful, others not. (But not fully reviewed every one.) Raw Data - Separated into raw data and calibration images. Calibrated - Just flat-fielded, bias-subtracted, not technically calibrated (absolute flux units or physical units). Tilden: Is that documented? Tony: They do talk about what was done. not one-to-one correspondence between raw and calibrated. - image labels are minimal, but standardized, including some geom numbers (spot checked w/ no problems). - Usually, readpds yes iff nasaview yes - Caught some (but probably not all) bad images, because there are so many. Did basic comparisons between different programs to be sure data read correctly. - Pixel values sometimes differ between fits and pds and usually the difference related to 32768 or 65535 (problem between signed and unsigned integers). Not always clear which version is correct. FITS header sometimes has keyword bzero = 32768. In that case, need a corresponding offset/scaling keyword in the pds label. - In pds label, pointers to fits extension starting points are sometimes not correct, usually when there are multiple extensions. - Some flat fields are bad. Team: Tried to talk to PIs, will probably just remove if it's bad data and not just corrupted that has a good version somewhere. - All NOT ALFOSC data files are unreadable in pdsread. missing the line_samples keyword. team: fixed. - pds label filename pointer points to wrong fits file. Maybe also pointing to extensions that don't exist. But it's inconsistent when this happens, unlike with maybe a copy error. team: fixed. - One corrupt fits file, also some bad images. Remove or replace bad images. Gerbs: bim images are binary masks. Tony: Should be documented. - fits extensions are usually not well described. need documents about what different extensions mean and how they relate. - Where do the docs/ref papers come from? Anne: Please provide a license. If not available, we can't use it. We have to acknowledge the license when we republish copyrighted work. Certification: No. Too many issues w/ pdsread not able to access data. Polarimetry Reviewer: Bill Sparks - There are observations in the polarimetry that are photometry or spectrometry. Anne: If the label identifies, we can create index files to differentiate. - (for hubble, in particular) at least 4 diff levels of lvl3 data depending on where in the pipeline. Does all that need to be there? - Mostly instrument docs, generally not sci papers. Can we have obs logs? - label files with errors that prevent reading, missing line_samples keyword, for example. - readpds input requires .lbl, outputs/overwrites .fit? - consequence: can't use readpds to access all but WHT observatory stuff. Ensure compatibility, or improve doc if it's the reviewer's misuse of the software. - Absence of scientific info from the label file. Label files do not contain instrument config or type of polarization obs. lots of info in the fits, but then you have to probe the fits headers. Provide at least minimal instrument mode descriptions. BNAO (raw only) - fits and lbl files contain no info about instrument configuration regarding polarimetry. Unlikely (even w/ inst manuals) any useful sci info can be derived. Provide filter/wollaston/waveplate and relevant angle to enable a basic understanding. Team: PIs are unresponsive. HST - start_time in lbl wrong. team: fixed VLT - only acq(uisition) images provided at l3 for pmos spectroscopic data, but not at l2. team: fixed - hst isn't ground-based. makes searching hard. (discussion) Should we safe it because it requires specialists and funding to make ready archivable, and suggest that people get a pdart to work on it to be put into the archive. Gerbs wants anne to write up general considerations for safing this dataset. Certification: no Spectroscopy Reviewer: Lori Feaga - No target files, although they're referenced in aareadme.txt. Remove if they won't be there. - Index directory does not have index.tab and .lbl files. We have a tool that can generate them. - In index directory, indxinfo.txt files are empty. Need more complete files. We can produce text. - (just spec), vlt x-shooter user manual must be updated. version is oct 2011 - mar 2012. Replace w/ doc contemporary when data submitted. - observing_notes.txt contains info on observatory, PI, dataset. The notes column has a note that says "nothing to report." Of what value is that? Must differentiate between "nothing out of the ordinary" (nothing wrong) or observing team has nothing to report. clarify meaning and from whom. - TNG NICS is in obs_notes but has no data directory. Other empty ones still have the data directory even if just to say "data not provided yet." Please make consistent. - same bzero/bscale problem (for many sets) - same erroneously defined fits extensions in pds label making them unreadable. - *_sum data. how are the summed data created? pds lbl does not indicate which reduced raw data were summed to create. should be in lbl or auxiliary file. fits header contains history note of sum, but nothing described in the lbls. - (ifs) missing *.png files in document directory and the eaicd for lvl 3, but are present for lbl2. include them and describe in label. Certification: No Day 3 (9/5/19) Earth-based Joint Review Larry: What's important today is discussion of what can reasonably be done to get the data out there to the public. We don't want to get lost in the weeds discussing the many RIDs. Focus on aspects of scientific usability of data (as opposed to technical standards issues) and what can be done and what are the implications if something can't be done. Gerbs: Even if we can't certify, we can safe it. Spectroscopy Reviewer: Olivier Halnaut - vlt/sinfoni raw data not useful. Replace w/ pointer to eso archive. - tng/nics, too many calibs. Science data obtained only in lr/jk mode. calibs contain many other that could be pruned. - bta, mixed up bias. - tng/dolores, wrong info in fits headers. for example, not a halogen lamp being used, but some spectral lamp. messy calibrations, star files look like flats, f.e. team: PI retired, so there's not much we can do. - There are calib files in data directory for sprat/arc. Move raw to calib folder. Get rid of for reduced. - Spectroscopy datasets contain images that contain intrinsic value as images, so they should be there, but maybe stay in spectroscopy directory. Lori: Context is important, so those images should be kept in spectroscopy directory if they are contemporaneous w/the spec stuff. Slit images don't have much value in image directory. Larry: We're making a user's guide. Could be mentioned there that there's an image directory with the corresponding files from spectroscopy. - weird/wrong data. bad flats in irtf/cshel for example. Lori: Typically we keep even bad data but flag it w/ uncertainty or data confidence level, but won't have lvl3. If we're removing, indicate what was removed. Larry: Then we need a full list of bad files. Just have a file saying there are bad flats and be aware. Lori: Usually we have an obs log that a user can go to if they find bad images and see if there was a problem. - cancel RID for irtf/cshel missing arc lamps. but should be in imaging directory. - keck/hires, description of spectra format in headers is incomplete. Can maybe send this slide and ask what these numbers are. Larry: Good to tell PI if there's a pipeline issue. Lori: critical to get a definition for those values. - tng/nics missing manual. just gives link to pages. but pages are not stable. Nicolas: "nothing to report" rid is his language (nothing outstanding), not the PI saying there is in fact nothing there. french -> english translation issue. Nicolas: bzero/bscale issue - Tell me where in the label the keywords need to go and I can do this. Tilden: They have to go in the image object in the label file. Nicolas: Will add summed data history to a text file. Larry: Seems like with rids fixed, we can roll out. Just PDS rules issues. Tilden: In order to access data, the labels need to be correct. Larry: This is the end of the process. Further issues won't get fixed. Gerbs: Sure, but then we will safe it. NOT archive. Larry: Lori, are you happy w/ the science status of data? Lori: For people to use scientifically by everyone, important for the data to be accessible via PDS label. The data are important, but harder to judge the completeness of the data as a whole because of these missing or wrong stuff. Gerbs: If you don't have the correct label information, it's not discoverable in searches in PDS (and then it's not useful!). Olivier: Thinks data are usable even if not ideal. Certification: No, delta review Imaging/Polarimetry Reviewer: Rosita Kokotanekova - Calibrated data for some instruments not avail. PIs say it isn't there. Larry to Gerbs: For more data, we can wait until it's delivered. Tony: It's annoying to have to click through to directories and see there's no data there, uselessly mirroring the raw directory structure. A useful document would have observatory, contact info, etc. to get more info/data. Gerbs: Needs to be made clear when data are not available. - Missing biases for some data. Note should be added to use bias from nearest possible date but calibrations will not be ideal w/ higher noise levels. - Flats taken on different days but not noted. - Missing flats makes data unusable. Should be flagged to say it's only for qualitative analysis and point to similar other dates/instruments. Nicolas/Colin: Archived everything I have. All we can do is put a note for the user. - label files do not contain info on filters used for science data and flats. Info hard for user to find without diving into instrument docs. Info is in headers. Would require a lot of work. Nicolas: That would require a lot of time/effort. Larry: Is that true for all? Rosita: Most were taken in R band, but that's not specific enough. Colin: Even though it's in the fits header, it's encoded differently in different instruments, so hard to extract into a table. Tony: But this info is critical, so we're just putting that work on each user instead, making it hard to search on and use. Colin: But how many keywords/observing modes would we need? Bill: With polarimetry, have to grapple w/ waveplates, rotations, polarizers, etc. Can solve to 70-80% lvl pretty easily w/ a few keywords. Gerbs: We need to be aware of when the marginal improvement reaches 0, but there are simple checks/reinforcements we can do before we get there. Colin: At least a filter one we can/should do. But don't we want consistent labels? Tilden: We want the same label across data type, not the whole dataset. Anne: Uniform labels across disparate datasets loses you info. We've got heterogenous data; we don't want to increase opportunities for confusion. Different labels are fine. - experienced observer won't have much trouble using data. Larry: Can we document what the extensions (Tony's RID) mean? Colin: Yes. Colin: Acquisition images should all be in one place. Bill: But in imaging polarimetry, it's very useful for deriving things. Can be used to increase s/n. Not really an acq image. But only 3 for hst. Gerbs: Are we aiming to make searchable or aiming to include all relevant parameters? Anne: We don't have the relevant keywords in PDS3 to do that. (migration!) Are there polarimetry keywords in PDS3? Will talk to local scientists. PDS3 had keywords for instruments that took the data, not the data itself. Had to look for a polarimeter. Colin: If there are no obs logs, they might not exist. Or they're in Bulgarian. Certification: No, delta review required. Anne: There should be a document in the dataset describing where it came from, how it formed, the work put into it. We don't want to give people the impression these datasets were just thrown together. They should understand the complexity of the effort. PDS must provide the PDS3 keywords that exist that are relevant and useful to be translated to from the fits header keywords.