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

News from 8-Feb-2012 CK

• Pointing with E3: This is difficult because quasar fluxes are low at these high frequencies. Though planets and secondary calibrators can still be used, one way out is to use the 2mm receiver in parallel. Observers should know that there is a significant focus difference between the two. The focus of E3 is about 0.6mm smaller than the focus of E1, e.g. -2.2mm for E1 and -2.8mm for E3. When we currently need to do a pointing while observing with the upper bands of E3, we connect E1 and leave the LO of E3 untouched, i.e. E3 tuned as it is, but change to the lower E3 bands. After the pointing with E1, we disconnect E1, and change to the upper sideband of E3 again. Having the scripts prepared, this comes at no extra cost.

• The EMIR homepage is constantly updated to reflect the current status.

• 32GHz FTS

  1. 200kHz <-> 50kHz:Switching between 200kHz and 50kHz resolution needs to be done by the operator who has to stop and restart the FTS process, and then ajust the attenuators. It takes about 3 minutes only.

  2. Attenuators: After starting a project, retuning the receivers, or switching between 200kHz and 50kHz, the operator needs to readjust the attenuators on the ambient load in order not to saturate the FTS. The operators have a detailed guideline on their wiki. The AoDs should check at the beginning of observations that FTS data are actually produced. It happens that no data are produced and the fts process on the fts pc needs to be restarted by the operator.

  3. Restarting the FTS process will also re-calibrate the FTS-ADCs. It is a good idea to do this during a pointing scan.

  4. HERA: When using 50kHz with HERA, switch to fine mode to place the line in the center of the band.

  5. Dump times: AoDs should keep an eye on the dumping times, especially when the observer uses on-the-fly or frequency switching. Dumping times down to 500msec-100msec work (with the fully optimized mira version installed in the last week of July), but will create huge amounts of data in a short time! Keep an eye on disk space. Check with the observers that they rsync their data to their external USB disks, if possible.

  6. Frequency shifts: After correcting for two bugs in mira and class in July-2011, we put a report (Buchbender et al.) onto the EMIR homepage.

• bbc/nbc
  1. At present, a calibration needs to be done with bbc, as odp is not yet able to show raw data.
  2. bbc can only be used for EMIR. It is not available for HERA.
  3. The use of the new wide band continuum backend bbc is encouraged for standard pointing and focussing.
  4. For accurate flux measurements, it is yet safer to use the old nbc backends.

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.VERY IMPORTANT ! Perform this test even if the weather is bad. In this case, tune the receivers, and do a cal /sky no, in order to check that the data are correctly recorded.

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

• The weekly report to be send at the end of each AoD week, should address the following topics. Please add eps files to your report, to better explain any problematic spectra, etc.. Better start writing the report already on the first day of the AoD week, and not at the very last moment. Report what is not working, but also changes to the positive. There is no need to repeat any daily operator reports. The report shall be send to aodreportlist AT iram.es and should be structured as follows:

  1. Pointing/Focus

  2. Receiver

  3. Backend

  4. Computers

  5. Software/Documentation

  6. Other remarks

Quick Guide to the 30m

• Quick30mGuide (DRAFT!)

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

• The above list assumes that you are familiar with the system:
  • Computers, Printers
  • Basic working of pako, odp/mira, class, greg
  • Basic security rules (Operators, Juan)
  • Observatory information for the guest observers
  • Basic IRAM web pages, wikis.

  • See the AoD Training Checklist maintained by Manolo

  • See the NCS Operations Notes maintained by Hans