Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the use of JointFitter (in astropy)? #190

Closed
els1 opened this issue Apr 6, 2022 · 5 comments
Closed

Implement the use of JointFitter (in astropy)? #190

els1 opened this issue Apr 6, 2022 · 5 comments
Labels

Comments

@els1
Copy link
Contributor

els1 commented Apr 6, 2022

input multiple spec with each their pack, information which parameters need to be the same in all spec. [https://docs.astropy.org/en/latest/modeling/jointfitter.html]

JD: "if using the joint fitter, we’ll be making more than one model for simul-fitting. I think this means we should create and keep a separate parameter table for all the input channels/segments/orders/whatever we call them." <-- Related to PR#165

Use AKARI + Spitzer as a test run ….

@els1 els1 added the fitting label Apr 6, 2022
@jdtsmith
Copy link
Contributor

This makes the JointFitter kind of problematic for PAHFIT at the moment:

The JointFitter uses the scipy.optimize.leastsq. In addition, it does not support fixed, bounded, or tied parameters at this time

But it's so much simpler to conceptualize than "figure out a way to blend your spectral segments".

@karllark
Copy link
Contributor

I am pretty sure the JointFitter can be enhanced to support fixed, bounded, and tied parameters. It has not been as fully developed as other fitters.

@jdtsmith
Copy link
Contributor

Yeah honestly it seems to me that it's none of the optimizer's business that we're re-using the same parameter in a few different parts of the model/segments of the data. So it was surprising to me that there are any such constraints. A dead-simple version of a joint fitter would be just concatenate all the x_0 ... x_i and y_0 ... y_i into a fake "concat spectrum", then pass some arguments to the model function such that it knows where the segments start/end, which parameters to re-use everywhere (most), and which are "custom" for a particular segment. So there'd be a few extra parameters for a given line, e.g. fwhm_0 ... fwhm_i would be pretty much all you'd need (for each line). With pre-bounding-box trimming you can ignore "far away lines" and cut this down alot, probably to just a pair of fwhm's for a handful of lines. With the area-based functions, power is a shared parameter. For continua and PAHs, it's basically then a no-op (assuming we can ignore the slight convolution of a PAH feature with the LSF).

@karllark
Copy link
Contributor

And this is what the JointFitter does for us. It just needs to get a little work to bring it up to the same standard as the LevMar fitter that is already there. I'm pretty sure there are even existing helper routines that can be used to do most of this work. This is even something I could try to do if it is a real priority for PAHFIT. And if we upgrade JointFitter, then everyone can get the benefit.

@jdtsmith
Copy link
Contributor

Closing in favor of #291.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants