Request: support for spectral flux-per-area

[ariedel]

The JWST ETC uses backgrounds given in MJy/sr (extended source brightness units), but synphot does not support this.

It would be convenient to the project (and presumably astronomers working with extended sources like galaxies or nebulae) to support MJy/sr as a spectral unit.

[pllim]

How do astronomers convert between MJy/sr and MJy?

How exactly do you envision synphot should support this? Can you please give some usage examples?

Thanks!

[ariedel]

I can't speak for most astronomers (extragalactic work was not my field) but in the JWST ETC, the backgrounds are given in Megajanskies per steradian, converted to millijanskies per cm^2, and then to millijanskies per pixel to be applied to our model scene. It's then integrated over our apertures to provide scalar numbers.

[pllim]

Can JWST ETC please provide a standalone and real-life example with such a conversion?

[tepickering]

it's a surface brightness. to convert to integrated flux (i.e. Jy) you provide an area to integrate over. astropy.units does this easily enough:

sb_f = 1 * u.MJy/u.steradian
flux = sb_f * ((0.15 * u.arcsec)**2).to(u.steradian)

the background is 1 MJy/sr and this calculates the integrated background in a 0.15"x0.15" pixel (0.52884969 𝜇Jy).

[pllim]

So, a pixel scale is needed, which means it is instrument specific. 🤔

Do you simply want synphot.units.convert_flux to know how to handle this conversion (simple) or do you want SourceSpectrum to actually take this surface brightness unit (hard)?

[tepickering]

it's not instrument-specific, per se, it just needs an area (more precisely solid angle) to integrate over. this can be a pixel scale or aperture size or whatever has valid solid angle units (e.g. sr or arcsec**2). i think ideally SourceSpectrum should be able to support surface brightness units. would implementing a new surface brightness subclass like SBSpectrum be any easier? or is the unit handling complexity more deeply baked?

[pllim]

It's more about thinking carefully how it would interact with all the other existing objects and methods. What happens when you pass surface brightness into an Observation? What happens when you add it to some other source? What does calculating effstim on surface brightness really mean? Etc etc

[tepickering]

in principle, most if not all of the spectral operations should pass thru and not care if it's flux or flux/solid angle. e.g. effstim would give you something like FLAM/sr or counts/s/arcsec**2; bandpasses work the same way. of course, you can't just add a flux spectrum to a surface brightness spectrum without dealing with the areal integration. this argues for something like SBSpectrum that subclasses from SourceSpectrum and adds what you need to convert as appropriate. seems doable, but definitely more work than just making convert_flux surface brightness aware...

[pllim]

seems doable, but definitely more work

Yes, I agree. Therefore, I would like to know what exactly that JWST ETC needs here first.

[pllim]

Apparently, a 1.0 release is going to happen by Fall (not my choice), so if you want this in, please let me know how to proceed. cc @vglaidler

[pllim]

JWST ETC has confirmed that this is not needed for 1.0 release as they have a workaround from the PySynphot days.

[pllim]

@talister also requested this in #372 (comment) .

However, it is still unclear to me whether there is an universal standard to obtain the pixel scale to get rid of the "per area" from various instruments/observatories to make coding this up less painful. And how this "per area" should be accounted for in the various photometric calculations that are already supported.

If there is a write-up somewhere that I can implement, would be possible. Without that, I do not have time to dive into this.