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

Python version: Dereddening the Observed SED? #13

Open
karllark opened this issue Oct 10, 2012 · 6 comments
Open

Python version: Dereddening the Observed SED? #13

karllark opened this issue Oct 10, 2012 · 6 comments

Comments

@karllark
Copy link
Member

Am I correct that you are dereddening the observed SED then comparing to unredded stellar models? Or applying the dust extinction to the band averaged fluxes of the model stellar SEDs? If so, I think
this is a potential major source of error. The wide bandpasses and red leaks of the PHAT filters make this an inaccurate way to do this. To get the right predicted flux, you have to extinguish the stellar flux,
then multiple by the bandpasses. This then gets the right weighting and produces the "correct" flux in each band. Doing this any other way does not produce the same predicted flux. Or am I missing something?

@mfouesneau
Copy link
Member

You are perfectly right, in the current script, we deredden the data using the same tau, or filter effective wavelength for any value of Av. (dereddening the data is faster that reddening the models, 1 SED against N>>1)
We actually had a discussion with HW about this when he visited us at UW recently.

We completely agreed that in theory, we should apply the redenning on the modeled spectra, then compute the SEDs. However, our arguments in favor or this approximation are:
a) the approximation we do may be smaller than the data uncertainties in practice,
b) we can compute a better effective lambda, lamb_eff(Av,...) or tau(lambda, Av,...) for the models to keep the speed up.

I never had the chance to plot how wrong we are by applying redenning on the integrated fluxes compared to the correct way. However, I am pretty convinced (so far) that this should held on (maybe not for 10 magnitudes of Av). Back on the bench of my school (a long time ago as you know) I have been taught to how do isochrone fitting in clusters'cmds using constant reddening vector, as everyone does in practice I think.
I expect the approximation to be worse in the blue part instead of the red side, why the red?
I would be happy to be wrong, when talking about being dirty, you are the expert :p. If effectively this is way wrong, this is short very useful paper.

Anyhow, this is the current demo script, but we can change this.
I have no idea about the redding model including "smc-ness". We can work that out, and the worse scenario is to grid over Av, Rv, ... which speeds-up the likelihood computations but costs memory.

@karllark
Copy link
Member Author

I understand the desire for speed and the hope that this approximation is "ok". But it just isn't in the end. I know that lots of people do it this way, but that doesn't change that this is an approximation and that it has scary systematic effects. It is more than just changing the effective wavelength of the bandpass, the really scary parts are for red leaks. The blue filters in PHAT have red leaks - in fact all filters have such issues. When you redden a star, the importance of the red leak increases and, in fact, can begin to dominate the measured flux in filter. This is completely missed unless the extinction/reddening is applied before multiply by the filter bandpass. This is a well known effect and has been mentioned many times in the past in the literature.

As speed is not a major issue at this point (is it?), I don't see why we should be taking chances with this approximation at all. If speed becomes an issue, then we can MCMC the puppy. We should push do do this the right way and then deal with any speed issues. We can then quantitatively evaluate if a particular approximation is a good idea, but only after we have the full solution. Otherwise, how do we know that we aren't going to be screwed by one of our approximations?

@mfouesneau
Copy link
Member

Speed is not a problem at this point. The python code is fast.
This is an interesting question for the Gordon Rule... I agree on the theoretical proper way but wonder if this improves significantly the results. Do you have a plot in your archives?

@karllark
Copy link
Member Author

No plot. I had assumed that this was maybe obvious. I've played around with this and the red leaks are an issue for red sources - as expected. I haven't saved anything at this point. We probably should do this face-to-face at this point. Red leaks are basically that there is throughput at wavelengths much longer than the bandpass. These throughputs are small, but for red sources, the contribution from the red leak (star flux_leak) can be larger than the (star flux_in band response). It is not a problem for blue sources, as the red leak is << in band flux. Hopefully this makes some sense. I would encourage you to look at the actual band response functions to see that the throughput is not zero at red wavelengths. The F275W and F336W bandpasses are probably the easiest to see this in.

@mfouesneau
Copy link
Member

I see. I thought this was the reason why using an effective wavelength and not a median or average.
If I understand your concerns are that the filter is actually so broad that the attenuation factor varies a lot across the filter and this can be amplified for red very red sources.
I'd be happy to talk about this during the meeting week.

@dweisz
Copy link
Member

dweisz commented Oct 11, 2012

I'm curious to see the magnitude of the systematic introduced by the extinction approximation. I think a similar approximation is made in MATCH, and the systematics can't be too bad (at least not larger than any photometric errors), or the CMD residuals would show it. Although I could be wrong about how Andy does it. It'll be good to discuss this with him at the PHAT meeting too.

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

No branches or pull requests

3 participants