Changes between Version 5 and Version 6 of IPP_for_PS1/ppImageMemoryExplosion_201208
- Timestamp:
- Aug 14, 2012, 5:15:05 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
IPP_for_PS1/ppImageMemoryExplosion_201208
v5 v6 24 24 25 25 == How do the sources get large pixel images == 26 I traced through the code and found that the sources are getting allocated large pixel images in psphotKronIterate_Threaded. When the sum of pixels in the kron radius measurement == 0 the kron radius is set to NaN. Then it calculates the integration boundary and finds NaN. So it includes all pixels in the flux measurement. On the next kron iteration the code that is intended to avoid large raddii for small surface brightness objects calculates a huge allowed value. And since source->moments->Mrf is not finite it sets the window to the huge 27 value. 26 I traced through the code and found that the sources are getting allocated large pixel images in psphotKronIterate_Threaded. When the sum of pixels in the kron radius measurement == 0 the kron radius was getting set to NaN. Then it calculates the radius and finds NaN. So since r is never > NAN the sums includes all pixels in the flux measurement. 28 27 29 Basically it's a mess. 28 On the next kron iteration the code that is intended to avoid generating large radii for small surface brightness objects uses the huge flux to calculate a big radius. And since source->moments->Mrf is not finite it ends up using that causing the pixel images to become huge. 29 30 Basically it was a mess. 31 32 The fix is to only use the kron flux for the surface brightness cut if Mrf and the kron flux are both valid. 33 34 This has been implemented and integrated into ipp-20120802. 35 36 I also changed the code to leave the Mrf and kron flux values unchanged in the case where an invalid Mrf is measured. Maybe this will reduce the outliers in our kron radius measurements
