search

DavidT3 / XGA

X-ray: Generate and Analyse is a module designed to make the analysis of XMM observations simple and efficient. It provides an interface with SAS for the creation of XMM data products, as well as a way to easily perform fits (scalable for multiple observations) and retrieve information about an object, all within a Python package.
BSD 3-Clause "New" or "Revised" License
31 stars 3 forks source link

Definitely something wrong with temperature profile radii #872

Closed DavidT3 closed 2 years ago

DavidT3 commented 2 years ago

The radii that I'm retrieving from the AnnularSpectra instance that created the profile:

[Annulus Centres] - [ 0. 137.5137532 229.18958866 320.86542413 421.70884314 568.39017988 953.42868883] kpc [Inner & Outer Annular radii] - [ 0. 91.67583546 183.35167093 275.02750639 366.70334186 476.71434442 660.06601535 1246.79136232] kpc

ARE NOT THE SAME as those I retrieved from the temperature profile created from it: [Annulus Centres] - [ 0. 113.62522904 189.37538174 265.12553443 348.4507024 469.65094671 787.80158803] kpc [Inner & Outer Annular radii] - [ 0. 75.75015269 151.50030539 227.25045808 303.00061078 393.90079401 545.4010994 1030.20207665] kpc

Not yet sure why this is happening but I am concerned that this is effecting my model fits, I suspect this would become especially bad at larger radii, but shall have to do some digging to see whats causing this

DavidT3 commented 2 years ago

So, using SDSS-124 as a test case, I ran projected and deprojected temperature profile measurement with the same settings as the analysis where I noticed this issue. On the first run (prior to model fitting) there is nothing wrong and all the radii in the profiles (both projected and 3D) seem to have the values that they're meant to.

DavidT3 commented 2 years ago

Ran the simple_vikhlinin_temp fit, and again the radius values are as expected. Now I'll try re-starting the notebook and loading things back in

DavidT3 commented 2 years ago

Restarting and loading things back in didn't cause the issue, which I find quite surprising, I thought that was going to be what caused it. It may be that I struggle to replicate this issue.

The main differences I can think of are that I didn't create the temperature profiles through the mass calculation functions, and I have only created one mass profile whereas before I had at least attempted to make a few per cluster through the iteration thing

DavidT3 commented 2 years ago

I still don't know what has caused this, but I think including a check of radii when profiles have the a reference to the annular spectra stored in them is a good idea. Or failing that a check using the set_id to grab the annular spectra when the profile is being retrieved or something?

DavidT3 commented 2 years ago

The ratio of the correct annular spectra radii to the incorrect temperature profile radii is 1.2102396. It may well be a coincidence but the radii were generated out to 1.1 $R_{500}$ and 1.1*1.1 is 1.21.

So I wonder if my $R_{500}$s are getting expanded by the way I'm calling them for the iterative method, and thats why I can't reproduce it so far?

DavidT3 commented 2 years ago

Actually no that can't be write as the 'correct' radii are 1.21... times larger than the 'incorrect' one

DavidT3 commented 2 years ago

So the ratio of the overdensity calculated for SDSSRM-124 from the mass profile, to the init R500 is 1.1292411499717439.

That same ratio for another cluster that is loaded (SDSSRM-1018) in is 0.70618654, and the ratio of the annular spectra bounds to the temperature profile bounds is 0.707...

So is there some casual relationship here?

DavidT3 commented 2 years ago

There is also the possibility that the radii are a hangover from when I was messing around with iterating $R_{500}$ values, and things got changed.

DavidT3 commented 2 years ago

Still unsure what's going on, but I started my attempts to recreate it from scratch again (deleted all the files etc) with two clusters from the SDSSRM-XCS sample, SDSSRM-1018 and SDSSRM-124. The information in this comment is all from a single run, nothing has been loaded back in from disk:

Loaded them into a ClusterSample and then used the inv_abel_dens_onion_temp function to measure mass profiles. This was what I did for the measurements of temperature profile that led me to finding this bug in the first place. The following command was used:

inv_abel_dens_onion_temp(xcs_srcs, xcs_srcs.r500*1.1, 'double_beta', 'simple_vikhlinin_dens', 'simple_vikhlinin_temp', 
                                                'r500', temp_annulus_method='min_cnt', temp_min_cnt=Quantity(1500, 'ct'), 
                                                temp_use_combined=False)

So I wanted it to generate temperature and density profiles out to 1.1$R_{500}$, and using some prints I added while debugging I know that for SDSSRM-1018 the annulus algorithm decided on these annular bounds:

[ 0. , 21.74996923, 43.49993846, 65.2499077 , 287.09959387] arcsec or [0. 0.00604166 0.01208332 0.01812497 0.07974989] deg or [ 0. 75.75006084 151.50012167 227.25018254 999.90080316] kpc

