Skip to content

Have sed.resample_sed actually resample rather than interpolate. #427

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

Merged
merged 1 commit into from
Oct 22, 2024

Conversation

yoachim
Copy link
Member

@yoachim yoachim commented Oct 21, 2024

Replace numpy.interpolate calls with a resampling algorithm that conserves flux. Thus, Bandpass and Sed objects can now safely have very different wavelength sampling and still return correct integrated fluxes and magnitudes.

@rhiannonlynne
Copy link
Member

Looks like this makes the magnitude calculation run about 2x slower .. not a dealbreaker I guess.

The magnitudes that are calculated for the m5 'overview' values are the same, which is good .. either because the m5 is calculated using a flat SED and thus resampling methods don't matter as much or because the strict-regridding is happening behind the scenes anyway in the makeM5 function. Either way, having these results remain identical is good.

The magnitudes calculated in other notebooks (such as the rubin_sim_notebooks.photometry directory) do change, although at the level of 0.001 magnitudes, but those are also using fairly simple SEDs. Did you get a chance to check the calculated magnitudes against some other package such as astropy synphot?

@rhiannonlynne
Copy link
Member

I did also check for the simple SED of the sun that if we read in the Bandpass or the SED and downsample either or both of them that we do still get about the same magnitude. Obviously you can still push things far enough that they are not accurate, but it's surprising how much leeway you do get, and you do regain some of the speed loss.

@yoachim yoachim force-pushed the tickets/OPSIM-1089 branch from 0974542 to e75723d Compare October 22, 2024 17:05
@yoachim
Copy link
Member Author

yoachim commented Oct 22, 2024

Didn't check the mags against anything external, but looked like the values weren't changing.

I didn't see an easy way to get rid of the brute-force loop that's slowing things down. There is a numba wrapped version as well, so I'll make a note of that in the docstring in case anyone wants to upgrade to that in the future.

@yoachim yoachim merged commit 3c307d3 into main Oct 22, 2024
6 of 7 checks passed
@rhiannonlynne rhiannonlynne deleted the tickets/OPSIM-1089 branch December 20, 2024 00:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants