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

Include prism bandpasses in the roman module #1307

Merged
merged 11 commits into from
Sep 11, 2024
Merged

Include prism bandpasses in the roman module #1307

merged 11 commits into from
Sep 11, 2024

Conversation

arunkannawadi
Copy link
Member

Addresses #1018

@arunkannawadi arunkannawadi added the roman Relevant to Roman Space Telescope specifically, especially including the galsim.roman module. label Jul 31, 2024
@arunkannawadi arunkannawadi added this to the v2.6 milestone Jul 31, 2024
@arunkannawadi arunkannawadi marked this pull request as ready for review July 31, 2024 03:57
@arunkannawadi arunkannawadi linked an issue Jul 31, 2024 that may be closed by this pull request
@arunkannawadi
Copy link
Member Author

arunkannawadi commented Jul 31, 2024

There's a lot of chatter about setuptools removing the test command. How do we want to fix the breakage?

https://setuptools.pypa.io/en/stable/history.html

@arunkannawadi arunkannawadi removed this from the v2.6 milestone Jul 31, 2024
@rmjarvis
Copy link
Member

Eugh. I guess pin setuptools to <72 for now. We use it to run the C++ tests. I guess we'll need to come up with some other builder/runner for them.

@rmjarvis
Copy link
Member

BTW, are you planning to actually do something to implement prism observations? This PR doesn't do anything except allow those bands to be selected. I think that's a bad idea if we don't also do something to make them simulate the prism dispersion physics.

@arunkannawadi
Copy link
Member Author

I figured that somebody would be confused because the changes in the PR doesn't do justice to the title :-)

Troxel and I have generated prism images along with Roman SN PIT with these changes here, some in skyCatalogs here using the dispersive photon operator here. All of these come together in the roman_imsim package here.

image

I'd still like to have this merged by v2.6 since someone at STScI is going to take this over from us and I'd like them to be able to use GalSim+skyCatalogs without needing any modifications. Apart from having a similar photon operator here in the unit tests, do you have anything in mind? I am not sure if this would be meaningful at all.

@rmjarvis
Copy link
Member

rmjarvis commented Jul 31, 2024

I feel like some kind of sanity check is warranted here. I'm worried that someone who isn't using the roman_imsim code will just try to make an image with one of these as the filter, and then be upset that the image doesn't actually have any dispersion. I don't know what the best place for it is though.

Maybe just add a logger warning along the lines of "Warning: selecting a dispersive bandpass. This should be accompanied by a suitable photon operator (e.g. from roman_imsim) to actually implement the dispersive effect. This compatibility is not checked."

@rmandelb @matroxel What do you think?

@matroxel
Copy link
Contributor

We need to at least get the right thermal backgrounds for these bandpasses and an implementation of the zodiacal light that works before merging into main I'd think?

A warning would be good, and we should probably include an example dispersion photon op and some updated documentation in demo13 or a new demo?

@arunkannawadi
Copy link
Member Author

Do we have the thermal backgrounds from the project? For other short wavelength bands, they are unavailable and set to 0 here, so I followed the same. We have nominal zodical backgrounds through those bandpasses here although they may not be precise enough for prism.

Warning + demo with dispersion photon operator sounds good. If we have to switch the backgrounds, then I'd suggest we keep the issue open but merge this PR with warning+demo.

@matroxel
Copy link
Contributor

matroxel commented Jul 31, 2024

The blue bands round to zero at some decimal place. The wide prism/grism bandpasses won't. This is something we'll have to ask about, its not on the Roman page that I found.

@matroxel
Copy link
Contributor

I guess we should be properly accounting for it vs wavelength like we will for the zodiacal light for the W filter and prism/grism. W filter is also not well represented right now.

@arunkannawadi
Copy link
Member Author

arunkannawadi commented Jul 31, 2024

