maravelias.info

When creating finding charts for observations with the OSIRIS instrument on GTC you need to check the field-of-view (fov). With the Aladin Sky Atlas it is easy to download an image and overplot an instrument footprint (Edit > Load instrument footprint). Although there is a selection of instruments, by default the OSIRIS is not included. It is possible however to “create your footprint” which opens a link to an online editor.

Using this and the information collected from the manual and the web for OSIRIS I created a footprint that displays the fov for the imaging (larger box) along with the fov for the Multi-Object Spectroscopy (inner boxes) which display the two CCDs with the gap in between. Then, it is easy to place the footprint to the exact coordinates you wish in order to include (or exclude) sources of interest, check which parts are outside the fields or in the gap.

You can find the file here: gtc-osiris-v2.vot (better right click on that and save as…)

To properly process data (either imaging or multi-slit spectra) from the OSIRIS instrument at GTC you need first to convert the original data to single images. The raw fits data contain two extensions corresponding to the two CCD sensors. To combine these into a single 2110 X 2051 pixels image (including the gap between the sensors) they provide with a convenient IRAF script called Mosaic Tool. This takes into account more than simply adding the extensions. As written in the ReadmeFirst.txt file:

(i) corrects the input OSIRIS pre-image for overscan to provide a uniform background, (ii) executes the mosaic assembly according to the rotation/traslation parameters obtained from the MD Polynomial Manual (current version: V5; see contents of the attached MD_polynomials.pdf file) on a new created image, (iii) copies the zero extension of the input image in the new one, and (iv) updates the WCS keywords. Such updating consists in switch the input reference pixel (CRPIX1, CRPIX2) to the center of the mosaic (see MD_polynomials.pdf, p.12) and calculate the celestial coordinates (CRVAL1, CRVAL2) corresponding to the new reference, based on the original WCS parameters. Hence, the correction of the astrometric solution is the same of the input image.

So it does quite a work! To run it you have to start IRAF, define the task and apply it to an raw image:

-->task $mosaic_2x2=mosaic_2x2_v2.cl
-->mosaic_2x2 0002604740-20200628-OSIRIS-OsirisBroadBandImage.fits

(the name for the task, in this case mosaic_2x2 is not really important). When I tried that (using PyRAF v2.1.5 with IRAF 2.16.1 on a Debian 10 machine) I got an error:

Traceback (innermost last):
File "", line 1, in
File "", line 16, in mosaic
iraf.noao.PY()
AttributeError: Parameter PY not found

which I couldn’t understand. Even after contacting the support the mystery remained. Back in early August we had only a couple of images from our pre-imaging run (and not time to waste…) and the support team was kind enough to do it for us. But now that we have the actual spectroscopic data the images are way too more to ask again for this. Therefore, I tried to search a bit deeper than the first time.

I started by checking the mosaic_2x2_v2.cl file, and I removed all tasks to search where could be the problem. So I edited it to run this:

 
procedure mosaic (fobjeto)

file fobjeto {"",prompt="Object file:"}


begin

string objeto
file   text

objeto=mosaic.fobjeto

noao.
noao.artdata.
noao.imred
noao.imred.bias.
images.imgeom
ctio

#stsdas
#toolbox
#imgtools

end

In this form it only calls the basic packages of IRAF. Still though, when I attempted to run it again I took the same error! So the problem was already at the beginning. Then, I noticed these dots after the packages (e.g. noao, noao.artdata.) where obviously python was trying to get a non-existing attribute. After removing these dots it actually proceeded! Only after this revelation, it came to my mind to actually try the IRAF cl directly (when you have the python supported version there is no need to look back to cl!). However, it made a difference as (obviously) the cl doesn’t care about the cots… So the problem was python specific.

The script continued running only to … stuck again:


Traceback (innermost last):
File "", line 1, in
File "", line 44, in mosaic
iraf.imcreate(image = 'CCD_mosaic.fits', naxis = 2, naxis1 = 2110,naxis2 = 2051,pixtype = 'real')
AttributeError: Undefined IRAF task `imcreate'

However, this is easily interpreted. imcreate is a task in the ctio package, which is external (not part of the original core of IRAF). So you need to find the ctio package and put it under the iraf/extern/. This was actually not easy to spot since the support of IRAF by the STScI has dropped and most links are broken. The package is supported by the iraf-community, but I didn’t try to check exactly how to download (as I didn’t find it under my iraf/ directory). On the other hand, I found an alternative (in the iraf.net/forum) using the mkpattern task, under the artdata package which is already loaded in the file. Then, I just replaced the following line:

imcreate(image="CCD_mosaic.fits",naxis=2,naxis1=2110,naxis2=2051,pixtype="real")

with

mkpattern(input="CCD_mosaic.fits",pixtype="real", ndim=2, ncols=2110, nlines=2051)

and all problems are finally solved! The script runs to the end and provides the dinal mosaic image.

Bottomline, or what to do in three single steps

• If you are running cl/ecl directly AND have ctio package installed you don’t need to do anything
• If you are running cl/ecl directly and you don’t have ctio, just replace imcreate with mkpattern
• If you are running on python then remove the dots when the IRAF packages are called

I would therefore strongly suggest the support team to remove the dots and replace the imcreate task so that it can work in all cases.
(For any potential user here is my modified version: mosaic_2x2_v2_gm.cl.txt – remove .txt)

The pandemic of Covid-19 has obviously affected our observing runs also. ESO is (still) totally shut down while GTC after some off period it seems that it is under some limited operation.

Our accepted observing program with GTC includes Mulit-Object Spectroscopic observations with the OSIRIS instrument. For this we need to prepare masks, i.e. metal plates on which a number of slits is cut to allow the light of specific targets to pass and acquire their spectrum. In order to optimize the positioning of those slits (and make sure that they are placed on the correct coordinates) we have asked for pre-imaging, e.g. the acquisition of short exposures of the FOVs we have requested (for all our targets). With these and the appropriate software (Mask Designer) it becomes easy to create the masks.

Some weeks ago we actually received (quite unexpectedly, given the pandemic status) a couple of images. That allowed us to prepare the corresponding masks (after resolving all technical difficulties and questions of course). An example of these masks is shown below for the galaxy IC 10. When creating the mask we have to avoid slits that result in overlapping spectra (because we will end up with useless data). That’s why we need to prioritize our targets and select the best combination which will allow for the maximum non-colliding number of targets to be observed, respecting all constraints imposed by the program and the instrument involved. Although mask designing with modern software tools can become easy it is still a time-consuming step that needs caution and accuracy.

The image shows the mask designed for the galaxy IC 10. The small white line are the slits with the corresponding spectra visible as vertical thick green lines. Smaller lines correspond to fiducial stars, i.e. stars that help to the alignment of the mask. The yellow box corresponds to the physical limits of the maks. The background image is a short exposure of IC 10 in the r band.

So, the masks have been prepared, verified, constructed, … and now we wait for the real spectroscopic observations to be obtained! Fingers crossed!

note: the current article has been written originally for the ASSESS group.