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

General information

• The following AoD Training Checklist provides a list of topics which all AoDs should be familiar with. This includes several important topics like e.g. safety information.

At the beginning of the AoD week

1. Make yourself familiar with the present system status by reading the lastest 30m staff meeting minutes, the status page, previous reports, and by asking the operators. 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 the scheduler or the station manager to clarify their usage.

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

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

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

2. Documentation: Inform visiting astronomers on the NCS and GILDAS documentation which is available online, but also in the folders above the observers desk.

3. The following page gives useful information on how to start observations: Information page on observervations

4. Please remind the observers to fill out the observer comment sheet, at the end of their run.

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

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

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

8. Dead time to start a scan: Measure once per week the time it takes to start and execute a standard calibration.

   • 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 following times from the antennaDataStream viewer: loaded - started - done
   • Time(started - loaded) = Deadtime to start the scan = 12sec usually
   • Time(done - loaded) = Total time needed for calibration = 32sec usually.

9. Status page: Update the status page and other pages, e.g. the Information page on observervations.

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

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

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

13. Some tricks:

    1. Job queue of observations: login mrt-lx1 with your project name, type "observationQueue" in a terminal, this will open a file browser with a list of all jobs, to delete a job right-click. The display is automatically refreshed. There are more obs* command; check the NCS user guide wiki here.

Weekly report

• The weekly report to be send at the end of each AoD week, should address the following topics. Please add pdf 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> And please also note that the described gain-elevation curve holds only for pointlike sources. For extended objects (larger than the beam), the curve is flatter, depending on the source extend. This is why we cannot implement an automatic correction in Odp/MIRA.

Correction for wobbler losses

For the wobbler losses, we don't yet have a CLASS script, but here is a reference describing this effect: Greve et al. (1996) show that also this degradation is worse for the highest frequencies. At 230 GHz, the observed and modelled drop is almost 20% for a throw of ±110”. Near-focus active optics: An inexpensive method to improve millimeter-wavelength radio telescopes, A.Greve, J.W.M.Baars, J. Penalver, B. LeFloch, 1996, Radio Science, 31, 5, 1053 See here for a pdf version and here for the complete reference. Figure 6 shows the losses with increasing throw, also at 1.3mm. At the moment, I don't have an analytical formula. We may read the correction factor just off the figure. <CK, 18-May-2014>

Skydips (Antenna Tips)

To check the sky opacity and compare with the 225GHz opacity of the taumeter, and the result of the hot/cold/sky chopper wheel calibration of EMIR and HERA, we can check with a "skydip" (also called "tip"), ideally when the atmosphere shows no water clouds and is stable, i.e. when the taumeter plot has been flat over an hour or so).

The skydips should be done with E2 at frequencies around 225GHz and with NBC as the backend. If the current project uses E2, then keep the tuned frequency to spare some overhead time. If E0 is being used, then please add E2 to the receiver setup and tune at 225GHz. One should do a calibration right before the skydip.

   cal; start
   tip /airmass 1.1 3.2 0.2; start

The above command executes the skydip from airmass 1.1 to 3.2 by steps of 0.2. These are not the default values. We explicitly request more data points because we might need to reject some points at elevations about 45 degrees due to the partial blockage of the beam by the chopper wheel blades.

The resulting IMBfits (CAL + SKYDIP) should be copied to '/t00-12/skydips/imbfits/'.

The data should be reduced in MIRA (scan 'calScanNumber', scan 'SkydipScanNumber', cal all, solve 1, solve 2...), and the opacity entered in the file ResultsTable.tab under '/t00-12/skydips/'.

Please contact NB if in doubt. Thanks.

Pointing Session

All AoDs should be able to do derive and implement new pointing constant, should this be needed. Juan Penalver has written an elaborate step-by-step description on how-to-do this: pointing-session-06dec2016-penalver.pdf.

Miscellaneous

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

• 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, 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: We have *no* pending report on frequency shifts.

• bbc/nbc
  1. bbc can only be used for EMIR. It is not available for HERA.
  2. The use of the new wide band continuum backend bbc is encouraged for standard pointing and focussing.
  3. For accurate flux measurements, it is yet safer to use the old nbc backends.

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 NCS Operations Notes maintained by Hans