BUGS.SASS_PSPC: bugs present in SASS products for the PSPC 3-FEB-93 =========================================================================== --------------------------------------------------------------------------- Count rate / MASOL (13-APR-92) --------------------------------------------------------------------------- first occurrence: SASS5_2 (9-AUG-91) (-->"SASS V5.1" (s. below)) fixed in : SASS5_6 (07-MAR-92) All the MASOL files produced in the time from 9-AUG-1991 (release PSPC5_2) till 7-MAR-1992 (when PSPC5_4 corrected for the bug) contain wrong rates ("CTS/SEC"). The reason is that the vignetting correction has been applied twice. The bug is contained in release PSPC5_2 from 9-AUG-1991 and PSPC5_3 from 14-NOV-1991. These PSPC releases are part of release SASS5_2,SASS5_3 , SASS5_4 and SASS5_5. Since there was an ambiguity in the determination of the SASS version at the same time (changing to get the version from a DCL symbol instead of getting it from a file that had manually to become updated lead to overwriting the correct version by an old value) the print output delivered to the user in some cases shows a wrong SASS version thus making trace back of the error harder. The ambiguity is contained in those outputs that are characterized as "SASS V5.1". The bug can easily be found by comparing the data from SOLST and MASOL: Check, that the following relation is true: CNT/SEC = MLCNT * VIGNET / EXPOSURE where CNT/SEC = "CNT/SEC" from MASOL MLCNT = "ML CNT" from SOLST VIGNET = "VIGNET" from MASOL EXPOSURE= "EXPOSURE" from MASOL If CNT/SEC in MASOL is accompagnied by a "^" then check CNT/SEC = MPCNT / EXPOSURE where CNT/SEC = "CNT/SEC" from MASOL MPCNT = "MP CNT" from SOLST EXPOSURE= "EXPOSURE" from MASOL ---------------------------------------------------------------------------- Extraction radius / MASOL 13-APR-1992 ---------------------------------------------------------------------------- first occurrence: SASS5_6 (07-MAR-92) fixed in : SASS5_7 (16-APR-92) Some of the MASOL files produced in the time from 7-MAR-1992 (release PSPC5_4 which is contained in SASS5_6) may contain wrong values for the extraction radius. It has been given in wrong units. This bug appears in the case that the programs SP and SO both have been run with the version of 7-MAR-1992 (exe creation data). In the case the processing started with SO using data that already were produced with the older version of SP the bug does not show up. The bug may be identified by a value of the extraction radius that is unacceptably high, i.e. it is wrong by a factor OMAS_PIXEL/IMAGE_PIXEL = 30 for pointing. Thus the wrong radius in MASOL has to be multiplied as NEW RADIUS = RADIUS * 1/30 There is a check possibility: either the radius is contained in SOLST, then this radius is correct, but: it is given in OMAS_PIXEL = [0.5 arcsec] --> multiply this radius by 0.5 and you get the entry that should be in MASOL (radius in [arcsec]) or there is no entry in SOLST for the radius --> then the radius in MASOL is the correct one. ---------------------------------------------------------------------------- MLLST + SOLLST: something wrong with the flux error ? 16-APR-1992 ---------------------------------------------------------------------------- first occurrence: SASS5_8 (16-APR-92) fixed in : SASS5_9 (1-AUG 1992) Beginning with PSPC5_5 release contained in SASS5_7 (CONF5_8) SOLST and MLLST show up some strange, however marginal feature. This feature occurs in the case that the counts and the likelihood are zero. In these cases sometimes the error in flux appears quite reasonable, sometimes it is unusually high. We have not yet any explanation. ---------------------------------------------------------------------------- ACCEPTED TIMES & MEAN LIFETIME on cover sheet 16-APR-1992 ---------------------------------------------------------------------------- first occurrence: SASS5_7 (07-MAR-92) The accepted times and the mean lifetime of the individual observation intervals are shown on the cover sheet. For some transition time , i.e. for all observation intervals that have been processed with former releases, the basic data for this information will not be available in the respective par.par. The column then will be left blank. ---------------------------------------------------------------------------- Difference between ACCEPTED TIME and EXPOSURE 16-APR-1992 ---------------------------------------------------------------------------- first occurrence: since begin of operation fixed in : (release after SASS5_8) 17.8.92: fixed in SASS5_10 (18-AUG-92) (release SASS5_9 only for test) In spite of several attempts to bring the Exposure Time in accordance with the Accepted Times, there are still cases, where the Accepted Time is bigger for non irrelevant amounts. There are pointing times where the aspect shows an error less than one arcsec, but the aspect solution drifts away from the nominal position by an appreciable amount. This has the consequence that not all aspects are noted in the aspect histogram and thus these times will not be counted in the exposure map. We plan to remedy the situation by implementing a window accepting only aspects that are not too far from the nominal position. The limiting distance depends on the aspect histogramm. ---------------------------------------------------------------------------- Sources disappearing for some times 16-APR-1992 ---------------------------------------------------------------------------- first occurrence: since begin of operation fixed (?) in : SASS5_4_8 (19-DEC-1991) Analyzing survey data it has been found that some source is present in all but one orbit. Detailed investigations revealed that the missing source photons appeared e.g. 4 degrees north. It seems that there may be times where the aspect solution drifts away whereas in reality the telescope stays looking at the nominal position leading to the effect described above. We are checking whether all these situations known up to now to us are characterized by an aspect error larger than 1 arcsec. Then the error should not occur since installation of SASS5_4_8 (19-DEC-1991) where times and data have been screened for aspect errors larger than one arcsec. ---------------------------------------------------------------------------- Not acceptable PSPC high voltage times in ACCEPTED TIMES 15_JUN-1992 ---------------------------------------------------------------------------- first occurrence: since detector change on 26-JAN-1991 fixed in : SASS5_8_7 (15-JUN-1992) Checks on the high voltage (HV) of the PSPC are done based on two informations. One is a flag about the HV being ON/OFF, the other one the HV value itself being nominal. The respective values are contained in the houskeeping frames at positions that are not a straightforward result of which detector is ON but depend on other parameters as well. It turned out that due to misinformation by the hardware people the respective SASS program checked for a wrong HV field. This led to the consequence that the HV value indeed remained unchecked. As a result data intervals appeared in the accepted time intervals where the HV was turned on, but the HV had not yet reached its nominal value thus leading to a wrong pulse height information. Typically the time between HV getting turned ON and the HV reaching its nominal value is about 18 sec. This effect thus will be of no great impact for most observations, but it will affect observations with several HV ON and OFF occuring. The effect may be seen in the housekeeping plots delivered to the users. The "HV ok/not ok." values give the result on the logically "anded" checks on HV ON/OFF and on the HV nominal value. The HV value itself ("PSPC HV") up till now shows a behaviour which is not synchronized with the HV ON/OFF values. Every time when HV is set ON a time span of 20 sec should be cut out of the accepted times. This bug has been removed with SASS release CONF5_8_7. From this date on the HV value shows a behaviour synchronized with the "HV ok/not ok." status flag. Note that due to some speciality in the housekeeping frame notation the HV OFF value appears at slightly more than 2800 volts. The following text was added on 14-July WHV (14-JUL-92) =============================================================================== Before release SASS5_8_7 the PSPC-HV strip plots showed considerable jitter because of the above mentioned incorrect parameter reading. After this bug has been fixed with SASS5_8_7 there is almost no jitter visible anymore. The high voltage is and was very stable and as a consequence the gain too. ---------------------------------------------------------------------------- Count rate/likelihood/extent/hardness ratios 17-AUG-1992 ---------------------------------------------------------------------------- first occurrence: at least since Dec. 90 fixed in : release SASS5_10 (PSPC5_6) (18-AUG 1992) The source extent was computed in each band with the correct source photons but with the background photons taken from the broad band. This bug showed up in too big and sometimes even negative likelihoods of extent. It will be corrected with release SASS5_10. The following results are obtained when comparing corrected and old data : 1) there are no more negative or very big extents, 2) the sizes are now reasonable 3) there are small differences in likelihood, but no differences in position 4) there may be differences in counts in bands 2 to 5 As concerns the consequences for data that already have been processed one can state the following facts: 1) count rate/likelihood/extent in MASOL are correct in the broad band, they may be uncorrect for the other bands 2) hardness ratios may be uncorrect if the likelihood of the source in one of the bands 2 to 5 was greater than the parameter SP_SNRE (currently=8), because only in this case an extent was computed. Two examples give an impression of the changes induced by the bug: old new(corrected) BAND 3 counts CNTML 15.80000 26.90000 error in flux ERF 7.800000 7.900000 extent EXT 1.500000 1.210000 likelihood of extent DEX -1.600000 0.5000000 BAND 3 CNTML 17.50000 16.70000 ERF 5.800000 5.300000 EXT 0.4100000 0.3000000 DEX -15.90000 0.0000000E+00 ---------------------------------------------------------------------------- gaussian 2(sigma**2) and vignetting correction 2-DEC-1992 ---------------------------------------------------------------------------- first occurrence: at least since Dec. 90 fixed in : release SASS6_2 (PSPC6_2) (2-DEC-1992) The same bug that has been reported for the count rate/likelihood/extent/ hardness ratios (see above, 17-AUG-1992), i.e. that the photons of the broad band have erraneously been used for the other energy bands too, applies also to the gaussian 2(sigma**2) of the Point Spread Function and vignetting correction of the single photons. Positions and all broad band results are correct, whereas the consequences of this bug for the other energy bands are difficult to estimate. ---------------------------------------------------------------------------- Bug in Kolmogorov-Smirnov test and light curves 1-FEB-1993 ---------------------------------------------------------------------------- first occurrence: S/C clock >= 2**24 sec = 16777216 sec i.e. 13-DEC-1990, rosat day 197 fixed in : release SASS6_2_15 (PSPC6_2_4) (1-FEB-1993) There has been some bug in the pspc program SV (source variability) which delivers erraneous results for the KGS-Test and the light curves for S/C clock times greater/equal than 2**24 = 16777216 sec. The bug makes the begin and the end of an accepted time interval to be wrongly computed, leading to a wrong rate of extracted photons and as a consequence to a wrong chi square and wrong kolmogorov-smirnov test results. The light curves may show overlapping accepted time intervals. The detected time variability or nonvariablity of some source may be wrong. The effect should become significant only for sequences with a lot of separate intervals of not accepted time and becomes more and more relevant with S/C clock time raising above 2**24sec. The maximal time error per accepted time interval is 2*(2**1-1) sec for times between 2**24 and 2**25 sec, 2*(2**2-1) sec between 2**25 and 2**26 sec, in general 2*(2**n-1) sec for times between 2**(24+n-1) and 2**(24+n). ---------------------------------------------------------------------------- Bug in SIMBAD cross-correlation list 3-FEB-1993 ---------------------------------------------------------------------------- first occurrence: release 6_0 (implementation of correlation list) fixed in : forthcoming pspc release (after PSPC6_2_4) If the declination of a ROSAT source contains zero degrees, zero arcminutes, or zero arcseconds, a negative value is assigned to the declination. As a consequence the ROSAT/SIMBAD source correlation list may give false results. The declination of the ROSAT position is written with a minus sign, and SIMBAD candidates are searched at the wrong place. ---------------------------------------------------------------------------- Bug in SIMBAD PLOT 4-FEB-1993 ---------------------------------------------------------------------------- first occurrence: since SIMBAD plot existed fixed in : forthcoming pspc release (after PSPC6_2_4) For all galaxies with dimensions available in the catalogue the diameter has been plot too big by a factor of two. It is only the plot which is affected by the bug. ---------------------------------------------------------------------------- Improved background counts, hardness ratios, spectral fits 22-MAR-1994 ---------------------------------------------------------------------------- done in : SASS7_1_0 (MAR-1994) Improvements have been incorporated concerning the calculation of background counts and spectral fits for sources (as calculated in the spectral buffer SPCBF and shown in the spectral plots). The sources affected by these improvements are either weak or have other sources nearby. Better hardness ratios are achieved for those sources where no maximum likelihood algorithm was run for the individual energy bands, i.e. sources with a "^" in SASS output DETSA.SEQ. ---------------------------------------------------------------------------- Wrong count rates from local and map detect 15-DEC-1997 ---------------------------------------------------------------------------- done in : SASS7_9_C (DEC-1997) Stefan Doebereiner found a bug in the pspc local (DL) and map detect (DM) algorithms. The bug has led to a too low count rate in the source ouput lists LSLST and MSLST. Whereas the signal to noise ratio (SNR) given by DL is correct the SNR of DM is wrong. Since it is the SNR which determines whether the source position is provided as input to the maximum likelihood algorithm there could be sources at the acceptance limit that have not been taken into account. Since the final count rates delivered to the user are calculated by the maximum likelihood algorithm there is no effect for the SASS output countrates as long as the maximum likelihood algorithm has been run, e.g. in the inner ring of 40' diameter. In those cases where the likelihood algorithm did not run, this bug has led to a lowering of the final countrate. Since the list of sources presented to the maximum likelihood algorithm is mixed up from DL and DM detections it may be speculated that the consequences of the wrong SNR as a threshold for the maximum likelihood algorithm are reduced. Indeed we know from our screening experience that the number of sources that escaped detection is negligible.