-
Notifications
You must be signed in to change notification settings - Fork 90
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
add custom bandpasses #2581
add custom bandpasses #2581
Conversation
@@ -428,3 +428,21 @@ spectrum_types: | |||
- host | |||
- host_center | |||
default: source | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few minor comments, then I think we're ready.
additional_bandpasses_names = [] | ||
for additional_bandpasses in cfg.get('additional_bandpasses', []): | ||
name = additional_bandpasses.get("name") | ||
if not name: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do you expect to encounter this? I would expect this if you used .get("name", None)
above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's a malformed entry (name:
or missing name
), I dont want to throw an uncaught error.
Co-authored-by: Stefan van der Walt <sjvdwalt@gmail.com>
This looks good, thanks Josh. Curious about that last commit: should we not remove duplicate elements somehow? It was a bit surprising to me, but apparently people use dicts to do this, since they're ordered now:
|
We're not doing anything wrong with the deduplication it's just that a) I dont think we need to and b) doing so triggers a rewrite the of the enum since the ordering of the passed list changed. The migration manager (via migra) sees this as a change when it really isn't. Since sncosmo is managing the majority of the bandpasses (and names), they are keeping a unique set (I believe bandpass names are the key to their registry dict). And high up in the new code I'm checking to make sure we dont conflict with existing names. |
The 1-2 failing tests seem to be unrelated (and they pass on my machine) but they did consistently fail on the CI so I'm not sure what to do. If these have become more flaky due to other PRs then we might perhaps move them to the flaky script. Check out:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really good, and thanks for trying to improve that test!
@@ -7,7 +7,7 @@ seaborn==0.11.2 | |||
bokeh==2.4.2 | |||
pytest-randomly==3.10.3 | |||
factory-boy==3.2.1 | |||
astropy==5.0 | |||
astropy==5.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this meant to be added?
log( | ||
f"Additional Bandpass name={name} is already in the sncosmo registry. Skipping." | ||
) | ||
try: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking care of this!
Are the failures here related to the new bandpasses? |
This PR adds two custom
sncosmo.Bandpass
filters to SkyPortal. It adds the filters via data in theconfig
and loads the bandpasses ENUM with the new filter names. It also adds to the sncosmo registry so that the central wavelength is available to theplot.py
color picker. This requires a migration.This PR supercedes #2549, which contemplated using API endpoints to add bandpasses to the DB. Since adding filters will not be that common, and requires upgrading the enums, adding new filters via the config seems to be the fastest path (and least risky). This PR will be needed for the ATLAS PR #2498.
Co-authored by: jadalilleboe