MRS alpha-beta cubes for commissioning

[stscijgbot]

Issue JP-1013 was created by David Law:

In order to support commissioning activities to determine the MRS PSF (known to be different in the alpha-beta directions) it will be necessary to construct alpha-beta cubes for dithered observations.  These are cubes in which the along-slice and across-slice directions are aligned with the X/Y spaxel axes of the cube.

This has been on the long-term agenda of the MIRI team for a while, but was pending an easy solution of how it might be implemented that is now resolved.

Essentially, what is necessary is a data cube with astronomical RA/DEC coordinates in which the rotation of the cube is set such that the along-slice (alpha) direction is along the X-axis of the cube.  This can be achieved simply by applying a rotation angle Theta when computing the Xi-Eta pixel coordinates from the input RA/DEC coordinatates, where Theta is defined as the position angle of the along-slice direction in the first exposure (computed using the embedded wcs).  Specification of a keyword when running cube_build would thus determine whether the position angle of the cube is 0 (which it always is at the moment) or allow it to be aligned with the IFU hardware.  Both kinds of cubes would be equally astronomically valid.

Technical note: alpha may not increase to the right, and beta may not increase up in these cubes.  The alpha/beta coordinate system contains some flips relative to V2/V3 (and by extension RA/DEC) that should not be reproduced so that these cubes are simply rotated with respect to the standard PA=0 cubes.  This may mean, for instance, that beta increases downwards.

[stscijgbot]

