Introduction

This document details how to plan and describe the technical aspects of an MWA observing proposal, as written by the person who schedules your observations. It does not describe the science justification needed to get your proposal accepted, only the technical requirements that need to be included so we can schedule your observations and get the results you want, if it ends up being accepted.

Data Volume

The MWA is usually far more limited by the volume of the data collected than it is by hours available on the sky. Using a correlator mode with less frequency or time averaging not only uses more space in the archive, it also means your data will take more time to download and reduce. You can use this online tool to estimate the amount of data you can expect from your proposal by entering the number of hours, frequency averaging, and integration time (or by selecting the 'VCS mode' checkbox): https://ws.mwatelescope.org/data/volcalc/

The proposal form itself will also estimate the data volume for the given observing modes and numbers of hours.

Note - if you choose NOT to use fringe stopping, integration time should be 0.5 seconds or less, and frequency resolution should be 10 kHz or less for long baseline mode, or 2.0 seconds and 40.0 kHz or less for the compact configuration.

Triggered observations (eg, from VOEvents)

The MWA uses a two-level triggering system for real-time events that can interrupt current observations and schedule new ones to catch a transient with low (~10-20 second) latency. The triggering system is described detail in Hancock et. al, 2019. The observations generated in response to a trigger can be of any duration, but anything longer than 30 minutes will need strong justification in your proposal. Both normal correlator and voltage-capture observations can be generated by a trigger. Your code can also request that a calibrator observation be scheduled immediately after the target observations, and the calibrator can be specified, or chosen automatically. If the trigger occurs during the day, your code can request that the primary beam direction be automatically offset slightly, to put the target location slightly off-center, but with the Sun in a primary beam null, to keep it out of the side-lobes. Your event handler code can also interrupt observations that it has generated for a previous event - for example, if a new VOEvent arrives with an updated source position, you can interrupt your first triggered observation(s) and replace them with ones with the updated position. 

If you're interested in a project that involves triggering MWA observations in real time, contact Andrew Williams for more details, including a template for the VOEvent handler function you'll need to write, to parse incoming VOEvents and send them to the telescope. The MWA can also trigger via pathways other than VOEvents from 4PiSky, but this would require custom code to deliver the trigger calls.

Plan for at least a few months of testing and parameter tuning before any new trigger handler goes 'live' and actually interrupts the telescope.

Sources

Make it VERY clear what your sources are, and where they are in the sky:

