Include area of a pixel in mask_projected_limb#43
Conversation
|
I've always worked with relative fluxes so this never occurred to me. But it is in fact such an important fix. Thank you so much for this @vatsalpanwar! 🙏🏼 Could you change mask_projected_limb(N_or_y, phase=None, inc=None, u=None, obl=None)This way, we only create |
|
Ah yes, that's a better way to do it, I have just made the change to the branch. I should say here the reason I am trying to get the units right for stellar spectrum is for high-resolution emission spectroscopy where I am interested in calculating contrast of planet flux (Fp) to star flux (Fs). In this case I want to be able to get the Fs and Fp for each time step individually (with Doppler shift due to stellar rotation, active features etc accounted for Fs) and then compute Fp/Fs. |
|
That makes absolute sense. It's such a nice application of spotter. Please feel free to open more issues and PR in the future! |
|
One last thing, can you increase the version in |
After some testing with assigning PHOENIX spectrum for each pixel, computing the integrated spectrum, and comparing it with what one would expect the integrated spectrum to be a simple scaling of the input PHOENIX spectrum by pi, I found that the integrated spectrum computed by spotter was much higher (by a few order of magnitudes). And the difference between what spotter would compute and what is expected kept increasing with increase in the value of nside. I think the reason is that the projected_area calculation in the function mask_projected_limb was just set to the z, but actually it should be z*hp.nside2pixarea(N), which takes into account the decreasing area of each pixel as you increase nside. This resolves the difference between integrated spectrum computed by spotter and what one would expect from scaling by pi. I have made the changes in wherever mask_projected_limb is called in core (I didn't find it being called anywhere else, but let me know if it is and I will make changes there too).