Where SDSSRM-1018's initial $R_{500}$ is 902.2592310706574 kpc, so the outer radius makes sense as it is allowed to go slightly over the requested outer boundary and the ratio here is 1.11

Laying out the same information for SDSSRM-124:

[ 0. , 21.74999561, 43.49999121, 65.24998682, 86.99998242, 113.09997715, 156.59996836, 295.79994023] arcsec or [0. 0.00604167 0.01208333 0.018125 0.02416666 0.03141666 0.04349999 0.08216665] deg or [ 0. 91.67583549 183.35167093 275.02750641 366.70334186 476.71434443 660.06601536 1246.79136233] kpc

Where SDSSRM-124's initial $R_{500}$ is 1123.320736258806 kpc and as such the ratio is again 1.11.

So far, so good, my annulus deciding algorithm has evidently done what I asked of it. This information is then passed along to the single_temp_apec_profile function, which in turn passes the radii to spectrum_set first to generate the annular spectra for fitting. I will explore what goes on in these functions in another comment, next I will record the radii that the AnnularSpectra and temperature profile instances that are generated by these functions are aware of.

The AnnularSpectra instance that was created for SDSSRM-1018: image

has four annuli as we expect from the annulus boundary radii that the annulus algorithm decided upon, but when we grab the annulus boundary radii (using the proper_radii property of the annular spectra) we find

[ 0. 91.6757243 183.35144861 275.02717291 1210.11956081] kpc then I get the same information from the radii property, which should be the same but in degrees [0. 0.00604166 0.01208332 0.01812497 0.07974989] deg which converts to [ 0. 75.75008441 151.50016883 227.25012787 999.90083844] kpc

Essentially identical to the annuli we expected! So there's something going wrong with the kpc radii of the annular spectra.

I'll so this same check for SDSSRM-124: image

The output from proper_radii is: [ 0. 75.75015269 151.50030539 227.25045808 303.00061078 393.90079401 545.4010994 1030.20207665] kpc then getting the output from radii property Ann Spec boundaries [0. 0.00604167 0.01208333 0.018125 0.02416666 0.03141666 0.04349999 0.08216665] deg converted to kpc [ 0. 91.67590457 183.3516574 275.02756197 366.7033148 476.71433959 660.06599698 1246.79136136] kpc

Victory! Something is definitely going wrong with the setting of the AnnularSpectra proper radii, which in turn is propagating to the radii being passed to the temperature profile. You can see here for SDSS-1018, the radii that should represent the centre of annular bins (e.g. the last central radius should be (227.25018254 + 999.90080316)/2 = 613.575495 kpc from the original annular boundaries passed out by the binning algorithm):

[ 0. 137.51358646 229.18931076 742.57336686] kpc

and the same check for SDSSRM-124 (here the last central radius should be (660.06601536 + 1246.79136233)/2 = 953.428688845kpc from the original annular boundaries passed out by the binning algorithm):

[ 0. 113.62522904 189.37538174 265.12553443 348.4507024 469.65094671 787.80158803] kpc

So, this is a pretty exhaustive breakdown of what is going on with this bug, and this process has helped me figure out where to look for the problem.

DavidT3 commented 2 years ago

So what I think is happening is that the radii are being converted from degrees to kpc using the wrong cluster's convert_radius method. As such its using another cluster's redshift for the conversion. I'm thinking this because when I tried converting SDSSRM-1018's original annulus boundaries (from the annulus algorithm):

[0. 0.00604166 0.01208332 0.01812497 0.07974989] deg

to kpc using SDSSRM-124's convert_radius method, I get this result:

[0, 91.675753, 183.35151, 275.02711, 1210.1196]kpc

This is the same as the incorrect radii for SDSSRM-1018 in the comment above.

This is slightly concerning, as the only place I can see that happening is in the run.py chunk of XGA's SAS functionality (and then possibly in the part of BaseSource that reads existing files back in). Each AnnularSpectra, when assembled, should only be connected with the source object it was generated from, the fact that this is happening makes me wonder if products are being assigned to the incorrect source sometimes.

DavidT3 commented 2 years ago

I think it's because I wasn't updating the index of my source before I converted radii:

            ind = src_lookup[entry]

but only after when I was assigning the product to the source.

DavidT3 commented 2 years ago

Yup that was the problem... radii are now all correct

DavidT3 commented 2 years ago

The only place this issue existed was when the AnnularSpectra were created in run.py, though of course it propagated to profiles which were then saved and loaded back in. It doesn't exist in the re-loading of annular spectra from disk because that is performed within a source, so there is no chance of the wrong convert_radius method being used. This issue should now be corrected and I'm closing this issue.