• If there’s more than a handful of sources (too many to enter into the form), put them in a table in the attached 'observing instructions' table, with name, coordinates, and any other data (observing time, frequencies, etc) that’s not the same for every source in the proposal.
• When specifying source names, make sure that the exact strings you include in the proposal resolve correctly in a VizieR search (https://vizier.u-strasbg.fr/viz-bin/VizieR), don’t abbreviate them.
• If your source names are from some catalogue that isn’t searched by VizieR, that’s fine, but say so in the comment and in the attached observing instructions document.
• Ideally, use RA and Dec, with the RA in hours, not just degrees, so it’s easier to compare to LST when scheduling.
• If you want to include two nearby sources in the same observation, say what pointing you want to use (one source or the other, or midway in between).
• Think about issues like whether you want your observations LST matched to other observations (in the same semester, or a previous one). If so, specifying LST and/or MWA gridpoint number (or az/el) is important, as well as RA/Dec.

When do you want your observations scheduled? This should be discussed in the 'observing instructions' document.

• Describe both when in the semester your observations are possible, and when you would prefer them to be scheduled.
• Work out roughly how many hours per day/night your source/s can be observed through the semester, and explain that in the proposal – eg “We request 100 hours of night-time observations of source A at an elevation > 45 degrees. These observations are possible from early May to late July, but ideally we would prefer 3-5 hours per night over transit, for ~30 days centred around June 15th.”
• This is especially important for large time requests (more than a few nights).
• We can’t promise to fulfil requests like that, but seeing when your observations are possible, and when you’d prefer them, helps a lot.

Day or night observations?

• If your source isn’t available to observe at night during the semester (and you should know this in advance), then your observations can be scheduled in the daytime.
• The same is true if there aren’t enough night-time hours in the semester for all the accepted proposals at that RA range – some (or all) of your observations might be scheduled during the day.
• The scheduling software can optimise SNR by choosing a pointing that puts the Sun in a beam null without going too far off the source, but it only works well when both the source and the Sun are above around 30 degrees elevation.
• Keep this in mind when working out your suggested dates/times.

Commensal observing:

If your observations need to be scheduled around some other instrument (GMRT, Parkes, etc.), then your 'observing instructions' document needs to state:

• Roughly what dates/times you expect it to be, if known.
• When you expect to learn the exact times allocated on the other instrument.
• How closely aligned in time you would like the observations, and how closely aligned they need to be. Exactly overlapping? Partially overlapping? Within a few days? Do the alignment requirements vary by source or frequency choice?
• Remember that dishes can point closer to the horizon than the MWA, so consider that and latitude/longitude differences when scheduling joint observing.
• Finally, when you do get your time allocation results, please let me know dates/times (in UTC) as soon as possible, don’t wait for me to chase you up and ask.

Observation ordering

What order would you like individual observations (different sources, frequencies, etc.) taken in? Does it matter?

Suppose you want four hours, on each of 5 sources, at each of three frequencies, and there are 6 hours available per night. What ordering suits your science better for the 60 hours of observations? Eg:

• For each of 10 nights, loop over all 5 sources, and for each source, loop over all 3 frequencies, and for each frequency, take one 120 second observation. Repeat 11 more times that night. Repeat for 10 nights.
• Observe the first source for four hours at one frequency, then the first source for two hours at the second frequency. Over subsequent nights, continue to spend four or two hours continuously on each frequency, swapping to the next source in the list as required.
• Spend two nights just observing the first source, looping over the three frequencies, then swap to the next source on the next two nights, etc.
• These are just examples – there are many possibilities.

Things to consider:

• Consider how a telescope failure or a bad ionosphere (for a whole night, or a fraction of a night) would affect your results. Would you prefer to lose some integration time on every source/frequency, some of the frequencies for every source, or all the observations but only for some of your sources?
• Do you expect any time variability in your source/s, and if so, how would you prefer to sample it? Would you prefer your observations spaced out more widely, instead of on consecutive nights?
• Inside each single block of observations on a night, it’s a lot easier for me to schedule observations that loop over pointing first, and for each pointing, loop over choice of frequency. The reverse is possible, if you need it.

Frequency Channels

MWA observations use an arbitrary set of 24 ‘coarse channels’ numbered from 0-255, where each channel is 1.28 MHz wide. The centre frequency of each coarse channel is 1.28 MHz multiplied by the channel number. We carry out morning and evening calibrator observations every night, for eight commonly used channel sets:

• The five GLEAM bands, centred on 69, 93, 121, 145 and 169 (coarse channels 57-80, 81-104, 109-132, 133-156 and 157-180, respectively).
• Dual band (57-68 and 121-132).
• Twelve 2.56 MHz wide bands (62;63, 69;70, 76;77, 84;85, 93;94, 103;104, 113;114, 125;126, 139;140, 153;154, 169;170, 187;188).
• Twenty-four 1.28 MHz wide individual channels (62, 67, 73 , 78 , 84 , 89 , 95 , 100 , 106 , 111 , 117 , 122 , 128 , 133 , 139 , 144 , 150 , 155 , 161 , 166 , 172 , 177 , 183 , 188).

Decide whether you can use one of these eight frequently-used channel sets for your observation Using one of the above channel sets means that:

• You’re avoiding channels with low signal, or known bad RFI (<57, 105-108, > 188).
• You’re more likely to get a good calibration for your observations, with extra calibrator observations every morning and evening.
• The calibrator observations scheduled for you can help provide redundant calibration data for other people’s observations on the same night/s.

If you’d prefer to use a unique channel set, mention that in the proposal. That way I won’t waste time by asking if you want to use a GLEAM band, for example. Also, if you need precise limits for frequency, mention that in the proposal, so they don’t get missed by rounding to the nearest 1.28 MHz wide channel, or better yet, specify the exact channel numbers you want.

Summary

What I need to see, either in the form or in the 'observing instructions' document, at a glance:

• Source details (names, RAs, DECs)
• Observing requirements (channels, number of hours)
• Any constraints (commensal observing, observation spacing, etc)

What you need to remember:

• Observations are scheduled by someone who isn't familiar with your research area, so put the science earlier in the scientific justification document, NOT in the observing instructions.
• The more you describe when and how you’d like your observations (as soon as possible, when the source transits at midnight, in July, etc.), the more likely I am to be able to schedule them that way.