...

WEAVE Open-Time Phase 2. Instructions for Applicants

Summary of actions

The instructions below are mainly aimed at PIs who will request assistance to:

Communication with the PI

The WEAVE Automated Submission Platform (WASP) automatically emails the principal investigators (PIs) with submission deadlines, validation acknowledgements and any other important information concerning the preparation of phase 2. The first two emails contain the following (the subject line is provided):

...

emails contains the credentials to log onto WASP. Subject line is:

^{Subject: [WEAVE] Account created for WEAVE observation preparation}

...

...

General assistance can be provided at the following emailemailing:

Purpose of the phase 2

The purpose of the phase 2 is the upload of a FITS catalog containing fiber positions on sky, and observing blocks (OB) written in XML describing the necessary observations to the submission platform WASP, maintained by CASU in Cambrige (IoA). At the beginning of every trimester, the uploaded, validated and selected OBs are ingested into the observing queue at the WHT.

The kick off of phase 2 is a simple catalog of targets in CSV format prepared by the PI following the instructions provided on this page. ING can provide assistance with the preparation of the aforementioned catalog, and afterwards ING can also process it to make the FITS catalog and the XML OBs, and eventually upload to and validate on WASP on behalf of the PI.

An XML OB contains the instructions to execute the observations: instrument setup, telescope pointing, guiding star, dithering, exposure times, observing constraints and calibrations (one lamp flat and two arcs, before and after the science exposures). The following is an example of the XML code of an OB with comments for users: WC_2023A1-lifu_01-tgcs.xml.

Every observed OB is reduced and calibrated using automatic pipelines at CASU (IoA, Cambridge). Data is flux calibrated using a standard sens functions. However, applicant scan submit their own OBs for observing flux standards along with the science OBs. Every trimester we accept a maximum of 100 OBs  per programme.

Below we provide an example of real observations made from a simple OB which consists of 3 exposures 1020s each following a 3-point dithering pattern in LIFU low-resolution mode and arbitrary position angle: 

CSV catalog:

...

^{TARGID,TARGNAME,GAIA_RA,GAIA_DEC,PROGTEMP,OBSTEMP,IFU_DITHER
NGC3158,NGC3158,153.460497,38.764898,41331,NBCEB,3}

Validated FITS catalog on WASP:  WS2022A2-002.fits

Validated XML OB on WASP and ready for ingestion into the observing queue: 1713807920_1.xml

Log entry as a result fo the execution of the above OB. Note that the target coordinates correspond to the center of the field of view, not the centre of the LIFU array.

...

Phase 2: the short guide

https://ingpublic.atlassian.net/wiki/pages/createpage.action?spaceKey=ING&title=WEAVE%20Open-Time%20Phase%202%3A%20The%20Short%20Guide

LIFU mode: catalogue preparation

Target declination and right ascension limits

The current target declination limit is -25º. Objects with a declination lower than that cannot be observed. 

WASP sets limits to allowed target RA and Dec, and it will not validate your OB if your target coordinates lie outside the limits for that the trimester. See below the allowed RAs RA ranges for each trimester.

Total requested time

The total length (counted as science exposure time) of all the submitted OBs can't exceed the science time allocation of your proposal (see the time allocations).

...

3. Filling in a simplified CSV version of the catalogue template. Below it's an example of this simplified template and 4 catalogue rows that each describe an OB definition:

Filling out the catalogue template with targets

...

TARGPROG (optional)
TARGID
TARGNAME
GAIA_ID (if available)
GAIA_DR (optional)
GAIA_RA
GAIA_DEC
GAIA_EPOCH (optional)
GAIA_PMRA (if available)
GAIA_PMDEC (if available)
GAIA_PARAL (if available)
PROGTEMP
OBSTEMP
IFU_DITHER
IFU_PA_REQUEST (if necessary)

TARGPROG

TARGPROG is an optional column, to be filled out at the discretion of the catalogue creator.

TARGID and TARGNAME

This parameter is used to group IFU observations of the same target, in cases where stacks are required. This helps the Core Processing System (CPS) responsible for obtaining the data, to identify cases where the same astrophysical target is observed but the OBs executed were not related (via for example the "chained" directive).

