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

Account for zodiacal brightness in estimating star probability #209

Open
taldcroft opened this issue Aug 9, 2017 · 6 comments
Open

Account for zodiacal brightness in estimating star probability #209

taldcroft opened this issue Aug 9, 2017 · 6 comments

Comments

@taldcroft
Copy link
Member

The dark current modeling removes zodiacal brightness, which in turn underestimates the warm fraction in general. For the most accurate results we should included the estimated zodiacal brightness for each field.

@jeanconn
Copy link
Contributor

jeanconn commented Aug 9, 2017

This gives a driver to Python-ize the simple zodiacal brightness lookup and put it somewhere. Should that live in starcheck, a new module, chandra_aca, or Ska.astro, or?

@taldcroft
Copy link
Member Author

Probably chandra_aca.star_probs would work. BTW, one short-term workaround is just to increase the warm_frac by a fixed value that accounts for the mean zodi brightness.

@jeanconn
Copy link
Contributor

jeanconn commented Aug 9, 2017

Right, I suppose the short term work-around makes sense. Right now I don't think we have anything in Python to convert to ecliptic coordinates (needed for the table lookup). I haven't looked at the release notes to know if we'd be fine updating astropy to a version >= 1.1 in PY2 HEAD flight for use with this.

@jeanconn
Copy link
Contributor

Do you have a "fit" value for mean zodi brightness that I should use? I assume that we want at least the short-term workaround for starcheck 11.21?

@jeanconn
Copy link
Contributor

Regarding actually implementing this, once I have the zodiacal brightness in e-/sec for a field, do we need an offset option for chandra_aca.dark_model.get_warm_fracs or would it be obvious enough if the calling code in chandra_aca.star_probs just adjusted the warm threshold due to the zodiacal brightness contribution (as in 5 e-/sec zodiacal brightness moves N100 warm threshold to 95).

@taldcroft
Copy link
Member Author

Coming back to this after seeing the implementation, I think I disagree with myself circa Aug 2017.

warm_frac = get_warm_fracs(WARM_THRESHOLD - bgd, date=date, T_ccd=t_ccd)

This has an obvious problem that if bgd is more than WARM_THRESHOLD then everything blows up, even though in reality we could acquire stars with a uniform background of 100 e-/sec.

There is a deeper issue, which is that the acq probability model is calibrated using the warm frac derived from the zodi-subtraced dark cal. So warm frac is an indicator of dark current non-uniformity, which correlates with star acquisition. But we do not actually know how star acquisition probs are impacted by adding a uniform bias (zodi bgd). Here we could use ASVT to potentially add bgd level as another model parameter.

So now I think this issue is not such a problem, because we are calibrating using a sample that includes the zodi bgd in actual star data, and using warm frac that does not. So the mean probs are correct. In fact if we just put in this update as a "one-sided" change (without re-calibrating the model) then all the answers would be systematically wrong.

Upshot: if we have an especially high or low zodi bgd, then the predicted probability might be slightly off. My intuition is that the effect is relatively small, but we could now test this. I think it is not the highest priority though.

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

2 participants