Parameter Starting Point

[jdtsmith]

In addition to science pack components (positions, widths, etc. for all the features), the final fit is impacted by the starting position of the fit in the parameter space. In IDL PAHFIT, this starting point was crudely determined for each fitted spectrum:

• Stellar Blackbody: The stellar blackbody (T=5000K) was evaluated at the shortest wavelength (at least 5.25µm), and divided into the actual intensity being fitted at that wavelength. This sets the starting tau_star value.

• Thermal Dust Continuum: Each modify blackbody n I_nu is evaluated at it's maximum wavelength, and divided into the interpolated intensity at this wavelength. This sets the tau_dust_* parameters.

• Lines and Dust Emission Features (PAHs): The central intensity for all lines is set to 1/5th of the median (non-negative) intensity of the entire input spectrum.

• Attenuation/Silicate opacity: A constant tau_Si=0.1 was adopted.

These aren't necessarily optimal (especially estimating tau_Si and getting in the ballpark would be valuable to the fitter's performance and quality of its results).

But per-spectra starting point estimation increases the robustness of fits, and will make IDL PAHFIT comparable with classic pack for automated testing. This is important enough to live in its own module I think.

Since this affects the model to some degree, perhaps a science pack can optionally specify which "parameterStarter" it wants to utilize (with the default being like the above, but no doubt with improvements coming).

This likely needs to be part of the first release to be usable on archival spectra.

[karllark]

Shouldn't this be in the v2.0 release? As this is required to do the basic IDL vs python comparison. Good to keep the v2.1 release as just about AKARI I think.

[jdtsmith]

Reasonable. Probably should move the due date of 2.0 back.

On Jan 12, 2021, at 10:32 AM, Karl Gordon notifications@github.com wrote:

Shouldn't this be in the v2.0 release? As this is required to do the basic IDL vs python comparison. Good to keep the v2.1 release as just about AKARI I think.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/PAHFIT/pahfit/issues/82#issuecomment-758737103, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAW4NIHKWZ4UHXFF6CSHSLSZRTRBANCNFSM4V6JC5NA.

[jdtsmith]

Current "packs":

Instrument Pack: information about instrumental parameters, such as wavelength range and cutoff, line spread function (as a function of wavelength), etc.

Science Pack: Scientifically focused parameter setup, including constraints, total number of features, exploring the tradeoff between fit degeneracy and flexibility.

But just as important is the "starting point" of the fitter. For example, to be comparable to IDL PAHFIT, we should use a starting point guesser similar to it. But we will likely want to improve the staring point heuristics as well. Which means we either need a "pack" to specify them, or perhaps just a module/class implementing a common interface (akin to @ThomasSYLai's guess), so we can continue to make improvements but preserve old fitter behavior as well.

It's possible specifying which starting-point "guesser" to use should just be part of the Science Pack itself, but I haven't thought that through enough. Thoughts?

[ThomasSYLai]

This discussion may also be relevant to #88.

Like @karllark already pointed out, the scipack we're using now is in fact the combination of Instrument & Science Packs. So, would it be useful if we create a pack generator? The purpose of running this generator prior to fitting the spectrum is to create the pack file which will later be fed into the run_pahfit process. So, we can imagine something like:

run_packgen inst=['spitzer'] sci=['pdr'] or run_packgen inst=['akari', 'spitzer'] sci=['Exgal']

Aftering generating the input file -- packfile.ipac, one can use

run_pahfit datafile packfile.ipac

to get the fitting results.

Regarding the guess function, the first question we need to ask is whether this function should base merely on the shape of the spectrum or should contain scientific meanings. On one hand, guess should only handle the scaling of the spectrum and shouldn't be varied depending on science targets. On the other hand, it would be useful to change the starting points depending on our prior knowledge to the source. For example, if the input scipack for star-forming galaxies is 'Exgal_SF', tau_Si can set to be 0 as a starting point, but for obscured sources, say 'Exgal_obAGN', this value could be 2 instead. Personally, I kind of prefer that leaving guess as a module in base.py, which will only handle the scaling of the spectrum, and putting whatever knowledge we have to the objects in the scipack file. Any thoughts?

[karllark]

I like the pack generator idea.

As for the guess function, I agree for now in leaving it in code. We can always change our minds later. Maybe a way to indicate in the scipack that the starting point for a parameter should not be updated by guess would handle the case you mention.

[jdtsmith]

One subtly is how to treat regions of overlap between different instruments. Different people could make different choices for blending those spectra, so that in the overlap region, we couldn't predict which line spread function to use: instrument A, instrument B, or some blend between them.

One possibility is simply NOT to blend overlapping spectra at all, and have users just associate individual spectral segments with a given pack or instrument name, and then let the fitter work on multiple spectral "segments" at once. So e.g. if a line appears in both spectral segments, that information would be used by the fitter to fit a single line simultaneously to both . That sounds like a good possibility. Could even bake in some warning about spectral mismatch.

[karllark]

Please continue discussion in issue #88.