Hi,
I think I've found a bug in mfittrend in the version of kappa
(1.9-11) which was part of the lehuakona starlink release. It seems
that straight line fitting can give very wrong fits for certain map
regions in this release but works in the previous humu and, interestingly
the latest nanahope release. Details for reproduction are below.
This bug could potentially have serious repercussions for any NGLS
data reduced in the 9 month time period where lehuakona was the main
release. mfittrend is used multiple times in standard reductions and
we only happened to notice it when I tried rerunning a script on a
machine with lehuakona on it and found the final map to be
different from that generated on a humu machine.
I do not know if there is any platform dependence - the test machine
for the buggy lehuakona results was an Ubuntu Linux Hardy Heron machine.
Regards,
Jamie and Boon.
######################################################################
You can find the input .sdf file for the following here:
http://www-astro.physics.ox.ac.uk/~jxl/B_smooth.sdf
Input file : B_smooth.sdf
run:
mfittrend in=B_smooth axis=3 order=1 out=temp_02 auto mask=temp_mask2
method=global variance=false subtract=false 'clip=[1.5,2.5,2,3,5]'
then do:
stats temp_02
On humu (KAPPA version 1.8-9)
-------------------------------
Pixel statistics for the NDF structure
/Volumes/Users/tanb/My_Data/2009/Research_2009/zzz_ongoing/NGC/NGC3351_rework_t
est/temp_02
Title : <undefined>
NDF array analysed : DATA
Pixel sum : 727002
Pixel mean : 0.332604
Standard deviation : 0.558958
Minimum pixel value : -1.27967
At pixel : (-3, 11, 951)
Co-ordinate : (10:44:00.8, 11:43:21, 1189.861)
Maximum pixel value : 1.57673
At pixel : (4, -4, 951)
Co-ordinate : (10:43:55.8, 11:41:46, 1189.861)
Total number of pixels : 2185792
Number of pixels used : 2185792 (100.0%)
On lehuakona get (KAPPA version 1.9-11)
----------------------------------------
Pixel statistics for the NDF structure /home/jxl/temp/test_area/temp_02
Title : <undefined>
NDF array analysed : DATA
Pixel sum : 1.31314e+06
Pixel mean : 0.600759
Standard deviation : 1.99485
Minimum pixel value : -16.4671
At pixel : (0, 12, -952)
Co-ordinate : (10:43:59.5, 11:43:33, 379.9976)
Maximum pixel value : 29.2387
At pixel : (-4, 9, -952)
Co-ordinate : (10:44:01.1, 11:43:05, 379.9976)
Total number of pixels : 2185792
Number of pixels used : 2185792 (100.0%)
On Nanahope (Kappa version 1.10-10)
-----------------------------------
aslx2:~/temp/test_area_nanahope> stats temp_02.sdf
Pixel statistics for the NDF structure
/home/jxl/temp/test_area_nanahope/temp_02
Title : <undefined>
NDF array analysed : DATA
Pixel sum : 727002
Pixel mean : 0.332604
Standard deviation : 0.558958
Minimum pixel value : -1.27967
At pixel : (-3, 11, 951)
Co-ordinate : (10:44:00.8, 11:43:21, 1189.861)
Maximum pixel value : 1.57673
At pixel : (4, -4, 951)
Co-ordinate : (10:43:55.8, 11:41:46, 1189.861)
Total number of pixels : 2185792
Number of pixels used : 2185792 (100.0%)
########################################
If you use GAIA to look at the output file (temp_02.sdf), which is the linear
baseline fits for the B_smooth map, it is clear that the lehuakona version has
problems -- it looks as though in certain regions the fitted line is not a good
approximation to the data in the same region of the B_smooth map. It seems as
though the magnitude is much larger than it should be in these regions.
Interestingly these regions correspond to the maximal positive and minimal
negative areas of the original B_smooth map. Nanahope and Humu don't have these
problems and the fits looks more reasonable as far as I can tell in Gaia.
You can try dividing the temp_02 fits produced by humu (or nanahope)
and lehuakona and see that there are plenty of pixels that are very
far from 1.0....
|
