Changes between Version 46 and Version 47 of Sa10Problems
- Timestamp:
- Dec 12, 2012, 11:41:06 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Sa10Problems
v46 v47 43 43 * a. We don't use this flag (so then why is it there?) 44 44 * A2: 12% have ra_err > 0.1 deg (same for dec_err), and 70% have ra_err = 0 (same for dec_err) 45 * a. F Or the 12% that have raerr > 0.1, the majority come from (ng+nr+ni+nz+ny) = 0 or only a few suspect the calculation is goofy because there are few points to calculate raerr. '''(GENE??)'''45 * a. For the 12% that have raerr > 0.1, the majority come from (ng+nr+ni+nz+ny) = 0 or only a few suspect the calculation is goofy because there are few points to calculate raerr. '''(GENE??)''' '''gene notes that ra/dec err are in units of arcsecs, and he notices that pretty much everything is within 1 arcsec. ''' 46 46 * a. For the 70% that have ra = 0, I did a count(*) and grouped by objInfoFlag. I repeated this for raerr!=0. Here's what I find: if 0x00090000 (avg position used and fitted) is not set, it has raErr = 0 (this is the majority of things). If 0x0040000 (mean astro could not be measured) is set, may fall into either, with a preference for raerr!=0. why do so many not have 0x00090000? are those entirely the stacks? the majority of those have a detection in a filter (for the raErr=0, and flag = 4194304). If I do a similar query but without the restriction on flags (same raerr = 0), I find a whopping majority have NO ng/nr/ni/nz/ny, ie, they are stacks. 47 47 * '''We need to make it very clear that raErr / decErr is calculated from an average of single frame detections, and may not be present at all when it is a stack with no or few single frame detetctions ''' 48 48 * '''EAM update : if we only have stack measurements, and they are forced to match a single input (ie, y-band), all ra/dec values will be identical (because the skycells have the same astrometry and the matched detections use the coordinate of the referring source), thus the stdev will be 0.0.''' 49 49 * A3: 0.1% have ndetections = -999 (one specific patch in ra & dec) 50 * a. This is due to a failed batch (outside of PSPS's ra/dec range) I thought it had been fixed (conrad ?)50 * a. This is due to a failed batch (outside of PSPS's ra/dec range) I thought it had been fixed (conrad fixed it for the future) 51 51 * A4: ndetections still not equal the sum of ng+nr+ni+nz+ny : far from it actually. ndetections >= 2xsum (and =2xsum for 97%) 52 52 * a. '''This is a bug in the code, Heather knows where and how to fix''' … … 57 57 * A7: General magnitudes comments: (GENE?) 58 58 * 1. gMeanPSFMag - gStackPSFMag is bimodal: two peaks one at -0.03 and one at 0.12 (clearly separated) and not really the case for other bands 59 * a. 59 * a. '''gene needs to address - likely not for SAS or ingest of LAP this time''' 60 60 * 2. ?MeanKronMag & ?MeanKronMagerr: they span a ridiculous range (which is not the case for ?MeanPSFMag and ?MeanPSFMagerr, hence the reason to flag it) 61 61 * a. '''EAM : in DVO, the mean kron mag range is not strange''' 62 62 * b. '''EAM : in DVO, the mean kron mag error is apparently not set (all values NAN) -- not calculated?''' 63 * c. ''' HAF: meankronmag is set properly in SA11. there are a handful (order of 100) that have ridiculous range.'''' 63 64 * 3. ?StackPSFmagerr: covers an even more ridiculous range (- 1E59 to +1E59) 64 65 * a. '''EAM : in the DVO, I find a small fraction of objects with (eg) gStackPSFfluxerr / gStackPSFflux > 0.5 (48 / 200k in my test). of these, a handful have values > 5.0. looking in detail, I've found 2 cases (so far): … … 75 76 * a. we don't set it (should we? ) 76 77 * 4. x/yposerr: -999 to 17k while x/ypos 10 to 6.3k 77 * a. 78 * a. '''Gene to investigate''' 78 79 * 5. raerr & decerr: quantized in 0.25 steps + in silly units (not the same as xposerr)+ negative from time to time (not just -999) + range is huge (-8000 to 8000) 79 * a. 80 * a. '''gene to investigate - note that ra/dec err are in units of arcsecond ''' 80 81 * 6. apFluxerr: -999 (i.e. never set) 81 * a. 82 * a. '''noted before on previous SASs. not to be fixed yet''' 82 83 * 7. kronrad: min value ~5 : is this expected? 83 84 * a. WES: psphot calculates a minimum value for the kron radius as some function of measured image quality. So a minimum value is expected. 84 85 * 8. psfchisq: 1k to 5k typically.... peak at 2.8k: what's the meaning of that number 85 * a. 86 * a. '''Gene??"" 86 87 * 9. activeFlag: always 0 87 88 * a. we already know about it, if we don't use it can we drop it 88 89 * 10. assocDate: what does it correspond to 89 * a. 90 * a. '''Heather -seems to correspond (at least the day part) to when it got stuffed into psps. Conrad would know more...''' 90 91 * 11. historyModNum: always 0 91 92 * a. not used … … 99 100 * a. This is a known issue and not to be resolved yet (why?) WES: A proposal was made to fix the stackMeta.skycellID but there are PSPS validation issues that must be worked out and no one has had the time to investigate. I think it involves creating an init batch with every possible value of skycell id. 100 101 * B5. psflikelihood: why <0 for 10% of the stackdetections and -999 for ~25% of the stackdetections 101 * a. ? 102 * a. ? '''Gene???''' 102 103 * C. PSPS flags: 103 104 * C1. objectxflags: what does ID_SECF_HAS_STACK correspond to: forced photometry on the stack if set? Not clear why it should indicate whether there is a stack photometry as if there isn't any, then the corresponding photometry column should be set to -999 104 * a. ? 105 * a. ? '''Gene???''' 105 106 * D. PSI/PSPS suggestions: 106 107 * D1. It would be good if a small command could be defined for this expression int_ran = (ippobjid % 10) *1000 + ((objid / 10000) % 10)*100 + ((ippobjid / 10) % 10)*10 +(objid % 10) . The neat part of int_ran is that it runs from 0 to 9999 and is randomly distributed. It can be selected from nearly all tables directly in a repeatable fashion. int_ran is very quick to compute (barely increases the runtime of the query). Equally important (if not key), one can match tables which were selected on the same int_ran condition, making it far superior than any true random number associated with any table. The only flaw is that one cannot select any fraction smaller than 1/10000, i.e. 0.01%, but I believe this will rarely be of interest. … … 110 111 * More Issues: 111 112 * 1. Matching stackdetection and object: for a few objects matched on objid, they don't have the same ippobjid (<0.1%) [found this even on a 10% random sampling, because the random number uses ippobjid and objid] 112 * a. 113 * a. '''needs investigation.. Heather/Gene???''' 113 114 * 2. select * from Detectionflags order by value: query does not return the same flags as listed on PSPSflags_sas10 114 * a. this is on heather's list to be fixed 115 * a. this is on heather's list to be fixed 115 116 * 3. objectflags and stackdetectionflags tables are inexistent, i.e. one can not retrieve from the database the meaning of the flags. This should be contrasted with: select * from detectionflags for the detection table 116 117 * a. this is on heather's list to be fixed 117 * 4. Object table flags: 118 * 4. Object table flags: 118 119 {{{ 119 120 -1. If stackphotometry exist (xFlags & 0x20 !=0), why does xStackKronMag or xStackPSFMag == -999?
