Versions Compared

Old Version 2

changes.mady.by.user Mia Walker

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Williams

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

This document describe 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.

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

...

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

...

  • 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 on one of these eight frequently-used channel sets for your observation Using one of the above channel sets means that:

...

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.

...