Here are basic guidelines for observing each night and/or observing run, like what kind of observations to do and when: The first step is to focus the telescope. Pick a bright target (preferably Mars or another planet), do a five-point observation and center up on the source, then run a focus macro. This steps the secondary through different settings so that we can pick the best focus offset. See CheckingtheSecondaryFocus for more details on focusing the telescope. This should always be the first thing you do each night. If you were able to focus on Mars, it's best to stay here and do a calibration observation right away. We need to do one calibration on Mars each night. It is a good idea to check this observation in real time to ensure that the optics are all in-line. See instructions below for more details on analyzing the Mars calibration. If Mars isn't available at the start of the night, just make sure to get a calibration on it later once it's available. Do a beammap on a bright source (Mars, Uranus, Neptune, or a quasar) once during the observing run, on the first night is best. This can be done at any time of the night. See BeamMapping for detailed instructions. If Jupiter is available at night, it would be a good idea to get at least one loadcurve on it during the observing run. This can be done at any time of the night. See CouplingLoading for more details. Do 2-3 calibration-style observations on bright quasars each night. These are used later for spectral flattening in the post-observing run data reduction process. The brighter the better, but at least > 2 Jy. Spread them out over the course of the night. Pointing observations are key. For all overhead observations on bright sources, make sure to do a five-point first after moving to the target. For science observations, an ideal pointing target is within 10 deg in EL of the science target and >1 Jy at 1.1 mm. If it's also close in AZ that's super, since you spend less time slewing back and forth. We recommend pointing once every hour during regular science observations. See instructions below for analyzing pointing observations in real time. The SMA calibration / pointing database can be very useful for picking bright pointing targets near your source : http://sma1.sma.hawaii.edu/callist/callist.html
There are more useful tips on observing, including useful windows to keep up and help on troubleshooting, here: MiscObserving. Even if you're a seasoned observer (hmm…tasty!) you may want to check out this page each time, since more problems and their solutions often pop up.
There are three computers you will be using: a) kilauea to control the telescope motion and run macros for observing; b) wakea to control z-spec, take data, and for real-time data analysis; and c) polytrope for more advanced data analysis, such as making coadded spectra of science targets. Use the user name zspec for kilauea and wakea; for any analysis on polytrope, you can use your own account.
Basic steps for controlling the data acquisition and telescope operation for a single observation.
uip> planet name or uip> observe name wakea$ bzed ./ YYYY MM DD 1500 100000 > out uip> @ “zspec_svn/macros/SUBDIRECTORY/MACRONAME.mac” ctrl-Cuip> @ “zspec_svn/macros/fivepoint/fivepoint” spacing integrationuip> @ “zspec_svn/macros/nodding/nodcycle” repetitions integrationuip> @ “zspec_svn/macros/nodding” 20 20.5 uip> @ “zspec_svn/macros/nodding” 5 20.5 3. Checking data quality in real-time
Steps for successful (well, most of the time…) real-time data analysis:
A. After the first observation of the night, cd to the data/observations/ncdf/YYYYMMDD/ directory on wakea, and start an IDL session. Run slice_observations to slice the plog files into chunks belonging to observation, assign the observation number, and create the obs_def file:
IDL> run_slice_observations, YYYYMMDD
When finished slicing the first observation, the message “Current observation is 1” will be printed to the screen (i.e., the current observation number really means the NEXT observation number). You do not have to stop run_slice_observations, you can keep it running all night long, and it will pick up the next observation once it's finished. Experience shows that keeping this procedure running (unlike others like run_maligns.pro) does not result in the loss of data packets. But do stop it before you leave the summit in the morning!
B. Open another IDL session, and run maligns to merge the telescope plog and rpc data with the bze bolometer data and create the netCDF file:
IDL> run_maligns, YYYYMMDD, obsnum_start=OBS
where OBS = the observation number. It's important to set this, otherwise run_maligns will try to “re-malign” every observation that night. After it is finished, hit CTRL+C to quit.
IMPORTANT NOTE: Do not simulataneously run bzed and maligns, nor any of the other IDL procedures below. If IDL is accessing the disk during an observation this is known to cause loss of data packets. You should keep an IDL window open, and after stopping bzed, run all of the following IDL processes on the observation you just finished, and DO NOT begin another observation until these are completed.
C. Run save_spectra to do the demodulation:
IDL>file = save_spectra(YYYY, MM, DD, OBSNUM, 1, /deglitch)
Note that the above use of save_spectra should only be used for pointing/calibration/focus observations on bright objects, not for science data.
D. For pointing observations, run through five-point analysis code:
IDL> fivepoint_ja, “~/data/observations/ncdf/YYYYMMDD/YYYYMMDD_OBSNUM_spectra.sav”
If you're looking at a CO source, use the keyword /use_co. This will only use the two bolometers which couple to the line in the fitting of the new offsets.
If you're not too far off in the pointing (as a rule of thumb, if the maximum amplitude occurs at the center of the five-point), you can generally trust the suggested FAZO and FZAO offsets printed on the 2nd output plot. Update these values on the UIP using UIP> FAZO new_fazo and UIP>FZAO new_fzao, and go on to the next observation. If far from the center (by >10 arcsec or so), update FAZO and FZAO as suggested, but you may want to do another pointing to verify.
E. For a Mars calibration observation, make a coadd list for this single observation (see instructions below on making coadd lists), and use uber_spectrum and plot_uber_spectrum_ks to verify that we have decent coupling. For example, for a Mars observation taken on 20100401, make a coadd list called “Mars_20100401.txt', and run uber_spectrum on it:
IDL> uber_spectrum, Mars_20100401.txt, /at_telescope
The name of the output savefile will be printed to the screen. Let's pretend it's called “Mars_20100401_0000.sav'. Then plot the results:
IDL> plot_uber_spectrum_ks, Mars/Mars_20100401_0000.sav, /mars
The spectrum will be printed to the screen. The dashed line is the model Mars spectrum, and the second panel in the plot shows the percent residuals ( = 100*(measured spectrum - model spectrum)/model_spectrum) ) for each channel. The median residual will be printed to the screen. If this is within 10 percent, that's good. If not, recheck your focus, adjust, and repeat the calibration to check that it's improved. If this is persistently bad, we may have an alignment problem, and should check this using the IR source. If you don't know how to do this, wake up James with a phone call!
A SPECIAL REQUEST: This is KS speaking here, as in plot_uber_spectrum_KS. I made this modified version of plot_uber_spectrum.pro to get rid of a lot of frustrating features, plot the spectra to the screen (instead of postscript files), and quickly compare with expected Mars results. It can in principle be used in place of plot_uber_spectrum for all cases, so you might find it handy. You can modify it to enhance it's capabilities, but I have two requests: 1. Do not hard code anything in here: there's no need to add “cases” for desired plot y-ranges for specific targets, you can pass yrange as a keyword (and any other graphics keywords). This was one feature I disliked in plot_uber_spectrum, so please don't put it back in. I'm generally opposed to code that keeps growing as the number of observations grow. And 2. keep it “backwards compatible”. That is, don't change the default behavior - if you want to add a feature, do so through keyword options. I'll be very sad if this gets very cluttered and I have to write plot_uber_spectrum_ks_take2.pro. Thanks.
F. For focus observations see analysis instructions here: CheckingtheSecondaryFocus. All other overhead observations can be analyzed later.
4. Advanced analysis/coadding spectra from multiple observations
All other analysis that does not need to be evaluated in real time should be done on polytrope. That way you can continue observations on wakea/kilauea without risking the loss of data packets. It is recommended that you do look at this data as it comes in, so we can access the quality, decide whether to keep integrating on a particular source, etc.
A. Wait until run_slice_observations has finished doing it's thing for the observation of interest. Then rsync the bze, plog, rpc, and obs_def files on wakea to polytrope:
[zspec@wakea~]$ rsync data/observations/plog/YYYYMMDD USER@128.91.79.253:/usr/local/data/zspec/data/observations/plog/ [zspec@wakea~]$ rsync data/observations/rpc/YYYYMMDD USER@128.91.79.253:/usr/local/data/zspec/data/observations/rpc/ [zspec@wakea~]$ rsync data/observations/bze/YYYYMMDD USER@128.91.79.253:/usr/local/data/zspec/data/observations/bze/ [zspec@wakea~]$ rsync data/observations/ncdf/YYYYMMDD/*obs_def.txt USER@128.91.79.253:/usr/local/data/zspec/data/observations/ncdf/YYYYMMDD/
Be sure to be in the home directory on wakea. We recommend that you leave an xterm open for doing this step after finishing each observation, as the bze files take awhile to copy over. You make have to create the ncdf directory on polytrope by hand, but all other will be created the first time you run rsync. Only copy over the obs_def files in the ncdf directory, not the netcdf files. It is okay to do this while taking another observation (i.e. does not seem to cause loss of data packets when running bzed).
B. The rest of the analysis takes place on polytrope. First, run_maligns on the observation(s) you want to look at:
IDL> run_maligns, YYYYMMDD, obsnum_start=OBS
C. Then run save_spectra on the observation. Use the syntax shown before for bright sources (pointing/calibration targets). For science data:
file = save_spectra(YYYY, MM, DD, OBSNUM, YYYYMMDD_OBS_chopphase.sav, /deglitch)
where YYYYMMDD_OBS_chopphase.sav is the previously computed chopphase file from a calibration observation (gets created when save_spectra is run on the calibration file).
D. To make a calibrated coadd for either a single observation or for multiple observations, a text file (coadd list) needs to be created here:
zspec_svn/processing/spectra/coadd_lists/SOURCE_NAME.txt
It's easiest to copy the format of another file, but just in case, the format is 1st line = object name, then skip a line 3rd line = redshift, then skip a line Further lines are tabbed columns with YYYYMMDD, OBSNUM, flag, and calibration file (YYYYMMDD_CALIBNUM_chopphase.sav). The flag of 0 tells uber_spectra to disregard that line, which is useful if you want to keep all observations in the file but only coadd a select few.
E. Make the coadd:
IDL> uber_spectrum, “SOURCE_NAME.txt”, /at_telescope
uber_spectrum will tell you the timestamped .sav filename that you can then plot. It will be in the directory zspec_svn/processing/spectra/coadded_spectra/SOURCENAME/FILENAME.sav.
F. Plot the coadded spectrum to a postcript file:
IDL>plot_uber_spectrum, “SOURCENAME/FILENAME.sav”, “PLOT_FILENAME.ps”
You chose the filename of the postscript, and it will automatically go in the SOURCENAME folder. Plot specifications [plot ranges, what lines to overplot]? are edited in the list of case statements in plot_uber_spectrum.pro. Alternatively, use plot_uber_spectrum_ks.pro to plot to the screen, but please do not add hardcoded case statements to this procedure as previously explained.