An example would be LIFU observations of the core of M33. If a user requires 3 OBs, each with different dither positions, then the CPS could not ordinarily stack these data, because they do not share the same Central CNAME (CNAME is the WEAVE object name from coordinates). In the input FITS catalogue, these observations are represented by 5,427 rows: 603 fibres, dithered 3 times for 3 OBs. Each of these rows must be tied together by a common TARGNAME, e.g. "M33 bulge". This indicates to the CPS that these observations should be evaluated for stacking.
Image Removed

...

Above: Three LIFU dither positions centred on a putative target. This information must be encoded in the input FITS catalogue, but grouped by common TARGNAME.

It is not always true that IFU observations with common TARGNAME will be stacked. Only common TARGNAMEs with sufficient overlap will be stacked by the CPS. However, if Contributed Data Products exist to create larger mosaics from these data, then they should use the common TARGNAME to group L1 products.Image Removed

...

Above: Example LIFU coverage of an extended source. Each colour here represents an OB. Within each pointing there would be a series of dithers (as per previous Figure). Whilst these pointings might share the same TARGNAME ("M33"), the CPS would recognise these as a mosaic and not stack them into a single LIFU data cube.

...

^{OB1: TARGNAME = “M33” TARGID = “M33 bulge”
OB2: TARGNAME = “M33” TARGID = “M33 disc NE”
OB3: TARGNAME = “M33” TARGID = “M33 disc NW”}

PROGTEMP

The PROGTEMP code is an integral part of describing how the instrument is configured. This parameter encodes the requested instrument configuration, OB length, exposure time, spectral binning, cloning requirements and probabilistic connection between these clones. We refer registered WASP users to the PROGTEMP form: http://wasp.ast.cam.ac.uk/progtemp(there is also a copy at ING: https://a.ing.iac.es/weave/progtemp.php ).

Please use this exposure time calculator for your signal-to-noise calculations: https://a.ing.iac.es/signalWEAVE/. There is more information, including a downloadable version, at WEAVE Exposure Time Calculator .

Instrument configuration

Check first what instrument modes are available in the ING announcement of opportunity. 

OB length

This PROGTEMP component specifies the overall OB length (inclusive of overheads). Please be aware that not all OB lengths are available. 

Arm exposures

It defines how the time within the OB that you wish to observe the target is divided up, by specifying the number of exposures and exposure time within the stipulated OB length.  The listed options of exposure time splits correspond to science open-shutter times (note that every exposure incur a 3-minute overhead).

Binning in the spectral direction

...

Furthermore, if PIs want to chain these OBs together, such that the observation of one of these clones increases the chance that the remaining OBs in this group are observed, then a "+" will be added to the end of PROGTEMP. The "+" instructs the WEAVE scheduler to increase the (internal, programme-specific) weight of all OBs in this group. This provides a mechanism to ensure that once a series of observations are started, completion of the chain becomes a progressively higher priority above other OBs from this programme.

OBSTEMP

Whilst PROGTEMP deals with “how” a target is observed, OBSTEMP deals with “when” a target is observed – namely setting the observational constraints required to optimally extract scientific information from the observation.

...

An instrument-wide lower limit of 30 degrees ensures sky brightness gradients and scattered light effects are kept to a minimum. This limit applies to any observations set with “0 degrees (no constraint)”.

Sky brightness

The maximum V-band surface brightness of the sky (mag / sq. arcsec) required to observe the target. 

The dark-of-moon sky brightness varies by a few tenths of a mag depending on ecliptic and galactic latitude and phase of the solar cycle. With the moon up, the sky can be up to ~4 mag brighter than dark-of-moon, depending on lunar phase, elevation and angular distance from the target. Science observations are carried out mainly during astronomical night, but those OBs tolerating moonlit skies can also use the latest bit of evening twilight, or the earliest bit of morning twilight – the only relevant criterion is sky surface brightness. No observations will be carried out when the sky brightness exceeds that at full moon.

GAIA specific columns

We strongly urge PIs to use the DR3 reference epoch for WEAVE targets.

...

Information from Gaia is expected to be provided exactly as it is retrieved from the Gaia archive, so parameter definitions, data formats and units remain the same. Please consult the Gaia webpages to further understand their data model.

IFU_PA_REQUEST

