Add support for multiple runs of the same XSPEC model with different fit configurations

[DavidT3]

This should have been in a long time ago, and I swear I had an issue for this but I cannot find it, but currently the XSPEC fitting functions (and the storage of the results in files, and in XGA objects) have no way of knowing what the fit configuration was. Thus changing the fit configuration doesn't run a different fit, which is terrible.

For instance, say you wanted to fit an absorbed plasma emission model to a cluster, with metallicity frozen and with it not frozen, and compare how the results change - you could not do that right now without setting up two versions of the same source and telling it not to load fits on declaration.

The reason I've never done this is because it is complicated, and more importantly it will add another layer of complexity for the user accessing results, but it does need to be done.

[DavidT3]

The primary things that need doing are:

• The storage structures for results in source classes and spectrum classes will need to have an extra layer under 'model name', with a key based on the fit configuration. All methods that 'add fit results' to an object will have to be modified to accept and use such a key.
• Of course this means the key must be generated - this will be done internally in the fit functions and passed out through the xspec run decorator. It will be achieved through calling a function which takes the arguments/keyword arguments from the functions, filters out a defined (i.e. hard coded) set that we know will be common to all fit functions (src, radii, lum_en, etc.) and then assemble a key from everything that is left. There may also be a version of this function that can be applied to a fit function from outside (i.e. reading the function signature), as that will then be able to easily create the 'default key'.
• The fit scripts, and results files, will need to include the key in their names - otherwise things are gonna get overwritten, XGA may get confused, bad stuff all around. Unfortunately this may have the butterfly effect of making the file names too long for unix, in which case I'm going to need to add an inventory file like the product directories have.
• Finally the user is going to need to be able to retrieve the fit of their choice - if there is only one version of a model fit (whether it is default, or the configuration was altered from default) then all the get methods will return that single fit. This (I suspect) will be absolutely fine for most users, but in the case there are multiple configurations of a single model fit then the user is going to have to pass more information. I think they're either going to pass the key (which honestly is probably gonna be more use for internal XGA methods), or they can pass a dictionary of the parameters that they changed from default, which will then be used alongside the other, still default, parameters to assemble the right key (I think this is the friendliest I can make this process). That will probably necessitate writing a function that can construct default keys. I also suspect I'll need to link particular model names to particular fit functions (in a constant dictionary) in order for that to work.

No doubt there are many more details to work out, BUT HERE WE GO.

[DavidT3]

Will now need to add the same functionality to the Spectrum class - including for the storing of plotting information for the models and XSPEC versions of the spectra - also will change the view method. THEN I'll need to go back to the view methods of AnnularSpectra and change them also.

[DavidT3]

Not doing this yet, but the same process of using fit configuration keys will need to be applied to the fakeit simulations done using spectra - this is in essence issue #111

[DavidT3]

The view methods of AnnularSpectra are all a bit buggered - the view_annulus method has had the conversion process started, but I forgot that they are still very basic compared to the view method of Spectrum, and still can't plot anything if no fit has been done, which is daft. Maybe I'll just completely rewrite them later.

[DavidT3]

Settled on rewriting them later - will add a get_view method to Spectrum (if I haven't already done that, I can't remember), and make use of that for view_annulus.

[DavidT3]

Note-to-self - even though the XSPEC fit functions (or the ones in 'general' anyway) now generate and pass out fit_conf keys, I still need to incorporate that into the script and results file names. This will mean altering the '_write_xspec_script' function.

[DavidT3]

Now I've started down this path, I think the best option for running the cross arf fits would be to control it with an argument to the existing single_temp_apec_profile function, rather than having it in its own function as it is now.

That will necessitate some rewriting, but I just think it makes the most sense from the user point of view. I can also allow them to choose whether they want an initial run with the non-cross-arf implementation first (as always happens as it is currently configured) or whether they just want to jump right in and try to run the first fit with cross-arf.

[DavidT3]

Okay! The storing of multiple fits is working now, and retrieving the different results is working if you have the exact fit conf key. The main next thing to do is write something that the user can pass the parameters they changed to and have it construct the key by adding in the default stuff.

[DavidT3]

Also, I think I'm going to have to allow different sources to have different fit_conf keys when running something like single_temp_apec, because I do allow there to be different start temperatures for a set of sources.

[DavidT3]

I want a way of knowing which arguments to an XSPEC fit function matter in terms of the definition of the fit_conf storage key. Currently those arguments are just defined within each function - this was an okay place to start, but I a) want to be able to access that information outside of the fit functions (i.e. in the fit_conf_from_function function that I'm writing) and b) worry that at some point we'll forget to update the dictionaries that are manually setup in each function.

As such I think I will abstract all those dictionaries specifying what information to include in the fit conf keys to somewhere else, and they will include null entries for arguments to the functions that don't matter, and that way each function can check that no new argument has been added to the function signature that we haven't considered including in the fit conf storage keys

[DavidT3]

I have found myself in a bad circular import situation - this is because of the function I created to help users construct fit_conf keys by only passing the parameters they changed.

What has happened is that now BaseSource imports that function, which in turn imports all the XSPEC fitting functions, which has this huge long knock on effect because they import the BaseSource class, so it is circular at initial import time.

I've been trying the TYPE_CHECKING constant that can be imported from 'typing' which I've only just heard of, but actually I've just thought of a better solution, I can do a local import of the function which is causing the problems in BaseSource.

[DavidT3]

This seems to be sorted out now

[DavidT3]

So I think the reading in of XSPEC fits from disk (i.e. when they have been previously run, and are now stored in the inventory file) should now be essentially fully functional again - the new XSPEC-fit inventory reading method seems to be working well APART from when trying to load in cross-arf based annular spectrum fits, that doesn't seem to be functional again yet,