Open entaylor opened 1 month ago
Hi @entaylor , indeed there is a lot of bookkeeping to do! It's so cool to see built out pipelines with the code :) I think there are a bunch of tricks that I could write out in a tutorial for sure. For example for any model you can do model.parameter_order
to grab a tuple with all the parameter names. Or even better, you can do model.parameters.vector_names()
to get a list of strings with the same length as model.parameters.vector_values()
which has all of the fitted values.
I had attempted to make a human readable automatic output at one point, this is the model.save()
yaml file. Ultimately, because there can be a lot of complexity in how models share parameters, and how one can make arbitrarily nested group model, I couldn't get a structure that was a really clean table like what I think you want.
Perhaps we can use this issue to discuss a format that AstroPhot could automatically output which would be useful for pipelines like what you are constructing. I have a few ideas for what could be done, which have advantages and drawbacks.
model.parameters.vector_names()
and model.parameters.vector_values()
to get a matched list of parameter names and values. But if you are fitting multiple of the same model, then the parameter names will be duplicated. So maybe I could add a function like model.parameters.vector_model_names()
so you can tell which model(s) that parameter points to.model.save_csv()
which dumps the data into a csv where each row is a model, and the columns are the model name, parameter value, parameter uncertainty. A challenge here is for parameters like center
which have multiple values, but I could just do like I do for vector_names
and convert the array into center:0
and center:1
. Then it would be a trivial matter for a user to rename the columns x
and y
or RA
and DEC
or anything else depending on their circumstance. Another challenge here is for different model types, if you have a bunch of stars and a sky model, then how does the csv handle that? I suspect I would just group models of the same type together and then have to make a new header row when I get to a different model type.I'm sure there are other options too. Let me know what you think!
Once again let me say that i am blown away by the power of this wonderful tool. So much fun.
I am currently working to build an image calibration pipeline, centred on astrophot modelling/photometry for stars. There are a few steps to the process: first i fit many stars separately and independent to assess their suitability for PSF modelling; then i fit an ensemble of 'good' stars with a single model to determine the PSF and to get the positions and fluxes to be used for astrometric and photometric calibration. Like i say: fun! : )
The hardest part of this with astrophot is actually tracking and extracting the results of the fits — which says a lot about how good astrophot is at what it is supposed to do! But still, it would be good to have some documentation or guidance and possibly even some extra functionality to help with record keeping.
I'm not sure that what i'm doing is particularly good or clever, but just to show the approach that i have gravitated towards:
In the first phase when i fit many stars separately and independently, here is what i do:
In the later phase, when i have the positions and fluxes of many stars fit with the same PSF, i have a different but equally awkward pattern:
I recognise that the pattern one should use is specific to use case, and that the point of astrophot is that it is structured to be applicable to many and varied situations. So actually conceiving of a unified scheme for 'just works' dumping of data into a table is probably a fool's errand. But it might make sense to have some facility to do some common/likely use cases like the ones above?
But regardless, it would be very helpful to have a tutorial notebook that includes some examples and/or guidance for best practice ways of constructing catalogues/tables of results from astrophot.