Closed Jammy2211 closed 5 years ago
I have set up a routine which outputs a model's .paramnames file. The paramnames file is a file which lists every model parameter and its latex label. It is set up using ClassMap. As shown in the test case, if a ClassMap comprises two models the paramnames file will look as follows:
0_profile_centre_0 $x$ 0_profile_centre_1 $y$ 0_profile_axis_ratio $q$ 0_profile_phi $\phi$ 1_mass_profile_centre0 $x{\mathrm{d}}$ 1_mass_profile_centre1 $y{\mathrm{d}}$ 1_mass_profile_kappas $\kappa{\mathrm{d}}$ 1_mass_profile_scaleradius $Rs{\mathrm{d}}$
The paramnames file is a default file used by MultiNest, for assigning parameter names and latex labelling axes.
This means there are two types of plots we will want after an analysis:
1) Plots which only require the paramnames file and therefore do not use the ClassMap routine to set up the mode in AuotLens. For example, plots of parameter confidences (1D and 2D). Therefore, I will begin by writing plotting routines for these files which are a separate layer from the ClassMap / Galaxy classes.
However, we may still want to tie these plots to ClassMap at some level, if say we wanted to plot just the confidences for a specific Galaxy, or a specific MassProfile over a set of images. It should be possible to call the routines I write above from the Galaxy class with specific inputs that give the desired behaviour (e.g. the MultiNest plotting routines could take specific parameter indexes which only the Galaxy classes 'knows' about).
2) Plots which require us to setup a model via ClassMap and run them through AutoLens. This includes anything which actually analyses the image (residuals, chi^2 image, source reconstructions, mass profiles, light profiles, etc.) and plots which arn't used in the analysis but are tied to the light or mass profile (e.g. surface density, potential, mass / luminosity integrals)/
To facilitate this, I've written routines which from the MultiNest output load a set of results (e.g. the best-fit model, most probable model, models corresponding to upper / lower error limits) and then use the ClassMap routine to set this up as a model. The model can then be passed through the normal AutoLens routines as per usual.
No longer an issue
As discussed in https://github.com/Jammy2211/PyAutoLens/issues/11 , we'll have bespoke analysis routines for computing light profiles / mass profiles during the lens analysis.
After an analysis is run, we want a lot of flexibility in how one can visualize the results For example, after we have a lens model, we may wish to plot the light profile of an individual component of a galaxy (e.g. LightProfile), all the light profiles of a galaxy (e.g. LightProfileCollection or Galaxy) or all the galaxies in the model (e.g. GalaxyCollection). The same is true of mass profiles.
Therefore, I suggest we include in all these classes plot routines which use an array of data to make the plot (you'd already started working on this, so I'll use the code that already exists). This code is different to that in the analysis routine, but we can tie them together via unit tests. To achieve this we need to do the following:
1) For light profiles, one should be able to retrieve either the light profile or the PSF convolved light profile.
However, the reality is the routines above won't handle the visualization of results after an analysis that is particularly computed, for the reasons below:
1) For a pixelized source reconstructions, this must run on the light-profile subtracted image, or the linear inversion will fit the lens galaxy light and look stupid. If there are multiple source-planes, the sources must be reconstructed simultaneously, information which again cannot be built into the Pixelization class.
2) When there are multiple galaxies, the light profile is computed not on the image coordinates but the coordinates already deflected by foreground galaxies. Equally, things like mass profiles should reflect the deflection angles of foreground deflections. Neither of these effects are reflected in the LightProfile or MassProfile class.
3) Some things we want to visualization are inherently tied to the analysis itself (e.g. the image, chi^2 map, residuals etc.). This includes a dependence on hyper-parameters.
Therefore, I suggest that we'll need a Visualization class, which takes the results of an analysis and computes all the quantities one could ever want to plot and stores them in memory, e.g.:
1) The light profile, surface density, deflection angles, potential etc. for every Galaxy, allowing one to plot what they look like after foreground lensing and in their true source plane.
2) All of the source reconstructions, as they look after the final analysis so including the complications above.
3) Everything else - the residuals, chi sq image, hyper-parameter associated images and so forth.
We could make a lot of flexible routines to allow one to do weird things that arn't necessarily obvious (e.g. subtracting specific components of a galaxy light profile from an image).
Input welcome, but I don't see a neater way to do this. It'd include all the parameter degeneracies images too.