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

APE 14 implementation #146

Merged
merged 1 commit into from
Nov 8, 2018
Merged

APE 14 implementation #146

merged 1 commit into from
Nov 8, 2018

Conversation

nden
Copy link
Collaborator

@nden nden commented Mar 26, 2018

APE 14 implementation.

@coveralls
Copy link

coveralls commented Mar 26, 2018

Coverage Status

Coverage increased (+1.05%) to 89.125% when pulling 4ef54e5 on nden:ape14 into 9c7d371 on spacetelescope:master.

@nden
Copy link
Collaborator Author

nden commented Mar 26, 2018

@astrofrog @Cadair This is a start of APE14 implementation. It's pretty straightforward to implement in gwcs though some questions came up, specifically the top three in the description above may need clarification.

gwcs/wcs.py Outdated
return is_separable(self.forward_transform)

def pixel_to_world_values(self, *pixel_arrays):
# need **kwargs
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am not convinced we do need this here, this API doesn't need to encapsulate the whole of the gWCS functionality.

Having said that I am not sure there is a problem with having it in the function signature. (Other than output should be prohibited)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

There's a suggestion that the result should return NaNs where there's no valid WCS solution. This is controlled by keywords and their current defaults provide this functionality. So yes, currently it's not strictly needed.

@astrofrog
Copy link

astrofrog commented Mar 26, 2018

@nden - just for info, I've started a document here with issues I've encountered while implementing this on the astropy side: [will send link in slack] feel free to make suggested edits if you have any further thoughts! Once we've both had a chance to think about these issues and try and push the implementation further, my plan is to send this out to the main APE authors and then if there is agreement, to open a PR to amend the APE.

gwcs/wcs.py Outdated
@property
def axis_correlation_matrix(self):
from astropy.modeling import separable
return separable.is_separable(self.forward_transform)
Copy link
Collaborator

@Cadair Cadair Aug 13, 2018

Choose a reason for hiding this comment

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

I dont think this is correct, the output should be a matrix. The closes I could cook up is:

s = separable.is_separable(spatial & Identity(1))
sep = np.identity(len(s), dtype=bool)
for i, a in enumerate(s):
    sep[i,i] = not(a)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Right. I will have to work on this. It isn't ready for review yet, especially thie property.
that said comment would be very useful.

Copy link
Collaborator

Choose a reason for hiding this comment

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

sure, I actually came here looking for how you worked this out for compoundmodels in general and ended up getting a little distracted by matrices lol

@astrofrog
Copy link

astrofrog commented Sep 28, 2018

Note that astropy/astropy#7326 has now been updated and is 'ready' (apart from more tests that are needed)

order of axes in pixel_shape and pixel_bounds

This is now clarified in the APE. Note that pixel_shape is now array_shape

how to pass kwargs to pixel_to_world_values and world_to_pixel_values

I don't think we allow this for now. What use case did you have in mind?

implement world_axis_object_classes - perhaps don't require classes but a callable?

I think you can now simply implement world_to_pixel and pixel_to_world yourself and just raise a NotImplementedError for world_axis_object_classes and world_axis_object_components - this was what you were planning on doing I think?

@nden
Copy link
Collaborator Author

nden commented Sep 28, 2018

how to pass kwargs to pixel_to_world_values and world_to_pixel_values

I don't think we allow this for now. What use case did you have in mind?

The use case is passing non-coordinate inputs, like spectral_order or slit_name.
The general implementation of this still needs to be worked out in gwcs.
Specific examples exist in jwst.

I think you can now simply implement world_to_pixel and pixel_to_world yourself and just raise a
NotImplementedError for world_axis_object_classes and world_axis_object_components - this was
what you were planning on doing I think?

Yes, this is fine.

@astrofrog
Copy link

@nden - is there any reason why you couldn't essentially treat slit_name or spectral_order as keys to a dictionary of WCS objects? That is: overall_wcs[slit_name][spectral_order].world_to_pixel(...). Having said that, I'm not completely opposed to the kwargs, but I just want to make sure I understand.

@nden
Copy link
Collaborator Author

nden commented Sep 28, 2018

@astrofrog I could but it's a dict then and not a WCS object. Many of the JWST spectral pipelines are setup as one WCS object. For example an IFU observation has one WCS for all slices. The reason is that many of the transforms are the same and are shared among slices.
Another example is the slitless spectroscopy where the models are global and are parametrized by spectral order and locaiton (IIRC).

@astrofrog
Copy link

astrofrog commented Sep 28, 2018

@nden - actually is there any reason why you can't choose to add kwargs in this implementation since you are going to implement both the low- and high-level API? In other words, I guess the APE doesn't forbid you from doing this?

@nden
Copy link
Collaborator Author

nden commented Sep 30, 2018

@astrofrog Yes, I will add **kwargs in this implementation. I just want to make sure that the option is available in the top level interface used in nddata (if my understanding of how this is going to work is correct).

@nden nden changed the title WIP: APE 14 APE 14 implementation Oct 1, 2018
gwcs/api.py Outdated
"""
if not self.forward_transform.uses_quantity:
kwargs = {'with_units': True}
return self.__call__(*pixel_arrays, **kwargs)
Copy link
Collaborator

Choose a reason for hiding this comment

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

why the __call__?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, strictly speaking, it's not necessary.

return False

def world_axis_object_classes(self):
raise NotImplementedError()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is the plan to implement these to facilitate a common high level API object? (In addition to gWCS implementing the high level api?)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, I wasn't planning on implementing it. Is there a need for this?

@astrofrog
Copy link

@nden - can you try updating to the latest developer version of astropy to make sure that things work properly now?

@nden
Copy link
Collaborator Author

nden commented Nov 1, 2018

@astrofrog Done and tests passing.

I'd like to merge this in about a week at the latest. If anyone has the time to review please do so before then. cc / the APE authors: @Cadair @eteq

@nden
Copy link
Collaborator Author

nden commented Nov 7, 2018

Last ping if anyone has time to review or intends to review it and needs more time.

@nden nden merged commit e59eb05 into spacetelescope:master Nov 8, 2018
@nden nden deleted the ape14 branch December 27, 2018 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants