...

This document details how to plan and describe the technical aspects of an MWA observing proposal ('Part C'), 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.

...

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/Note - in long baseline configuration

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)

...

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 whatever network configuration is required to allow the messages to be delivered to site (or generated by hardware on site), as well as custom code to handle deliver the incoming messagetrigger 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.

...

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

• If there’s more than one sourcea handful of sources (too many to enter into the form), put them all 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 proposalattached observing instructions document.
• Include Ideally, use RA and Dec, preferably 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 fulfill fulfil requests like that, but seeing when your observations are possible, and when you’d prefer them, helps a lot.

...

If your observations need to be scheduled around some other instrument (GMRT, Parkes, etc.), then your proposal '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.

...

Summary

What I need to see in part C, either in the form or in the 'observing instructions' document, at a glance (ideally in a table):

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

...

• Observations are scheduled by someone who isn't familiar with your research area, so put the science earlier in the proposalscientific justification document, not in part CNOT 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.

...