Weekly Checklist of Astronomers of Duty

This is page http://www.iram.es/IRAMES/mainWiki/AstronomerOfDutyChecklist maintained by CK.
Intended Audience: IRAM staff astronomers

Schedules: AoDs, Operators, Projects

Contents

  1. Weekly Checklist of Astronomers of Duty
    1. News from 8-Feb-2012 CK
    2. At the beginning of the AoD week
    3. During the week
    4. Weekly report
    5. Quick Guide to the 30m
    6. Complaint form
    7. Recommendations and gildas tools
      1. Spikes: IF Frequency
      2. FTS Platforming Correction
      3. On-the-fly observations
        1. Work arounds for missing points at borders of spectral line OTF maps (Quick & dirty by HU, 23.8.2012)
        2. pako template (DRAFT)
      4. Gain elevation correction
    8. Appendix

News from 8-Feb-2012 CK

At the beginning of the AoD week

  1. Make yourself familiar with the present system status by reading the status page, previous reports, and by asking staff, in particular also Juan Penalver. Which backends are available ? Had there been receiver related problems lately ? When was the last pointing session ?

  2. Check the observing schedule. If there are any TBD intervals, please contact Nicolas Billot or Clemens Thum or the station manager to clarify their usage.

  3. Please check with the observers whether they will use the FTS and with which dumping times. Please inform the computer group in case of dump times of less than 500msec.

  4. Do test observations near the end of the Tuesday maintenance period (T00-09): Ask operator to execute ./goOnce and ./go then let the operators tune to the frequencies of the following project. Do a quick calibration and pointing. Connect some spectrometers and do a quick position switched test observation (onoff). Use a strong line calibrator (e.g. from the Mauersberger catalogue) for this. Test the band combinations used by the next project. Beware that during one hour, only a brief test of the basic functionality can be done.

  5. Please also check with the local staff doing the weekly maintenance
    1. any changes made to the system which may affect observations, and

    2. whether it is possible to start the T00 test observations early on. If possible, i.e. if it fits with the maintenance work, the Astronomers of Duty should start testing as early as 3:30pm, using the setup of the next observing project.

  6. Introduce observers to TAPAS and the creation of observer logs. Show them how to add comments.

During the week

  1. Communication: Speak with the observers and operators to check and discuss any problems. Do not hesitate to contact other staff. Do not hesitate to inform directly staff in Granada of any problems you may encounter. Please remind the observers to fill out the observer comment sheet, at the end of their run.

  2. Frequency and temperature calibration: Remind the observers to check the frequency tuning by observing a line calibrator with strong and known lines (e.g. DR21, W3OH, OriIrc2, etc.).

  3. Pointing: Get an idea of the pointing situation by speaking with the observers or checking TAPAS.

    • How large are the observed offsets ?

    • Are pointing & focus affected by anomalous refraction ?

    • In case of large pointing jumps:
      • If the jump is only in elevation, check that the relative humidity is read from the weather station. This is used to calculate the refraction correction. In case the humidity sensor is covered by ice and stuck at 100% humidity, the operators can use a handheld hygrometer and enter the value by hand in manual mode.

      • Check that the pointing constants p4/p5 do not show jumps here. These may indicate problems of the inclinometers.

    • Summarize the pointing situation in your AoD report using TAPAS (enter as iramstaff). Do not only include only plots, but say whether or not there are problems. Remember that pointing offsets are not important, but their scatter. Attach a small selection of plots showing the pointing and focus corrections observed during the week by using TAPAS.

  4. Observatory: At least once per week, go up to the receiver cabin and take a careful look. Any strange noise ? Any water entering through the receiver cabin roof ?

  5. Dead times: Measure regularly the time it takes to start and execute a standard calibration. See the AoD report of CB of 10-Jan-2012.

    • select a source that is close to elevation 45 degrees (in the elevation range 30 to 60 degrees.), or just use the running observations for this test.
    • in pako enter:
      • CALIBRATE /DEFAULT
      • START
      • START
      • (or more starts if you have time)
    • ignore the times from the scan after the first START, because they may include additional overheads, e.g., to move the antenna to the start position

    • read the times from the displays of the messages, e.g., in the top center panel of https://mrt-lx1.iram.es/mrt/ncs/monitor/scanInfo.html or the bottom panel in the antennaDataStream viewer

    • for the time to start, record the time interval from the message "scan loaded" to the message "calSky started"
    • for the time to execute the scan, record the time from the message "calSky started" to the message "scan done"

  6. Status page: Update the status page.

  7. If the weather is poor and the telescope stays in stow position, please measure the stability of the receivers by following the HowToMeasureStabilities.

  8. Tests: Help the operators with the heterodyne tests while the telescope has to stay in stow position. These are described here.

  9. Spikes: If some spikes appear while using the FTS or other backends during the week, please use the above procedure to derive the IF frequency.