IFU_PA_REQUEST allows the catalogue provider to specify a rotation angle (position angle) of the LIFU, if this is required.  Any dithering requested for the field is applied to the rotated LIFU frame.  If a specific PA value is not requested, then the following defaults are applied: IFU_PA=0° (for declinations lower than 28.7°) and IFU_PA=180° (for declinations higher than 28.7°). Note that the requested IFU_PA could be changed by the IFU workflow software if a suitable guiding star cannot be found at the requested PA. Below it's a plot which shows how the PA is changed to find a suitable guiding star.Image Removed   suitable guiding star (from the requested PA marked as a blue cross to the final PA marked as a black cross).

...

The table below shows the allowed values for the PA depending on minimum elevation requested in the OB and the target’s declination. Following are plots showing two cases, for better understanding of the PA ranges in the table.

...

IFU_DITHER

IFU_DITHER allows the PI to specify the dithering strategy for their observations, but may alternatively request not to dither their observations, with the understanding that this will not provide full spatial coverage of their requested field. PIs may request the preset -3, 3, 4, 5 and 6-dither patterns. The LIFU preset patterns will be properly rotated according to the position angle of the observation. 

...

For custom dither patterns, constraints on the dither step size are imposed by the WASP to ensure that the guide star remains within the guiding camera field of view. From the perspective of IFU users, careful consideration of the dithering options should be made. Below it's an example of custom dithering. Note that pointings are provided for each dither, rather than the dither pointings from an initial position. The three pointings provided in the example below would be executed as part of one only pointings from an initial position. The three pointings provided in the example below would be executed as part of one only OB. Note that TARGID must be equal to TARGNAME in every row. The maximum allowed distance between (consecutive, for instance, exposure order 4 and 5) dither points is 4 arcsec while the maximum overall dither distance across all dithers can exceed the maximum permitted dither 10 arcsec. Minimum distance is ~0.3 arcsec. Dither point positions cannot be repeated within an OB.

Summary of table columns and examples

Aladin overlays of the LIFU footprints

Aladin overlays can be useful for preparing your observations. To use the Aladin overlays below, follow these instructions:

1. Download the vot files linked below.

2. Open Aladin and enter an object name in the command field, ex. 'M51'.

3. File → Load instrument FoV.

4. In the emerging window, click on 'File' and browse for a suitable vot file.

5. Click to submit. The vot file will load as a layer with a given colour.

Description and VOT file	LIFU FoV and sky bundles	LIFU FoV
Photo of a real view of the LIFU unit using fibre back illumination.

Image Removed

Image Added

Image Removed

Image Added

No dithering (as seen in Aladin) Download VOT file: https://cloudone.ing.iac.es:8081/sharing/dknwFwdzg

Image Removed

	Image Added	Image Modified
3-pointing dithering (as seen in Aladin) Download VOT file:  https://cloudone.ing.iac.es:8081/sharing/uYKm7kMqL	Image Modified

Image Removed

Image Added

6-pointing dithering (as seen in Aladin) Download VOT file: https://cloudone.ing.iac.es:8081/sharing/WZ9kEUUVb

Image Removed

Image Added

Image Removed

Image Added

Catalogue upload to WASP

The edited catalogue must go through the IFU workflow, a set of scripts which will make a version of the FITS catalogue suitable for uploading to WASP (http://wasp.ast.cam.ac.uk/catsubmit/upload) for validation.  First log on using the provided credentials (the ones emailed from WASP), note that you need to register your IP at http://wasp.ast.cam.ac.uk/ipsubmit/upload first. See below the tab used for uploading the catalogue.

...

At ING, we can provide assistance in guiding you through the different stages of the IFU workflow package, or we can even process your catalogue provided in any of the formats described above, on your behalf. In this latter case, simply email your catalogue to the contact below:

LIFU mode: OB preparation

...

At ING, we can provide assistance in generating the OBs from the CNAMEd catalogue, please contact:

OB upload to WASP

The processed OBs can be then uploaded, as a tar file if many, to http://wasp.ast.cam.ac.uk/xmlsubmit/upload (see below). Remember to log on first.

...

In the figure below we show an example of 6 OBs uploaded whose validation failed (the generated report will tell you why). The "Submission Management" button gives access you to all the catalogue and OB uploads made by the user. Note that if you have requested OB repetitions (for instance, PROGTEMP=41331.5, or 5 OB copies), then only one OB is validated on WASP (not 5 OBs following the example). The OB copies are actually made at the time they are ingested into the observing queue according to the information encoded in PROGTEMP.

...

Observations and follow up

...