WEAVE Open-Time Phase 2. Instructions for Applicants

Important links and documentation

WEAVE Automated Submission Platform (WASP):  http://wasp.ast.cam.ac.uk/

IFU workflow package: https://ingbitbucket.ing.iac.es/projects/WVSWG/repos/ifu/browse/workflow

WEAVE Open Time programme: https://www.ing.iac.es/astronomy/observing/WEAVE-OT.html

A detailed description of how the observations are processed and eventually released can be found in the WEAVE data model documentation:

1. Login to WASP or the OR.
2. Click on ("Tools" and select "Data Model").
3. In section "Resources", click on the "Documentation" tab and download WEAVE-ICD-030: "Interface between SPA and SWG/QAG (info for WASP etc)".

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):

1. An email containing the credentials to log onto WASP:
   

   Subject: [WEAVE] Account created for WEAVE observation preparation

2. A following email contains information about the opening of the OB submission window:
   

   Subject: [WEAVE-WASP] 20XXXX WASP upload window now open
   
   

General assistance can be provided at the following email:

weave_open_time_support@ing.iac.es

Summary of actions

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

weave_open_time_support@ing.iac.es

LIFU mode: catalogue preparation

Target right ascension and declination limits

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 trimester. See below the allowed RAs for each trimester. The declination limit is -25º. 

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).

Preparation of the catalogue

The catalogue can be prepared in three alternative ways:

1. Filling in the FITS catalogue template provided on WASP. Log on to WASP with your credentials. Go to "My survey" and click on "Download template".

2. Converting the above FITS catalogue template into CSV and filling in.

3. Filling in a simplified CSV version of the catalogue template. Below it's an example of this simplified template and one target:

<filename: WS2023B2-001_target_list.csv>

TARGID,TARGNAME,GAIA_RA,GAIA_DEC,PROGTEMP,OBSTEMP,IFU_DITHER
IC768_1,IC768,76.7836980,18.1489034,61331.3,DAFEA,3
GHMon,GHMon_NW,32.591451,23.910124,60881,IADEE,4
SN2024gtp,SN2024gtp,102.644083,+68.252231,43331.3,DACEA,6
M101HIIregionC1,M101HIIregion,161.2533346,-11.7653604,51001.7+,AAAEA,0

Filling out the catalogue template with targets

Any of the three catalogue templates above (FITS, CSV, simplified CSV) can be filled in with targets. These are the requested columns (the rest are optional):

TARGPROG (optional)
TARGID
TARGNAME
GAIA_ID (if available)
GAIA_RA
GAIA_DEC
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.

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.

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.

The TARGID is the target identifier and it is mandatory that this column is filled in.

For IFU fields, this is the OB-specific descriptor of the field.  In the first example above, this could be a simple numerical identifier for each OB:

OB1: TARGNAME = “M33bulge” TARGID = “M33bulge1”
OB2: TARGNAME = “M33bulge” TARGID = “M33bulge2”
OB3: TARGNAME = “M33bulge” TARGID = “M33bulge3”

For the second example, TARGID could be more descriptive:

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 .

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

Only listed values are allowed, all other values are forbidden. As an aside, note that there is no facility to request spatial binning. Such a mode would compromise the spectral extraction performance and crosstalk characterisation within the L1 pipeline.

Duplicate this OB 'x' times

This component is entirely optional – validation checks will not fail if there is no 'x' value in the PROGTEMP. If an applicant wishes to duplicate the observations of this target, then duplication would result in the OB this target lives in being duplicated 'x' times, or in other words, one only OB will be generated, but it will be cloned 'x' times when ingested into the observing system.

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.

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 .

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.

These constraints represent “worst-case” observing parameters – targets will be observed under these conditions or better. Note, however, that the worst case represents a scenario when all worst-case observational constraints meet simultaneously. PIs should note also that the probability of observing targets with highly restrictive OBSTEMP codes may be quite low.

We refer registered WASP users to the OBSTEMP form: http://wasp.ast.cam.ac.uk/obstemp .

DIMM seeing