Weekly report

Quick Guide to the 30m

Complaint form

Please encourage the visiting guest observers to speak out openly any complaints or to give suggestions on how we could improve. It is better they complain to us than to their colleagues at the home institute. If you hear a reasonable complaint (or have one yourself), please inform Juan Penalver, best by filling-out our complaint form. We will then take care that the issue is settled in a timely manner. (From the email of CK to the AoDs on 31-Jan-2012.)

Recommendations and gildas tools

Spikes: IF Frequency

If some spikes appear while using the FTS or other backends during the week, please use the following procedure to derive the IF frequency: spikes3.class. To use it, just tape @spikes3 after loading your spiky spectrum, and you will obtain a plot with the identified spikes and a list with relevant information. It would be very appreciated if you add a list of the local oscilator frequency, spike frequency and IF frequency of the spikes appeared during the week to your AoD report. It would permit to do a census of the most frequent spikes to try to solve them. <MG, 15-June-2012>

The spikes3 routine is width sensible. It means, that if the spike is wider than 2 channels, it will not be detected by it. In that case, you can use the spikes.class procedure. It allows to identify the IF of a single spike with the help of the cursor.

Finally, there is a third procedure, detection_spikes.class, which lists ALL the spikes in a set of spectra. Do not hesitate to contact MG if you have any doubt on how to use these programs.

FTS Platforming Correction

This Script FtsPlatformingCorrection4.class performs an automatic platforming correction for FTS Data by subtracting baselines from the individual FTS units. The FTS data have to be in their original resolution, i.e. 195kHz or 50kHz for the script to work. Line windows can be defined. For more information on its usage, see the comments at the top of the script. <CB>

On-the-fly observations

Work arounds for missing points at borders of spectral line OTF maps (Quick & dirty by HU, 23.8.2012)

1. use standard speeds, up to 60"/sec


2. use a fast time per data point (record), at most 0.5 sec,
   faster is better

   This is controlled through /tPhase of swTotal and swFrequency.
   For swFrequency, the time per data record is 2*tPhase, so for
   swTotal,       /tPhase 0.5         preferably smaller
   swFrequency,   /tPhase 0.25        preferably smaller


3. at the end of your OTF subscans, add the equivalent of 
   3 sec + the time per record
   E.g., if your time per record is 0.5 sec, 
   and your OTF speed is 30 "/ sec
   add 3.5 sec to the time per OTF subscan, /tOtf,
   and move the end point of your OTF subscans 3.5 sec * 30"/sec 
   further out.

4. at the start of your OTF subscans, add the equivalent of your
   time per record.

5. if you use OTFMAP /zigzag and /nOtf > 1, 
   use rule 3. at start and end of your OTF subscans

   NOTE: 3. and 5. are probably too conservative in some cases,
   you probably get away with a smaller increase of the OTF map.

6. if you think that some data points are missing because MIRA
   flags them out because of high tracking errors, check the
   plot of the tracking quality:
   MIRA> scan #
   MIRA> view /trace 5
   (in the panels of the tracking errors you want to consider the
    values plotted over grey backgrounds)

   If they are high, particularly at the start of subscans,
   consider to use a lower speed. (note that for Azimuth you also
   get a lower speed of the axis by observing at lower elevations!)

   Consider that they may be high because of high wind speeds.
   
   Generally, consult an expert on tracking behavior to assess the
   possibility of a technical problem.

pako template (DRAFT)

This is a basic but robust Pako-OTF script example. It creates a 60" x 180" map with an reference position at an offset of 660" in RA and 0" in DEC. The observation loop is ROOOR with ON cycle times of 15 sec and time on reference of 10 sec. The Tphase time is 1.0 sec. It is however not optimized for minimal overhaed times. OTF.pako <CB>

Gain elevation correction

The script GainElevationCorrectionv01.class corrects individual class spectra for the gain elevation curve, using frequency and elevation. It is based on formulae derived in penalver-16apr2012-GainElevation.pdf. Please note that this script is still a DRAFT. <CK, 30-Apr-2012>

Appendix