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

JP-1762: Add VA correction to WCS #5602

Merged
merged 7 commits into from
Feb 18, 2021
Merged

Conversation

mcara
Copy link
Member

@mcara mcara commented Jan 9, 2021

This PR adds support for velocity aberration correction in WCS. It needs thorough review.

It was decided, after a couple of iterations, that DVA correction will be applied as a separate transformation from the v2v3 frame to a new, VA-corrected, v2v3 frame that will be called 'v2v3vacorr' in WCS pipeline.

The code applies a constant scale DVA correction in the (almost-)tangent plane v2-v3 at Colin Cox suggestion. However, for when non-linear effects may become important, this PR also includes commented out full set of transformations from the spherical v2,v3 coordinates to a tangent plane and then applying constant scale transformation in that plane and then backward transformation to the (DVA-corrected) spherical coordinates v2,v3.

Resolves JP-1762 and #5434

@codecov
Copy link

codecov bot commented Jan 9, 2021

Codecov Report

Merging #5602 (51767f2) into master (1135053) will increase coverage by 0.23%.
The diff coverage is 93.40%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5602      +/-   ##
==========================================
+ Coverage   75.40%   75.64%   +0.23%     
==========================================
  Files         406      406              
  Lines       36486    37214     +728     
==========================================
+ Hits        27513    28150     +637     
- Misses       8973     9064      +91     
Flag Coverage Δ *Carryforward flag
nightly 75.77% <94.91%> (ø) Carriedforward from 1135053
unit 54.62% <88.23%> (+0.03%) ⬆️

*This pull request uses carry forward flags. Click here to find out more.

Impacted Files Coverage Δ
jwst/assign_wcs/fgs.py 70.58% <80.00%> (-24.01%) ⬇️
jwst/assign_wcs/niriss.py 78.92% <85.71%> (+2.10%) ⬆️
jwst/assign_wcs/miri.py 85.26% <91.66%> (-4.37%) ⬇️
jwst/assign_wcs/pointing.py 94.35% <94.73%> (-0.78%) ⬇️
jwst/assign_wcs/nirspec.py 93.59% <96.42%> (-0.28%) ⬇️
jwst/assign_wcs/nircam.py 88.58% <100.00%> (+0.55%) ⬆️
... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1135053...51767f2. Read the comment docs.

@@ -142,6 +147,7 @@ def imaging(input_model, reference_files):
(sca, det2gwa),
(gwa, gwa2msa),
(msa_frame, None)]
# TODO: Add DVA correction
Copy link
Collaborator

Choose a reason for hiding this comment

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

There's no need to add VA correction here since this pipeline does not go to sky but stops at the MSA.

@@ -231,12 +237,13 @@ def ifu(input_model, reference_files, slit_y_range=[-.55, .55]):
(slit_frame, slit2slicer),
('slicer', slicer2msa),
(msa_frame, None)]
# TODO: Add DVA correction
Copy link
Collaborator

Choose a reason for hiding this comment

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

No need for VA correction here, ti stops at the MSA.

@@ -345,14 +352,15 @@ def slitlets_wcs(input_model, reference_files, open_slits_id):
(gwa, gwa2slit),
(slit_frame, slit2msa),
(msa_frame, None)]
# TODO: Add DVA correction
Copy link
Collaborator

Choose a reason for hiding this comment

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

and here, no va correction

@jdavies-st jdavies-st changed the title Add VA correction to WCS JP-1762: Add VA correction to WCS Jan 11, 2021
@mcara
Copy link
Member Author

mcara commented Jan 12, 2021

Thanks @nden! I removed TODO comments, unused imports and fixed a bug due to which v2_ref and v3_ref were not converted to degrees.

Copy link
Collaborator

@jdavies-st jdavies-st left a comment

Choose a reason for hiding this comment

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

This looks good!

Just a couple minor comments below. Not sure why we're seeing small changes in the computed coordinates, mostly in S_REGION.

https://plwishmaster.stsci.edu:8081/job/RT/job/jdavies-dev/220/testReport/

name='v2v3vacorr_spatial',
axes_order=(0, 1),
unit=(u.arcsec, u.arcsec),
axes_names=('v2', 'v3')
Copy link
Collaborator

@jdavies-st jdavies-st Feb 17, 2021

Choose a reason for hiding this comment

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

