emsellem / pygme

PYthon Gaussian ModElling - python MGE tool
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

The ultimate goal for pygme #1

Open emsellem opened 9 years ago

emsellem commented 9 years ago

@wkerzendorf: read this

pygme should ultimately be an entry point to deal with Multi-Gaussian Expansion models (as in Emsellem et al. 1994). Namely deal with 1D, 2D and 3D Multi-Gaussian models.

A pygme (MGE) model should thus first include a set of Gaussians and their parameters. In that context, the two-dimensional (2D) Gaussians should be the reference: they are given in terms of e.g., cylindrical coordinates (R,z). Deprojection (given viewing angles) would provide the 3D associated Gaussians automatically (x, y, z axes). If the use changes the viewing angles, the 3D Gaussians should be automatically updated. The link between 1D and 2D Gaussians should be given via add-hoc functions: for example the user could specify a 1D model (w.r.t. spherical r coordinate) which would then translate into a 2D model (where the axis ratio would be 1, as for a spherically symmetric model).

To obtain a 2D pygme model, there may be different ways. For example: 1- to specify the model directly via its parameters. 2- fitting an image or given set of data with a 2D model (using the pygme fitter). 3- fitting a 1D model on some 1D profile and then transforming it (via associated routines) into a bona fide 2D pygme (MGE) model.

So the pygme models should include a number of associated functions (e.g., deprojection) and parameters (distance, mass, etc). Since the model will be passed on to dynamical modelling routines, it will get even more associated functions and parameters (hidden or not) useful to derive associated quantities (e.g., frequencies, combinations of basic parameters). All these parameters should be updated automatically when the user wish to change the basic 2D model.

Another important aspect is flexibility. We should be able to include a new Gaussian into a pygme model easily. We should also be able to remove a given Gaussian easily. Or add two models together (e.g., one representing the dark matter, and one the stars, plus one for the gas). Each of these should have associated "flags" (gas, stars, dark matter). And we should be able to work on a subset of Gaussians for these models (using the flags, or other selection).

Finally, efficiency. The parameters should be easily addressable and visible. For one specific Gaussian, or a subset of Gaussians. But also as "arrays" for example for the set of axis ratios or some combination of parameters from the Gaussians: this is critical as the calculation often involve addressing these arrays. Example: if I want to multiply all amplitudes by a certain factor. Or use a sum (over some Gaussians of the model) over a complex function of their input parameters.

In terms of implementations now, the question is:

wkerzendorf commented 9 years ago

Hi @embray, @emsellem is interested in using Astropy modeling for doing this project. I believe it would be a good fit, but can you have a quick look and point out any problems that you may see? thanks

embray commented 9 years ago

I agree astropy.modeling can already be used for a lot of this. Depending, you may still want to implement your own implementations of these models but that's not clear to me (there's no built-in Gaussian3D model yet, but there easily could be). Adding models together and selecting submodels to evaluate is a core feature of compound models. All the parameters of a model are stored in a numpy array, and provide efficient access. I think you should see what you can do with astropy.modeling first and where it does or doesn't meet your needs. Probably no reason to reinvent too many wheels here.

emsellem commented 9 years ago

Thanks @embray for the tip: this makes a lot of sense. Will start coding based on astropy modelling and see where this goes. I could easily switch to another class later on if needed/relevant.