When simulating a subarray the stars were not put in the right place about mirage HOT 7 CLOSED

Hmm, interesting. I know I've checked full frame vs subarray simulations before using the same RA, Dec values and had sources show up where I expected. Maybe I was checking some special case or something. One of the things I want to work on when I get back is to add a proper testing module to the repo that uses Jenkins to automatically run tests each time the code is updated.

from mirage.

The only case I can think of that would work is a subarray where self.subarray_bounds[0] and self.subarray_bounds[1] are equal to zero. It happens that none of the NIRISS subarrays are of that sort in the DMS coordinates, although several of them are that way in the detector coordinates.

from mirage.

@bhilbert4 do you have a strong preference for Jenkins compared to Travis? I am using travis for https://github.com/spacetelescope/pysiaf and I could try to set it up for mirage.
Let me know.

from mirage.

I don't have any preference between Travis/Jenkins. I think output file sizes may be a problem for testing on github, although I'm not positive.

from mirage.

I just did a quick check for NIRISS and NIRCam. For NIRCam I made a full frame and a SUB160 exposure, both with RA, Dec set to (4., 45.), and both using a point source catalog with a single source at (4, 45). So I expect the source to show up at the reference location in each of the exposures, which it did.

Repeating the same thing for NIRISS, using full frame as well as NIS_AMI1 and NIS_AMI4, the source did not show up in the subarray exposures. Very strange. I'm trying to think what code NIRCam is using that NIRISS is not, or vice versa that would result in different behavior.

from mirage.

My test run of the code is still running hours later, so I am not sure what the problem is with the machine I am using. I really have to wait until i can ssh to witserv3 to look at this again. But the fix I posted before should still apply here so you might look at the self.subarray_bounds[0] and self.subaray_bounds[1] values for NIRCam as opposed to NIRISS to see if there is any difference. The SIAF files may be treating things differently for the two cases, although it is difficult for me to imagine why it would be so.

from mirage.

This has been fixed (although it seems to have reappeared when trying to use pysiaf to get the aperture information...). I am closing this issue.

from mirage.