Closed jdtsmith closed 2 years ago
I just had the notion of people taking "power" in the model results Table at face-value, and blindly taking ratios and publishing them without realizing there is a factor of lam_1/lam_2
hiding in there. So, no... I'll stick with scaled_power for the internal units. I also think it may be useful to be able to specify either power or amplitude, and have PAHFIT just convert between them as appropriate.
I.e. amplitude is easy to "guess" staring at the spectrum, but power is more useful for ties.
So Karl's idea of power-based model components is pretty brilliant for tying. Power itself is an awkward number though, unit wise. One of the only redeeming values of our crazy "meet-in-the-middle" mixed radio (f_nu) + optical (wavelength) units in the infrared is that the numbers are nice round values. E.g. 5 microns, a few mJy or MJy/sr, etc.
Integrating a Gaussian/Drude with those types of peak fluxes, and width of a few percent of its wavelength yields powers like
f_nu*c/lam_0
with units[f_nu] * Hz
. Sincec/lam_0
is a large number of order 1e13, nice 1MJy/sr fluxes become ~1e13MJy/sr Hz
powers. This is ugly to look at, and isn't good for the fitter to deal wit (fitters prefer nice round numbers to avoid overflows and step-estimation mismatch).Internally, to deal with this, I'm adopting the following: a scaled power density,
PD=P lam_0/c
whereP
is the "real" power.Advantages of this re-scaling:
Disadvantages:
Any thoughts? It's fine to keep this as a hidden convenience of the fitter; we certainly don't have to expose this in the Features table. But then again it might be an easier thing to deal with. As a final step we can convert to "real power" (which often involves multiplying by e.g. 1e-20 to get W/m^2/sr). Since eventually we have to actually deal with units, #28 and #53 are both relevant here.