Revamping the hydrostatic mass profile product

[DavidT3]

Work has already begun on this - it should be quite simple, I wish to revamp the HydrostaticMass profile class so that it reaches feature parity with the entropy profile class (which was reworked some months ago).

That means that you'll be able to create hydrostatic mass profiles from data points as well as fitted models, those data points can be interpolated if desired, and we'll also allow for projected temperature profiles to be passed as an approximation (we already allowed the projected temperature profiles to be fit with the temperature models if the user desires).

All these changes should make this class much more flexible and useful.

We'll also add some mass profile models to fit to the data driven hydrostatic mass profiles that will be possible (probably just simple NFW to begin with).

[DavidT3]

NOTE that now the actual mass data points in the profile will have the radius uncertainty included in them - the trouble is that the radius 'uncertainty' for the profile points is set by the width of the bins of the input profiles, and whether that is really an 'uncertainty' in this respect I don't know.

May have to revisit

[DavidT3]

Figuring out the right way to include the radius errors in data is doing my head in:

• For model based measurements it is fine, we'll do it the exact same way we already do in the existing HydrostaticMass class.
• For data based profiles without interpolation turned on, I don't know that I can really do include the radius error in the density/temperature realisations - maybe I can in the gradient calculations though?
• For data with interpolation turned on, I think it should be possible.
• When it comes to the actual final mass calculation, there is a radius term in the actual equation, so will always be able to have the radius errors accounted for.

But yes it is a bit of a bloody mess

[DavidT3]

Note to self - maybe force a refit of models to the temperature and density profiles (if the user goes that route) if the number of parameter samples and the number of samples specified on Hydrostatic mass profile declaration are not the same.

[DavidT3]

Initial attempt to include the radii distribution in the density interpolation mode has ended in a HUGE failure, as I killed the kernel. Suspect the current setup is attempting to interpolate 'num_samples'$\times$'num_samples'**$\times$**number of radii. Which I think might cause some issues...

[DavidT3]

I'm not actually sure I can include the radius distribution in the interpolation stage in the way I'm thinking - aaaargh

[DavidT3]

Same deal with the derivatives, don't really think that I can include radius uncertainty, or that it would actually be valid to

[astrophysics-megan]

I have suggestions for you. The radial bins aren’t errors so treating them as errors might lead to conceptual disconnect? Megan Sent from my iPhone On Nov 19, 2024, at 1:21 PM, David Turner ***@***.***> wrote:  Figuring out the right way to include the radius errors in data is doing my head in: * For model based measurements it is fine, we'll do it the exact same way we already do in the existing HydrostaticMass class. * For data based profiles without interpolation turned on, I don't know that I can really do include the radius error in the density/temperature realisations - maybe I can in the gradient calculations though? * For data with interpolation turned on, I think it should be possible. * When it comes to the actual final mass calculation, there is a radius term in the actual equation, so will always be able to have the radius errors accounted for. But yes it is a bit of a bloody mess — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/DavidT3/XGA/issues/1260*issuecomment-2486436872__;Iw!!HXCxUKc!28NzGVQYyO63ESX2ARQXf-LvrRPPkMRuK9WGW_dgemJ_E7qGgTj61buMhDa78I9Ez7AyRezqlOij_as5Y0GFgRy41Q$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ASKK4P4EBFTWX7G2FKF3SHL2BN6T7AVCNFSM6AAAAABSCQPH6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWGQZTMOBXGI__;!!HXCxUKc!28NzGVQYyO63ESX2ARQXf-LvrRPPkMRuK9WGW_dgemJ_E7qGgTj61buMhDa78I9Ez7AyRezqlOij_as5Y0GokncCdA$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[DavidT3]

For entropy and mass profiles, I will add a flag that allows them to contain unphysical values (i.e. negative masses) without erroring, though the default behaviour will still be to throw an error when it detects that.

[DavidT3]

May alter the checking process in BaseAggregateProfile, where it looks at the type of the Python instances to check whether a set of profiles should be allowed to be plotted together - this is an issue currently because I want to compare the old hydrostatic mass profile to the new, but also would cause issues if you wanted to easily plot gas mass and hydro mass profile on the same axis for the same cluster (for instance). Should check that the units are compatible to plot on the same axis, rather than the absolute type of the class.

[DavidT3]

Things are beginning to work in principle:

This is the comparison of the previous (orange) calculation and the new class calculation (blue) of hydrostatic mass from SMOOTH MODELS. So they should be identical, the only difference should be the radii at which they are sampled.

Maybe better illustrated by the 'joined points' plotting mode:

[DavidT3]

Now for interpolating from data points, again comparing to the original measurement from the smooth models:

Same plot but 'joined points' plotting mode:

Broadly similar, which makes me more confident that the numerical differentiation is doing broadly what I thought it was (the documentation wasn't completely clear whether it wanted some coordinate analogue (i.e. radius - this is what I tried here) for the points, or if it wanted the separations between points (I think I'll try that as well to be safe).

Obviously the data-pointed derived profile is not as smooth, which was always going to happen - I do wonder however if there is a better way to handle interpolation, especially for the derivatives, I am currently interpolating the density/temperature AND THEN finding the gradient - I wonder if I should find the gradients of the original points and then interpolate that? That feels less valid somehow.

[DavidT3]

Not a good fit, but the fits do actually work as intended now:

[DavidT3]

New version of the mass calculation function cannot produce results for individual input radii when using anything but smooth model mode.

Actually in this vein check that the specific entropy class can produce individual values on demand.

[DavidT3]

Things are working now - I need to stop the user if they are trying to extrapolate with data points, that clearly won't work

[DavidT3]

Issue #1271 is sort of related to this and left outstanding, but I am happy with the state of the new mass class, and am closing this issue.