Closed Cameron-Van-Eck closed 4 years ago
ijiraq
commented
4 years ago This appears to be a service layer problem in how cutouts are done. It might relate to the multiple axis or it might also be about the size of the file and how cutouts are done when their are multiple dimensions.
at88mph
commented
4 years ago Hi Cameron,
There is an issue where the Polarization WCS is unreadable/unusable in that file. We're working on a bug fix now.
pdowler
commented
4 years ago The polarization WCS issue was fixed, but I also determined that the fits wile in question uses the PC matrix + CDELT values for spatial WCS. Our current s/w that extracts WCS from the file in order to compute cutouts only supports CD matrix. I will create an issue (bug) in the correct place and we'll determine when we can get someone to work on the fix.
ijiraq
commented
4 years ago Adding support to PC matrix values is now being worked on. @pdowler where is the 'the correct place' that you created an issue in to fix this? I would like to close this issue and link to the other location.
jburke-cadc
commented
4 years ago Hi Cameron,
Yesterday March 18th we released a software fix that supports PC matrix keywords in the FITS header. I ran your example vcp command which gave me a cutout that matches the requested coordinates. Thanks for the very detailed description. It really helps when fixing a bug.
Closing this issue.
Hello:
I want to report a problem I ran into using vcp. I have some very large FITS files (67 GB each) on CANFAR, from which I want to download small regions. When I use the pixel-based cutout method (file.fits[xmin:xmax,ymin:ymax]), it works as expected, and I get a file with the expected dimensions. A great feature, thanks for making it!
What is not working for me is the coordinate based cutout method ( file.fits(ra,dec,rad) ). On my files it consistently fails with "HTTPError: 500 Server Error: Internal Server Error", and I am unable to diagnose further (full error log below).
This is simply speculation, but I wonder if this may be a result of my FITS files having 4 axes (3 non-degenerate)? I went digging for a 2D fits image and tested it, and it worked fine. This is potentially a big problem for those of us working with radio data, especially polarimetry data, because ALL of our data natively has 4 axes (often 1-2 of these are degenerate, but not always). All of the files we get from the VLA, and from ASKAP, are 4D by default (I don't even have any 2D files to test with; I had to go digging into the CANFAR public archives to find one!).
Any chance you could look into this? For clarity: I'm not asking for any ability to cutout based on the additional axes, just RA and Dec are fine. I wrote a little work-around script to do the coordinate-to-pixel conversion and then submits a copy request based on the pixels, and that seems to work OK in the mean time, but I'd like a cleaner solution in the long run (particularly when sharing data with collaborators).
Thanks a lot, Cameron
Diagnostic information: OS: MacOS 10.13.6 Python version 3.7.1 (Anaconda installation) vos version 3.0.14
Attempt on 4D file (sidenote: this file should be public, if you want to test yourself): vcp -d --vos-debug vos:cirada/polarimetry/ASKAP/SB10168/image.restored.i.SB10168.contcube.fits(326.22,-50.8933,0.01) ~/Desktop/image.fits 2>&1 | tee -a vcp_log.txt Log:
Attempt on 2D file: vcp vos:/SITELLE/Abell2390/A2390NW_C4.merged.InterferogramMerger.deep_frame.fits(0.085658,0.09555,0.01) ./image.fits Log omitted. The file looked as expected, with the correct coordinates and size.