For some context, Roman SN PIT folks just want to be able to test their spectral extraction code from a reasonable-looking image, not necessarily realistic. Depending on when v2.6 is aimed for, getting realistic backgrounds may be out of scope. For this initial PR, my minimal goal is to be able to get the bandpasses by calling galsim.roman.getBandpasses(), which is not possible at present.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
Copy link
Member

@rmjarvis rmjarvis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR is currently waiting on some kind of warning to let users know that selecting the Prism doesn't automatically give them Prism physics. Probably pointing to the implementation in roman_imsim that does.

AFAIU, the other items mentioned above (thermal backgrounds zodiacal light, etc.) for the Prism/Grism are considered out of scope for this PR and would be implemented in a later one. But please correct me if we want something better than just 0.0 for those now.

@arunkannawadi arunkannawadi changed the title Simulate prism observations Include prism bandpasses in the roman module Aug 14, 2024
@arunkannawadi
Copy link
Member Author

I changed the PR title to reflect the code changes.

For the warnings, I could think of two ways - either include an optional argument to getBandpasses that will decide whether to fetch non-imaging bands and warn the user if they are fetched or modify the __getitem__ method for the bandpass_dict that will warn if the keys corresponding to non-imaging bands are passed. I kinda like the second one, but I don't know if this would annoy users who might be used to just iterating over all the bands.

@rmjarvis
Copy link
Member

Here's an idea, which might be better anyway. Add an option to getBandpasses like include_nonimaging_bands=True, which would include the Prism and Grism, which defaults to False. And maybe then it would be sufficient to just put a warning in the doc string about how that isn't sufficient to get prism physics and where the user might go to get it. At least then, it requires the user to be more intentional about selecting those bands, so maybe they would see the documentation about it.

Copy link
Member Author

@arunkannawadi arunkannawadi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have at least a ball park value for the backgrounds in these bands? I can add a note in the docstring appropriately.

@@ -322,7 +322,7 @@ def test_roman_backgrounds():
# The routine should not allow us to look directly at the sun since the background there is high
# (to understate the problem). If no date is supplied, then the routine assumes RA=dec=0 means
# we are looking at the sun.
bp_dict = galsim.roman.getBandpasses()
bp_dict = galsim.roman.getBandpasses(include_all_bands=True)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you normally like to keep the old tests as they were, but I think this should be fine?

Copy link
Member

@rmjarvis rmjarvis Aug 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change shouldn't be necessary. However, you should add a test that the Prism/Grism bands aren't included yet. Then the test you added below accounts for the include_all_bands=True case where you check that they are included.


assert 'Grism_0thOrder' in bp_all
assert 'Grism_1stOrder' in bp_all
assert 'SNPrism' in bp_all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or do it here, adding the converse asserts that these are not in bp_imaging.

@rmjarvis
Copy link
Member

I'm happy with this now. @matroxel or @rmandelb did either of you want to take a look?

@rmjarvis
Copy link
Member

@arunkannawadi Looks like you might need to rebase it to the current main. GitHub is complaining.

@@ -134,8 +139,7 @@ def getBandpasses(AB_zeropoint=True, default_thin_trunc=True, **kwargs):
bandpass_dict = {}
# Loop over the bands.
for index, bp_name in enumerate(data.dtype.names[1:]):
# Need to skip the prism and grism (not used for weak lensing imaging).
if bp_name=='SNPrism' or bp_name=='Grism_1stOrder' or bp_name=='Grism_0thOrder':
if include_all_bands is False and bp_name in ('Grism_0thOrder', 'Grism_1stOrder', 'SNPrism'):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to save this list somewhere (and reuse them in the tests may be) instead of hardcoding them here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could imagine this going in galsim/roman/__init__.py as nonimaging_bands or something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

@rmjarvis rmjarvis added this to the v2.6 milestone Aug 20, 2024
@rmjarvis rmjarvis merged commit dcb134c into main Sep 11, 2024
10 checks passed
@rmjarvis rmjarvis deleted the #1018 branch September 11, 2024 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roman Relevant to Roman Space Telescope specifically, especially including the galsim.roman module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants