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

Refactor and adding filters. #71

Merged
merged 3 commits into from
Mar 11, 2024
Merged

Refactor and adding filters. #71

merged 3 commits into from
Mar 11, 2024

Conversation

astronomerritt
Copy link
Collaborator

Code refactor:

  • This should be the final big rearrangement, at least for a long while. This is about as neat and maintainable as I can get with my current skillset.
  • The DataSchema parent class has been eliminated. Always best to avoid inheritance where you can.
  • There are now custom constructor classmethods on all classes. See adler.py for how AdlerPlanetoid should now be called.
  • The dataclasses now each have their own file. Because I was very tired of scrolling.
  • There's an additional module for utility functions for the dataclasses.

Fixes #37.

  • The user can now supply a comma-separated list of filters to the command line. By default, all filters are used.
  • The Observations object on AdlerPlanetoid is now observations_by_filter, a list of Observations objects in the order of the list of filters.
  • SSObject has many filter-dependent fields. These are now correctly pulled down from the RSP and organised into arrays, once again in the order specified by the list of filters.

Fixes #66.

  • Incidentally, the refactor now ensures the TAPService object is only created once.

Review Checklist for Source Code Changes

  • Does pip install still work?
  • Have you written a unit test for any new functions?
  • Do all the units tests run successfully?
  • Does adler run successfully on a test set of input files/databases?
  • Have you used black on the files you have updated to confirm python programming style guide enforcement?

@astronomerritt
Copy link
Collaborator Author

Fixed a typo on AdlerPlanetoid.populate_observations() that was causing observations_by_filter[0].filter_name to show up as "filter" rather than the actual filter name string.

@codecov-commenter
Copy link

codecov-commenter commented Mar 8, 2024

Codecov Report

Attention: Patch coverage is 0% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 69.84%. Comparing base (610d429) to head (6ae74ca).

Files Patch % Lines
src/adler/adler.py 0.00% 3 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #71      +/-   ##
==========================================
- Coverage   72.13%   69.84%   -2.29%     
==========================================
  Files           3        3              
  Lines          61       63       +2     
==========================================
  Hits           44       44              
- Misses         17       19       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@jrob93 jrob93 left a comment

Choose a reason for hiding this comment

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

Following from me playing around with the new AdlerPlanetoid and our quick chat, it would be useful to be able to retrieve a given filter from a planetoid object containing many filters. Something like:

obs_r = planetoid.observations_in_filter("r")
obs_r.mag

This would address the issue of having the user look up which index to use for a given filter_list (noting that the index would change if filter_list ever changes)

@astronomerritt
Copy link
Collaborator Author

Following from me playing around with the new AdlerPlanetoid and our quick chat, it would be useful to be able to retrieve a given filter from a planetoid object containing many filters. Something like:

obs_r = planetoid.observations_in_filter("r")
obs_r.mag

This would address the issue of having the user look up which index to use for a given filter_list (noting that the index would change if filter_list ever changes)

Done.

As we discussed earlier, it's probably also a good idea to have something like this for the AdlerData class to retrieve parameters by model/filter. Made an issue for that: #74.

@astronomerritt astronomerritt marked this pull request as ready for review March 8, 2024 14:31
@astronomerritt astronomerritt requested a review from jrob93 March 8, 2024 14:34
Copy link
Collaborator

@jrob93 jrob93 left a comment

Choose a reason for hiding this comment

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

Awesome, that's exactly what I wanted!

@astronomerritt
Copy link
Collaborator Author

@mschwamb would you like to look at this or shall I go ahead and merge?

@mschwamb
Copy link
Collaborator

If Jamie is happy, I am happy

@astronomerritt astronomerritt merged commit 6077e15 into main Mar 11, 2024
6 checks passed
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.

Make sure the TAPService object is only created once Include more filters
4 participants