Comment by Alicia Canipe: Added to the list of issues for prioritization: [https://outerspace.stsci.edu/display/JWSTPWG/Calibration+Pipeline+Deadlines+and+INS+Issues]

[stscijgbot]

Comment by David Law: From an email thread:
Rather than trying to do any actual cube construction in a distorted reference frame (requiring mapping coordinates from one image to another), the simplest way to implement it is as a rotation in the xi-eta cube coordinate frame with respect to RA/DEC.  
 
How cube building works is that each pixel on the detector (i.e., all slices) maps to a ‘point’ in RA/DEC space using the instrument WCS, and there is only a single step of gridding that occurs when building the cube in this output space from the input point cloud.  By default, N is up and E left in the output cubes.  What we planned to do for MIRI was to implement a very simple variation on the above in which the point cloud coordinates are simply rotated by some angle prior to constructing the xi-eta pixel coordinates used for the actual cube construction.  This angle is determined from the WCS as the angle for which the first exposure in a given sequence will have the along-slice direction in the cube-x direction and the across-slice in the cube-y direction.  The embedded WCS in these derotated cubes is fully useful as it’s simply a version of RA/DEC oriented without N up.
 
The main intent of this coordinate frame is for PSF determination during commissioning, since for MIRI the PSF has a dependence on along-slice vs across-slice direction, but I’d expect it would be useful for science purposes too.

[stscijgbot]

Comment by David Law: Here's a pipeline branch in which I calculated the relevant rotation angle and added it to the output cube headers: https://github.com/drlaw1558/jwst/tree/drl_abrot2 (this draft specific to MIRI though)

[stscijgbot]

Comment by Jane Morrison: [~dlaw] Ok David I am going to start on this tomorrow. Do you have any test data I can use. We just want to dithered MRS data right ?

[stscijgbot]

Comment by David Law: Any dithered MRS data should be fine, e.g. the stuff that I emailed you at the end of February from end-to-end testing should be good.

[stscijgbot]

Comment by Jane Morrison: [~dlaw]
So currently cube build can create an IFU cube in alpha-beta space, but it can only do it for single exposures not dithered. This is controlled by coord_system parameter = 'alpha-beta'
These cubes are then built in alpha beta space and not using the point cloud because the transformation
goes from x,y to local MRS coordinate system.
For now I will just keep that and not bother taking it out. I can run a test to make sure the new de-rotated cubes are similar to the alpha_beta cubes using the old code.

But for de-rotated cubes these are only valid for a single band and single channel. I will add some checks in code to test this. I looked at your code and it seems simple enough. I suppose we want these cubes to have some distinctive name (suffix or something) - ideas ?

[stscijgbot]

Comment by David Law: I think it's reasonable to keep in the old one-exposure alpha-beta cubes.

For the new cubes, I'm not sure that it's strictly necessary that they be only valid for a single band/channel.  I'd be inclined to allow them for any combination of input exposures ( using the first one to set the rotation angle) with the simple documentation caveat that there could be a degree or so difference if (say) you're effectively using a 1A input file to set the rotation used for a 2A input as well.  The difference in rotation angle between bands especially is sufficiently small that for many purposes it can likely be ignored when working with derotated cubes.

As far as a naming scheme, I think 'derotated' is fine.  Alternatively, we could approach this the other way and instead of setting a special flag to create derotated cubes, we have a special flag that creates our usual aligned with N-E cubes.  I.e., by default cube building runs with the 'SKYALIGN' flag enabled, which makes it produce cubes in which N is up and E left.  If that flag is false, it produces what we've been calling derotated cubes.  Thoughts?  'skyalign' is perhaps more descriptive than 'derotated'.

[stscijgbot]

Comment by David Law: Just realized you might have been asked a slightly different question regarding file naming conventions; I'm inclined to not give these a special name.  It's not really necessary, as the embedded WCS is fully accurate, and it's simply a construction choice similar to the weighting function used.  I think it would just add complexity that we don't need.

[stscijgbot]

Comment by Jane Morrison: You know better what is needed for commissioning than I do. But in the case of the alpha-beta type cubes there is 1 to 1 mapping of the slices to the beta dimension. So all alpha-beta cubes in channel 1 have a dimension of 21 in the beta dimension. We only had to worry about mapping and overlaps in the alpha and wavelength dimension. This ensured that the cubes were aligned in the alpha-beta system.
I am not really sure what de-rotated cubes using more than 1 channels worth of data worth of data will be used for. Are you sure we want to allow the user to make these ? They seem a little confusing - but like I said you know better than me what they want these in commissioning for.

And back to SKYALIGN - yes I like that idea. That will be an additional header keyword that will be written to all IFU cubes. False if it is 'de-rotated".
Have you talked to NIRSPEC about if they want something similar ? James Muzzerole may want these types of cube when they have internal lamp data.

[stscijgbot]

Comment by Jane Morrison: [~dlaw]You know better what is needed for commissioning than I do. But in the case of the alpha-beta type cubes there is 1 to 1 mapping of the slices to the beta dimension. So all alpha-beta cubes in channel 1 have a dimension of 21 in the beta dimension. We only had to worry about mapping and overlaps in the alpha and wavelength dimension. This ensured that the cubes were aligned in the alpha-beta system.
I am not really sure what de-rotated cubes using more than 1 channels worth of data worth of data will be used for. Are you sure we want to allow the user to make these ? They seem a little confusing - but like I said you know better than me what they want these in commissioning for.

And back to SKYALIGN - yes I like that idea. That will be an additional header keyword that will be written to all IFU cubes. False if it is 'de-rotated".
Have you talked to NIRSPEC about if they want something similar ? James Muzzerole may want these types of cube when they have internal lamp data.

[stscijgbot]

Comment by Jane Morrison: [~dlaw]
I have looked at the code in
https://github.com/drlaw1558/jwst/tree/drl_abrot2
That calculates the angle to rotate the IFU. I might be missing something but I thought we wanted to build
the IFU cube on this rotated system and not just build the cube on the sky and supply a rotation in
in the wcs. Would it not be better to build the ifu cube on the rotated system. That way we have a better
1 to 1 mapping of columns of the IFU cube with beta slices. Isn't the point of building cube in the alpha-beta
system so that an output spaxel only have 1 slice contributing to it.

[stscijgbot]

Comment by David Law: [~morrison] I'll bounce the SKYALIGN suggestion off James and Nora.

Regarding multi-band cubes: the thought is mainly one of simplicity, if our 'de-rotated' cubes are produced just by having them aligned with the orientation of the first exposure in the sequence (and have fully accurate WCS) there is no a-priori reason to add all of the logic necessary to prohibit creating them in certain cases.  It's true that given the small rotation between channels a Ch1+2 derotated cube might not be quite as useful for defining the PSF as separate Ch1 and Ch2 cubes, but there may still be some convenience to be had in a combined cube in that you can then measure what the PSF is doing pretty well at all wavelengths without needing to create, align, and extract from multiple different cubes.

The code at [https://github.com/drlaw1558/jwst/tree/drl_abrot2] was just an example of computing the rotation and saving the value somehow, it didn't actually apply it like we want to do.  I've got a newer version though at [https://github.com/drlaw1558/jwst/tree/drl_abrot3] that does apply the rotation in a horribly-kludgy and approximate way.

[mperrin]

About a similar capability for NIRSpec - while I don't speak in any functional capacity for NIRSpec, speaking as a science user of NIRSpec this is very much a capability that's desired, and will be strongly beneficial for a subset of science programs (including GTO and ERS programs as well as planned GO programs). Detailed PSF calibrations, and the ability to reconstruct cubes in an instrument frame that's independent of sky orientation, will be a key enabler for high contrast PSF subtractions (e.g. spectroscopy of substellar companions < 1 arcsec from host stars).

[stscijgbot]

Comment by Jane Morrison: [~dlaw] in the equation
ab2radec_transform = input_model.meta.wcs.get_transform('alpha_beta','world')
temp_ra1, temp_dec1, _ = ab2radec_transform(0,0,wave[0])
temp_ra2, temp_dec2, _ = ab2radec_transform(0,-1,wave[0])

alpha = 0, beta = 0 and first wavelength value
can you remind me what an alpha =0 and beta = 0 or -1 means in alpha-beta space

[stscijgbot]

Comment by Jane Morrison: !Screen Shot 2020-05-20 at 8.33.17 AM.png|thumbnail!
Is this diagram still valid. So an alpha of 0 is the origin - what is beta = -1

[stscijgbot]

Comment by David Law: [~morrison] In that equation I've just taken one point at the center of the field of view (alpha=beta=0) and a second point offset by some small distance in beta (1 arcsec in this case) and transformed them both to RA/DEC coordinates to give two points that can be used to work out what the corresponding rotation in RA/DEC space is.  As such 1 arcsec is an arbitrary choice; small enough that it's guaranteed to be within the MRS field of view for which the distortion transforms are defined, and large enough that numerical precision on the coordinate transforms doesn't dominate the measured rotation angle.

So in that diagram, the only issue is that alpha=0 isn't the edge of the field, it's the middle.

As to why I chose to use beta=-1 for the secondary point, instead of +1, this is because the alpha/beta frame handedness is flipped relative to RA/DEC, so the rotation is the angle of the -beta axis measured E from N.

[stscijgbot]

Comment by Jane Morrison: [~dlaw]
I just pushed over some new code. The align along alpha beta is not working correctly. Below is an image of
three cubes: left: ra-dec, middle: de-rotated align alpha-beta, right alpha-beta cube.
I used only 1 file to make the cubes so I was thinking the de-rotated and alpha-beta cubes would look similar. But they do not. Something is wrong about determining the rotation angle - not sure what it is though. !Screen Shot 2020-05-22 at 2.00.19 PM.png|thumbnail!

[stscijgbot]

Comment by David Law: Hm, I'll see if I can take a look early next week.  If you're using test data that I messed with the WCS headers to mock up a non-zero roll it's possible that the problem is in how that was done rather than how cube build is working.

[stscijgbot]

Comment by Jane Morrison: [~nluetzgendorf] [~muzerol][~sargent]
I am looking into how to make de-rotated cubes (cubes aligned with the slicer plane) for NIRSPEC.
The first thing I wanted to do was to see if I could an ifu cube from a single file aligned with the slicer plane
using a similar method that MIRI does (coord_system = alpha-beta). Instead of going to ra-dec the cubes are created in the slicer plane. Nadia added the transform to stop at the NIRSPEC slicer plane a while ago.
I want to test that - do you have a good example of data - maybe CV3 data - that I could use to these this for NIRSPEC. A source (point source like) might be the best data.

[stscijgbot]

Comment by David Law: [~morrison] I took a look at the derotated_cubes branch and I think I've run down the problem; around line 1108 of ifu_cube.py the declination term isn't being converted from degrees to radians before applying cos(dec) to the delta-ra computation.

The xi=-xi flip in coord.py also needs to happen before the rotation matrix is applied.

Finally, it looks like the rotation information isn't being recorded into the output PC matrices of the cube yet, so I added

if (self.rot_angle is None):
self.rot_angle = 0.
ifucube_model.meta.wcsinfo.pc1_1 = -np.cos(self.rot_angle * np.pi / 180.)
ifucube_model.meta.wcsinfo.pc1_2 = np.sin(self.rot_angle * np.pi / 180.)
ifucube_model.meta.wcsinfo.pc1_3 = 0

ifucube_model.meta.wcsinfo.pc2_1 = np.sin(self.rot_angle * np.pi / 180.)
ifucube_model.meta.wcsinfo.pc2_2 = np.cos(self.rot_angle * np.pi / 180.)
ifucube_model.meta.wcsinfo.pc2_3 = 0

to the end of ifu_cube.py

If I make these three changes then I get derotated cubes that look about right to a quick inspection.

[stscijgbot]

Comment by James Muzerolle: [~morrison]  Yes, we do have an IFU exposure taken with an external point-like source from CV3 (PRISM only).  I'll try to dig it up and send it to you in pipeline-ready format later today.

[stscijgbot]

Comment by Jane Morrison: [~dlaw]
I made those changes and still it is not correct. I will continue to look for a mistake. I have pushed the code over. Have you made IFU cubes aligned with the local MRS plane using this method ?
Below is the rotated cube (left) on the right alpha-beta cube.

[stscijgbot]

Comment by David Law: Hm, looks like the updated code is working for me.  I just pulled over your new update, and below are the cubes that it's creating for a single exposure from that set.  Left panel is with 'world' frame, right panel with 'align_slicer'.  Which exact file are you using?

 

!cubes.png!

[stscijgbot]

Comment by Jane Morrison: I am using: det_image_seq1_MIRIFUSHORT_12LONGexp1_cal.fits
I believe it came from /ifs/jwst/wit/miri/cubetesting/MIRISim/TEST-SIM-10/

[stscijgbot]

Comment by David Law: I've been using the 1A example, will take a look at 1C

[stscijgbot]

Comment by James Muzerolle: [~morrison] you can find level 2a files here:  

/grp/jwst/wit4/nirspec/Muzerolle/for_jane.  If for some reason you'd rather have the level 1b files, let me know.  Since this is a PRISM exposure, the NRS2 file contains no useful data, but it's there for completeness.

[stscijgbot]

Comment by David Law: I'm getting good results with det_image_seq1_MIRIFUSHORT_12LONGexp1_cal.fits as well

[stscijgbot]

Comment by Jane Morrison: This is for the alph-beta type cubes. Which I need to change the name of since alpha-beta corresponds to MIRI not NIRSPEC. I am going to change the name of coordinate system from 'alpha-beta' to
'align-slices' since that is what we are doing. To not be confused with 'align-slicer' which is in a valid WCS I need to change the current 'align-slicer' which was just temporary until I could think of something better to
'rotate-slices" - what do you think [~dlaw] ?
The 'align-slices' (formerly alpha-beta) type cubes are limited to single exposures (in MIRI single channel)
are will likely only be used during commissioning. I am thinking they might help de-bug some of the problems we are having with the NIRSPEC IFUs cubes. Once I get these 3 type of cubes I can not imagine we will need any more.

[stscijgbot]

Comment by David Law: Hm, naming, always tricky.  Perhaps then we would have these options for coord_system:

'SKYALIGN': This is what's currently called 'WORLD', in which North is up and East left. Works with dithered and single exposures.

'IFUALIGN': This is what's currently called 'align_slicer' in which there is a fully valid RA/DEC world-coordinate WCS, but the zeropoint of the rotation is set such that the cube x/y axes match the slicer direction.  Works with dithered and single exposures.

'DEBUG_LOCAL': This is what's currently called 'alpha-beta' in which it uses the local internal coordinate system.  For MRS this is the true alpha-beta cubes, for NIRSpec it's whatever their slicer plane coordinate system is called.  This only works on individual exposures, and does not have WCS that maps to RA/DEC.  These are intended only for debugging during commissioning.  We could also just call this 'LOCAL', but 'DEBUG_LOCAL' makes very clear that this isn't a mode intended for general use.

Might be worth a separate conversation about whether SKYALIGN or IFUALIGN is the pipeline default.

Thoughts?

[stscijgbot]

Comment by Marshall Perrin: Speaking as an end user, I concur with David about the confusing-ness of having any WCS in meters. And speaking as an optical scientist, I'll point out we can use the plate scale at the slicer plane to convert from physical units at the focal plane to arcseconds on the sky. The necessary coordinate conversions are in the SIAF, for instance. It certainly seems preferable to me to have consistent units for the WCS between any of the SKYALIGN, IFUALIGN, or DEBUG_LOCAL options. At the very least, consistent between the first two of those.

[stscijgbot]

Comment by James Muzerolle: I think we're talking about two different products that have two different use cases.  The NIRSpec version of an "alpha-beta" cube, which corresponds to our slicer optical plane, is needed primarily for calibration, so that we can create cubes and extract spectra for our internal lamps. Most users probably will not need to make use of that, as opposed to the second version, the "align-slicer" cube, which is just sky coordinates but with the rotation removed so that it is aligned with the internal slicer plane orientation.  I think this is what is needed for cases such as PSF subtraction?

Since the slicer is an image plane within the instrument, the model transforms are set up to produce positions in physical size units; the IDT likes SI, so in this case it's meters.  We could apply a plate scale to convert to angular units, though that's not really necessary for internal calibration data.  The question is whether this would be something of interest to users looking at on-sky data?

[stscijgbot]

Comment by James Muzerolle: I like David's suggested names, except for 'DEBUG_LOCAL' since that is not optional for NIRSpec.  How about something like 'INTERNAL_CAL'?

[stscijgbot]

Comment by David Law: INTERNAL_CAL works for me

[stscijgbot]

Comment by Jane Morrison: Thanks it sound like we have a consensus - SKYALIGN, IFUALIGN and INTERNAL_CAL

James just double checking - for NIRSPEC - INTERNAL_CAL type IFU cubes. Will these cube be constructed from a single exposure ?

[stscijgbot]

Comment by James Muzerolle: [~morrison] yes, INTERNAL_CAL cubes will only be constructed from individual exposures.  We will not need to combine multiple exposures for any internal lamp calibration data.

[stscijgbot]

Comment by Jane Morrison: [~dencheva][~muzerol]
There might be an error in the NIRSPEC transform 'detector' to 'slicer'
Here are the steps I do
slice_wcs = nirspec.nrs_wcs_set_input(input, i) # i = slice number
x, y = wcstools.grid_from_bounding_box(slice_wcs.bounding_box, step=(1, 1), center=True)
detector2slicer = slice_wcs.get_transform('detector','slicer')
coord1,coord2,lam = detector2slicer(x,y)

The wavelengths returned (along the slice) are all close to zero for each slice.
Now I have gotten around this problem by also mapping the x,y values to the sky
using the detector to world transform: c1, c2, lam = slice_wcs(x, y)
I use those wavelength values which are fine.
I just wanted to mention this incase this is not how the detector to slicer transform is supposed to work

[nden]

@jemorrison Nirspec internally works with wavelengths inunits of meters. Can you confirm that the problem you are seeing is just reading the values in the correct units?

[stscijgbot]

Comment by Jane Morrison: [~dencheva] Ha that explains it. I did not realize the wavelength was also in meters.
When I convert from meters to microns I get the expected values.
So there is no problem with the "detector" to "slicer" transform for NIRSPEC.

[stscijgbot]

Comment by David Law: Just a quick note that it would be extremely helpful to change the default cube building weight function from MSM to EMSM (at least for MIRI) while we're making these changes.

[stscijgbot]

Comment by Jane Morrison: [~muzerol] When building NIRSPEC internal_cal type cubes this is how I have set up the cubes.
The across slice direction is the x ifu cube axis and the along slice direction is the y ifu cube axis.
I am forcing the ifu cubes to have a size of 30 in the across slice dimension so that each slice maps to 1 column of data an an ifu plane. Should I arrange the slices in order - 0, 1, 2, 3 ... or should I used the coordinates determined from the transform('detector', 'slicer') this results in odd slices
on left side and even slices on the right. I think it should be in slice order but I am checking cause the IFU cube I have made so far do not look correct.
When I map the x,y detector values to slicer values I get a range of -0.00116 to 0.00116 (in across slice dimension) and -0.00067 to 0.00067 in along slice direction. I thought the FOV was 3 X 3 arc seconds. So why do the along and across slice dimensions not cover the same region. This example I have given is for NRS1.

[stscijgbot]

Comment by James Muzerolle: [~morrison] The detector-slicer transform has the correct order (see the slicer geometry plot I attached on May 27).  The numbering is based on the order in which the virtual slits appear on the detector, which is different than on the sky.

The range of coordinates should be roughly 0.012 to 0.012 in the cross-slice direction and -0.006 to 0.006 along the slices (perhaps you added an extra zero by mistake?).  It is twice as large in the cross-slice dimension by design - the IFU optics introduces anamorphic magnification x2 in that direction so that the spectra are Nyquist-sampled.

[stscijgbot]

Comment by Jane Morrison: [~muzerol] I did miss type that . The range in the along slice should of been -0.006 to 0.006.
Just to be clean - the transform ('detector', 'slicer') is the transform from the x,y detector values to the slicer plane which is not on the sky? So I should not use those values to arrange the slices but
you the slice number instead ?
I have not wrapped my head around what the "slicer" plane is and how it relates to "sky"

[stscijgbot]

Comment by James Muzerolle: [~morrison] That's right, detector-slicer is the transform to the slicer plane, which is an internal image plane in the instrument at the IFU slicer optics.  This shows the optical path in the instrument (from ESA doc ESA-JWST-SCI-NRS-TN-2016-010):

!Screen Shot 2020-06-01 at 6.54.30 PM.png!

[stscijgbot]

Comment by James Muzerolle: Huh, not sure why that came out so large....

The slice numbers shown in the last plot you attached on May 27 has the correct ordering both on the detector and on the slicer plane.

[stscijgbot]

Comment by Jane Morrison: [~muzerol]
I am stuck. Maybe you can see what is wrong. I took the data in /grp/jwst/wit4/nirspec/Muzerolle/for_jane
ran assign_wcs on the data so I would have access to the wcs information.
I then produced a normal on sky IFU cube and an 'internal_cal' ifu cube.
The internal_cal one does not look correct. The slices seem confused.
Summary of algorithm for internal_cal cubes:
I first loop over all the slices to set up the WCS of the cube.
I set the wavelength sampling to be twice that for the normal on sky IFU cube because though the wavelength sampling for the on-sky IFU cube is set in a reference file to be 0.005 the roi in the spectral dimension is 0.01. So I made the spectral sampling (for now) = 0.01 in the internal_cal cube. When making cubes in the internal plane the overlapping routine is essentially a drizzle method. The slices match in a 1 to 1 correspondence in the across slice dimension. So the 2-D to 3-D mapping for normal cube build is broken down to a 2-D to 2-D mapping.
All the internal_cal IFU cubes will have 30 spaxels in the across slice dimension (for NIRSPEC that is the x dimension in the final cube). So slice 0 maps to the first bin in the x dimension in the ifu cube and slice 29 maps to the last bin in the x dimension in the ifu cube.
I then transform each detector pixel to it value in the slicer plane using detector2slicer = slice_wcs.get_transform('detector','slicer') for that slice. I find the pixel corners in the along slice and wavelength dimension and do a drizzle like mapping /overlap determination to final IFU plane.
I have put the two ifu cubes in /grp/jwst/ssb/morrison/ForJames
Any ideas ?

[stscijgbot]

Comment by Jane Morrison: So this picture is for about the same wavelength plane in the IFU cube. The image on the left is the plane on
the sky and the image on the right is in the internal_cal coordinate system. At least the internal cal looks like the source in correctly aligned. The odd columns (odd slices seem to be missing). I will look more at what is going on with odd slices. !Screen Shot 2020-06-03 at 7.40.07 AM.png|thumbnail!

[stscijgbot]

Comment by Jane Morrison: [~muzerol]
So I am looking again at the picture you provided on the "Slice geometry in the slicer plane"
So is that how I should arrange the slices - in that order - instead of arranging them in order of 0 to 29.

Also I have found another problem. For the internal_cal reference IFU I have been setting the across slice dimension. This makes determining the overlap between along slice, wavelength dimensions easier. As I mentioned earlier it becomes a drizzle like problem. How I do this is I take each detector slice x,y value
and find the along slice, wavelength of the corners using the 'detector' to slicer' transform.
So I map (x,y), (x,y+1), (x+1, y+1), (x+1,y) - but the way the detector to slicer transform works adding 1 to the x,y values can result in NAN values for the returned along slice, wavelength values.
For example for slice 29 there are 14492 pixel values but when I map the corners of the 14492 I get
451 pixels that NaNs for the corners that add 1 to x or y (3%). So I can not map those 451 pixels to the slicer plane. I could not do the "drizzle like method" and for NIRSPEC internal_cal still do a point cloud technique.

[stscijgbot]

Comment by Jane Morrison: [~muzerol][~nluetzgendorf]
This might require a telecon. As far as I can tell the algorithm for creating internal_ifu cubes is working as expected given the WCS information.
This is a rather complicated picture:
Upper left: image of cal (after photom step)
Upper right: diagram I made taking various slices and mapping them to the detector space (using the bounding box of the slice)
Lower left. - zoom of the upper slices and lower slices. If the order of the slices in upper right is true then
slice 30 (has large fluxes in on the slice) and the bottom 3 slices have MUCH less (but the very bottom slice is slice 29). This makes no sense to me
Unless the picture in the upper right is WRONG. I looked at Docs and I found the image in the lower right had plot. That plot - to me - implies - ordering of slices on the detector is from 30 to 1
!Screen Shot 2020-06-03 at 12.44.38 PM.png|thumbnail!

[stscijgbot]

Comment by James Muzerolle: [~morrison] the numbering in JDox is not consistent with the instrument model algorithms delivered in 2016.  I'm still confused as to why this has changed; nevertheless, assign_wcs is using the original slice numbers as shown in the slicer geometry plot I attached on May 27.  I just now looked at the cube you generated, it looks like using that numbering should solve the problem.  For example, slice 29 has the brightest part of the source, but should be on the left side of the cube, while slice 28 should be the farthest from the source position, which makes sense since it has the weakest counts.

Maybe [~nluetzgendorf] can comment on the numbering scheme; will the OTIS model update use the sequential numbering shown in JDox?  If so, that may require further changes to the cube_build code so that it can use both the CV3 and OTIS models (and any future updates after that).

[stscijgbot]

Comment by James Muzerolle: As for the NaNs issue, I think that gets populated for any pixel outside of the bounds of any slice, such that there is no valid WCS.  Would it work to just use the wavelength interval from the adjacent (inside) pixel?

[stscijgbot]

Comment by Jane Morrison: [~muzerol]Ok thanks. Remapped slices today according to your figure but I messed it up. So I got myself really confused and that is when I saw the jdox picture. I just re-did it - correctly this time and it looks good. I have a few more things to fix but I am now on the right track.
This is how the internal_cal image looks for wavelength plane at 1.70 microns
!Screen Shot 2020-06-03 at 2.57.54 PM.png|thumbnail!

[stscijgbot]

Comment by James Muzerolle: (y)

[stscijgbot]

Comment by Howard Bushouse: Fixed by [https://github.com//pull/4974]

[stscijgbot]

Comment by David Law: Working as expected last time tested, but currently running into some new bugs.  This ticket can be closed, will file a new ticket on recent errors.

[stscijgbot]

Comment by David Law: Working as expected; this ticket can be closed.