Is there a reason to have axes_names here but not for the MIRI imaging mode (or the other instrument imaging modes)?

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 do not know... I just copied the frame that was already used in the assign_wcs for a given instrument. I simply appended vacorr to the frame name. No other changes. I also noticed sometimes frames are called v2 and sometimes V3 - see #5746 point #4. Maybe this should be noted there?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see. Maybe for a future "consistency and cleanup" PR then. Agree to keep it as for this PR.

@@ -74,6 +74,7 @@ def imaging(input_model, reference_files):
"""
detector = cf.Frame2D(name='detector', axes_order=(0, 1), unit=(u.pix, u.pix))
v2v3 = cf.Frame2D(name='v2v3', axes_order=(0, 1), unit=(u.arcsec, u.arcsec))
v2v3vacorr = cf.Frame2D(name='v2v3vacorr', axes_order=(0, 1), unit=(u.arcsec, u.arcsec))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Again, no axes_names here. Maybe it would be good to have consistency between these imaging modes and the spectral modes?

Comment on lines 296 to 298
va_scale = float(datamodel.meta.velocity_aberration.scale_factor)
v2_ref = float(datamodel.meta.wcsinfo.v2_ref)
v3_ref = float(datamodel.meta.wcsinfo.v3_ref)
Copy link
Collaborator

@jdavies-st jdavies-st Feb 17, 2021

Choose a reason for hiding this comment

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

Casting these to float is probably not needed, as they are already floats by definition from the schemas. Or they are not populated and return None, which of course will return a TypeError when cast to float. AttributeError should never be returned.

You could just put the equation in the try block and if any of the items are None, you're going to get a TypeError.

I wonder the casting of values could be causing the slightly differences in the regtests for S_REGION? One is type <class 'numpy.float32'>, the other <class 'float'>.

Copy link
Member Author

Choose a reason for hiding this comment

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

You could just put the equation in the try block and if any of the items are None, you're going to get a TypeError.

Isn't what I am already doing? I did not know that meta.velocity_aberration.scale_factor and wcsinfo.v2_ref and meta.wcsinfo.v3_ref are always guaranteed to exist. If that is the case, I'll be happy to remove attribute error from being caught.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, they are always guaranteed to exist because they're in the schema and in meta.

# rot.inverse | c2s | unit_conv.inverse
# )

va_corr.name = 'VA_Correction'
Copy link
Collaborator

Choose a reason for hiding this comment

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

The name should be descriptive, and bits are free. "Spacecraft Velocity Aberration Correction" would be useful.

Copy link
Member Author

Choose a reason for hiding this comment

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

@nden What do you think? I personally think that VA_Correction should be OK but if you think a longer string is more desirable - it is easy to change this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Models can be referenced by name so I'd say shorter is better and not having spaces in the name is preferable.

Comment on lines 11 to 17
def create_imaging_datamodel(v2_ref, v3_ref, va_scale):
hdul = create_hdul()
datamodel = ImageModel(hdul)
datamodel.meta.velocity_aberration.scale_factor = va_scale
datamodel.meta.wcsinfo.v2_ref = v2_ref
datamodel.meta.wcsinfo.v3_ref = v3_ref
return datamodel
Copy link
Collaborator

Choose a reason for hiding this comment

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

This could be a Pytest fixture, and it would be much clearer that the tests depend on it.

@mcara
Copy link
Member Author

mcara commented Feb 18, 2021

Just a couple minor comments below. Not sure why we're seeing small changes in the computed coordinates, mostly in S_REGION.

https://plwishmaster.stsci.edu:8081/job/RT/job/jdavies-dev/220/testReport/

I investigated this and it looks that VA_SCALE was poulated with a value != 1 and hence now that VA correction is accounted for in the WCS, changes in produced world coordinates are expected. I think what we see here is reasonable.

For example, for test_miri_lrs_slit_spec2_run_pipeline0/jw00623032001_03102_00001_mirimage_cal.fits I get:

In [7]: d.meta.velocity_aberration.scale_factor
Out[7]: 1.000000146732572

Copy link
Collaborator

@jdavies-st jdavies-st left a comment

Choose a reason for hiding this comment

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

Thanks Mihai. Yeah, it looks like some of our test data, probably from OTB or SDP processing, already has VA_SCALE set, so nice to see it exercised in your code.

Copy link
Collaborator

@nden nden left a comment

Choose a reason for hiding this comment

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

LGTM other than the code style issue

@nden
Copy link
Collaborator

nden commented Feb 18, 2021

Needs a change log.

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.

3 participants