Seeing is provided by a DIMM monitor located nearby the WHT, and it is measured as the full-width half-maximum (FWHM) brightness profile of a star if located at airmass 1.00.  Note that IFU observations are more tolerant of poorer seeing (diameter of the fibres is 2.6"). An instrument-level limit of seeing <3” is adopted due to degradation of guiding quality in poorer seeing.

Transparency

This component defines the minimum transparency (T) required for the observation. In the absence of cloud and Saharan dust, the V-band transparency (i.e. the fraction of top-of-the-atmosphere light reaching the WHT) is ~ 0.88, and likely scales as (0.88)^airmass (i.e. T ~ 0.83 at airmass 1.5, T~ 0.77 at airmass 2). Extinction due to Saharan dust rarely exceeds a few tenths of a magnitude (i.e. reduces transparency by <~ a few tenths) and varies little with position on the sky. Thin cloud, reducing transparency by a few tenths, can be patchy, so only an all-sky average can be predicted (based on the guide-star signal from previous observations).  A limit on transparency (T > 0.4) is adopted to avoid various performance degradations such as guidance on attenuated guide stars, delivery of science data with significantly reduced signal-to-noise ratio and increased risk of precipitation on the telescope optics.

Elevation angle

Users may set the minimum elevation angle (and thus airmass) that their targets should be observed with. An instrument-wide limit of airmass < 3 will be set due to several effects degrading the quality of data at higher airmass: increasing differential refraction; higher extinction; worse light pollution. Please remember to check for the visibility of your target using http://c.ing.iac.es/staralt/ when placing an elevation limit.

Moon distance

Users may specify the minimum angular distance between the moon and the target. Observations under low moon distance may suffer from sky background light gradients across the field, as well as higher levels of reflected light causing spurious signals within the focal plane. 

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.

Objects that are not detected by Gaia must have their coordinates converted onto the Gaia Reference Frame DR3. It is the responsibility of the PI to verify that their provided coordinates are both consistent with the ICRS.

Parallax and proper motions are particularly important for construction of the WEAVE CNAME, to ensure that successive observations (with varying separation in time) of the same target are correctly attributed to the same CNAME.

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 of the LIFU, if required. Note that the default value is zero.  Any dithering requested for the field is applied to the rotated LIFU frame.

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 OB.

# A custom 3-dither pattern LIFU pointing

TARGID,TARGNAME,GAIA_RA,GAIA_DEC,PROGTEMP,OBSTEMP,IFU_DITHER
PSZ1_125A,PSZ1_125A,316.369609537,-4.71060356792,41331,IAEEB,-1
PSZ1_125A,PSZ1_125A,316.369058752,-4.70967250147,41331,IAEEB,-1
PSZ1_125A,PSZ1_125A,316.370143237,-4.70966298315,41331,IAEEB,-1

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.

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:

weave_open_time_support@ing.iac.es

LIFU mode: OB preparation

Download the validated catalogue

After the upload of the catalogue to WASP, this is validated. When it is passed, then the PI can download a FITS file (linked at the Download column in the figure below) which is the same catalogue as the one uploaded but this time including CNAMEs for every row entry. 

Generation of OBs

The downloaded validated FITS catalogue is used by the IFU workflow software to generate OBs in the form of XML files. Every OB defines the observations for a given target, including instrument setup, observing conditions, dithering (if any), and exposure times. There are a number of considerations which don't affect the generation of an OB: if an OB requires being observed a number of times (as defined in the PROGTEMP code) then that OB will be cloned accordingly when ingested into the observing system. Also, if these OBs are chained: the observing system will handle the respective internal priorities.

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

weave_open_time_support@ing.iac.es

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 Submission Management button gives access to all the uploads made by the user. Submission management allows the user to manage all FITS and OB submissions and select the ones active.

Observations and follow up

ING ingests the OBs (as provided by CASU on WASP) into the observing system at the start of every observing period. OBs are then queued taking into account the priorities derived from the band the associated programme lies (A, B or C). See the open-time time allocations. Observations can be followed up at CASU's operational repository.