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 VaryingCelestialTransform models #344

Merged
merged 32 commits into from Mar 25, 2024
Merged

Conversation

SolarDrew
Copy link
Contributor

Starts compressing WCS models into a single model that can handle multiple dimensions of input.

Copy link

codecov bot commented Mar 8, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.50%. Comparing base (c6dd4c2) to head (d7f2887).

❗ Current head d7f2887 differs from pull request most recent head b140961. Consider uploading reports for the commit b140961 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #344      +/-   ##
==========================================
+ Coverage   96.08%   97.50%   +1.42%     
==========================================
  Files          51       34      -17     
  Lines        2832     1887     -945     
==========================================
- Hits         2721     1840     -881     
+ Misses        111       47      -64     

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

dkist/wcs/models.py Outdated Show resolved Hide resolved
dkist/wcs/models.py Outdated Show resolved Hide resolved
@Cadair Cadair marked this pull request as draft March 8, 2024 17:10

if not isinstance(projection, m.Pix2SkyProjection):
raise TypeError("The projection keyword should be a Pix2SkyProjection model class.")
self.projection = projection

if self.is_inverse:
Copy link
Member

Choose a reason for hiding this comment

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

I am conflicted about this. I like the reduction in classes, but I think that ultimately this might be more confusing when introspecting the models etc. The most common pattern with astropy models is that you have a different class for the inverse.

What would the fall out be from putting the inverse classes back as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Minimal I should think. The way it was before there was some calulation happening in the inverse classes but now that's been brought in to the base class it would be pretty straightforward to just have an inverse class for each dimension that sets self.is_inverse = True and does nothing else. Some of the corresponding infrastructure would have to go back in but that's fine.

Happy to revert this later, just want to make sure everything else is
working
@Cadair Cadair mentioned this pull request Mar 22, 2024
@@ -1,5 +1,7 @@
from abc import ABC
from typing import Union, Literal, Iterable
# from functools import cache
Copy link
Member

Choose a reason for hiding this comment

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

remove

Comment on lines 17 to 19
"InverseVaryingCelestialTransform",
"InverseVaryingCelestialTransform2D",
"InverseVaryingCelestialTransform3D",
Copy link
Member

Choose a reason for hiding this comment

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

revert?

@Cadair Cadair marked this pull request as ready for review March 25, 2024 11:56
@Cadair Cadair merged commit 5b0a45b into DKISTDC:main Mar 25, 2024
15 of 16 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.

None yet

2 participants