Change page style: 

Multi-Object Spectroscopy with GMOS-N/S and FLAMINGOS-2

This is a top level summary page about Multi-Object Spectroscopy (MOS) at Gemini.

Capabilities
Timely preparation and pre-imaging
The mask design process
GMMPS -- Download (PIs must use latest version)
GMMPS -- Documentation (external link)
GMMPS -- Getting started
GMMPS -- Conflicts with Ureka / AstroConda

 

Capabilities:

(Note: The FLAMINGOS-2 MOS mode is still to be commissioned)

GMOS-N/S FLAMINGOS-2
Slit placement area 5.5 x 5.5 arcmin
5.7 x 2.0 arcmin
Minimum slit width 0.5 arcsec
0.18 arcsec
Max number of slits
(depending on slit length, disperser, filters, etc)
50-500 30-150
Max number of masks in instrument 18 9
Mask design from RA/DEC catalogs yes yes
Mask design from pre-imaging yes yes
Nod & Shuffle yes no
Dispersive elements all all

 

Timely preparation and pre-imaging

Multi-object spectroscopy (MOS) with Gemini is based on individual slit masks. The masks must be designed either from pre-imaging data, or from object catalogs with accurate relative astrometry, using our mask making software (GMMPS). This process causes delays with respect to normal observations, and a timely preparation by the PI increases chances for observations. This holds in particular for the Fast Turnaround program (short lifetime) and FLAMINGOS-2 (cryogenic; limited number of opportunities for mask installation).

Pre-imaging is always executed in queue mode, usually as soon as the field becomes visible. The time for pre-imaging must be requested during Phase I, and the observations are defined as part of the Phase II process. Requesting very good observing conditions for the pre-imaging may cause delays in the mask design, lowering chances for program completion. MOS masks are normally cut twice per week following specific deadlines.

PIs will receive instructions by e-mail on how to retrieve the reduced and co-added pre-images. The pre-images take into account detector gaps and relative detector positions while leaving optical distortions untouched. The mathematical transformations used to translate the source positions in detector coordinates into physical coordinates (mm) in the mask plane depend critically on exactly this setup. It is strongly recommended to use the images provided by Gemini to avoid flawed mask designs. The co-added images are averaged and in units of in e-/pixel.

Imaging obtained in a prior semester can be used for the mask design, provided that the acquisition stars and science targets do not have high proper motion. If you are in doubt about whether existing pre-imaging can be used for your mask design, please contact the Gemini HelpDesk.

 

The mask design process

The mask making software, GMMPS, is at the center of the mask design. The starting point is a list of relative object positions in detector coordinates. We refer to it as "object table", or OT (usually a FITS table), not to be confused with our Phase II Observing Tool. The OT can be obtained either from pre-imaging data, or using a non-linear transformation of a list of accurate, relative celestial coordinates.

GMMPS produces one or more mask designs ("object definition files", or ODF) with maximum slit density from each OT. The PI checks the ODF FITS tables in GMMPS for consistency. Upon loading an ODF, GMMPS allows to optimize the central wavelength to avoid certain wavelengths falling onto the detector gaps (GMOS only).

The Phase II definition of the spectroscopy observations depend on several mask design parameters, such as pointing, position angle, grating, filter, and Nod & Shuffle parameters. GMMPS displays these parameters when loading an ODF, and the PI must copy them into the Phase II Observing Tool.

Once the mask design is finished, the PI uploads the ODF FITS using the Observing Tool. We will double-checked the designs and initiate the cutting process. The masks are then sent to the summit where they await installation and final verification in the instrument.

 

GMMPS -- Getting started

 

 

GMMPS -- Conflicts with Ureka / AstroConda:

Users have experienced Python / numpy version conflicts if GMMPS is run from a terminal that has an active Ureka (and possibly AstroConda) environment. While we are trying to better understand this issue, run GMMPS from a terminal without Ureka / AstroConda setup.