For more information or assistance, please contact helpdesk@eaobservatory.org. To get up-to-date information about the JCMT please send an e-mail to jcmt_users+subscribe@eaobservatory.org.
JCMT Observing (4)
Flexible observing practice involves determining what the next MSB queued to observe should be by assessing the currently known weather conditions, the source position and the scientific priority of the project. This can be updated on a constant basis and aims to ensure the best use of the available weather conditions and maximise the scientific aims of a project.
When we invite observers to the telescope we always aim to do so at the best time for observing their targets (according to their RA distribution). So we hope that you will get to observe your project when you are at the JCMT. However, if the weather on the night(s) you are at the summit is not in your allocated weather band, then the Queuy Tool will select something else.
Yes! Because this ensures that we match as best we can the current conditions to those for which you calculated your observing time and subsequent sensitivities. It also means there is a good possibility we might have already gathered data for your project before you have arrived at the facility. So when you get here, you may already have freshly collected data to start making great science with.
No. The observatory takes care of all calibration observations (pointing, focus and standard source observations) and this time is not charged to your project. We suggest you look at the calibration pages on specific JCMT instruments to guide you as to our quoted calibration uncertainties. If you have a special requirement, for example with SCUBA-2: a faint source observation (like cosmology) where pointing is critical, you may request in the MSB notes that, if possible, additional pointings are taken bracketing the observations to provide additional precision. Likewise, with a spectral observation, if intensity is of critical importance, you may wish to request a standard source observation be taken closely in time to your science observation. We will do our best to accommodate such requests. If uncertain, ask your Friend of Project for further guidance.
JCMT Operations (2)
JCMT operates a 12-hour shift from approximately sunset to just after sunrise (though submillimeter observations are not strictly limited to nighttime hours). We have an attending Telescope System Specialist (TSS) who operates the telescope from the summit, and who is accompanied by a visiting observer. The visiting observer assists by helping to guide selection of MSBs with the Query Tool (according to weather and priority) and providing scientific feedback on the quality of the observations being collected. If weather conditions are favourable, we might also complete evening observing and then handover to a remote operator (Extended Observer) in Hilo, to continue observing for a few hours in the morning whilst conditions are still good.
Yes it can. Submillimeter telescopes are not limited to night time hours. Telescopes like the JCMT are mostly restricted by the amount of water vapour present in the atmosphere. This tends to be lower at night, and in the early morning, but can often (especially on sites like Mauna Kea) be low enough throughout the day to allow us to observe at any time. Scientific observations of planets and comets are the most common targets for daytime observing.
However usually the seeing becomes bad at submillimeter wavelengths during the day and pointing and focus observations become difficult after about 10am HST.
JCMT Data (4)
No, this pipeline is only for an inspection of the data quality (e.g. rms) while observing.
The reduced data at CADC are mainly for inspection of the results, and also have not always been reduced with the latest version of the software.
They are reduced with the default DR recipe in the MSB, and for SCUBA-2 the default FCF was applied, which may not be the best for your observation. Also observations of different nights are not co-added.
You probably want to rereduce SCUBA-2 data using the correct FCF, the pixelsize of your choice, and possibly using external masks and other refinements.
For heterodyne observations the resulting files are often acceptable, but in some cases you may e.g. want to blank parts of the raw data or modify the velocity range with noisy pixels at the edges of the bands and rereduce.
Dealing with data from different telescopes is a common activity for astronomers. Here is a rough method for convolving a beam (i.e. PACS, Herschel) to another beam (i.e. SCUBA-2 at 850um).
A very rough and ready method is to assume that both beams are Gaussian. Let’s say PACS has an FWHM of “A” arc-seconds and SCUBA-2 has an FWHM of “B” arc-seconds. If “A” is larger than “B”, then you need to smooth the SCUBA-2 map using a Gaussian kernel of FWHM equal to sqrt(A*A – B*B) arc-seconds. If the SCUBA-2 map has a pixel size of P_b arc-seconds, then first convert the above size into pixels by calculating:
width = sqrt( A*A – B*B )/P_b
and then smooth the SCUBA-2 map using the “gausmooth” command in the starlink kappa package:
kappa
gausmooth in=<your scuba-2 map> out=<smoothed map> fwhm=<your "width" value>
The smoothed map is put into the file specified by the “out” parameter. Alternatively, if “B” is larger than “A” smooth the PACS map inthe same way, using a width of:
width = sqrt( B*B – A*A )/P_a
where P_a is the pixel size in the PACS map.
You will need to know what the A and B values are (at 850 microns “B” is about 13.5 arc-seconds). If your maps have point sources in them, then you could determine A and B by measuring the widths of the point sources in your maps. For instance, the “psf” command (“Point Spread Function”) in the starlink kappa package allows you to determine a mean beam shape from one or more point sources in an image. It does this by fitting a generalized Gaussian function to the mean radial profile of the indicated point sources.
The above assumes that both beam shapes are Gaussian. The SCUBA-2 beam shape is not quite Gaussian and so the above method can be improved, but it involves a lot more time and effort. You need first to get accurate models for the two beams (either as analytical functions or as 2D images), then you smooth the SCUBA-2 map using the PACS beam, and then smooth the PACS map using the SCUBA-2 beam. This approach requires no deconvolution, but results in maps that have lower resolution than either the PACS or SCUBA-2 maps. The kappa package includes the “convolve” command that will smooth a map using a beam shape specified as a 2D image (the kappa “maths” command can be used to generate a 2D image if your beam shape is expressed as an analytical expression). The details of this method depend on the form in which you obtain the beam shape information.
A common question we receive here at the JCMT is regarding observations with SCUBA-2 and the conversion from mJy/beam to mJy. Before we begin, it should be noted that for a real point source, a peak brightness value reported in units of mJy is the same as a peak brightness value reported in mJy/beam.
Now what happens if we have a map in mJy/beam and we want to obtain an integrated intensity value, a total flux value. We first sum up a number of pixels and now we want to get our units correct from mJy/beam to mJy…
Total Flux = flux summed over a number of pixels/(number of pixels in a beam)
Then your units are:
[mJy*pixels/beam] / [pixels/beam] = [mJy].
Beam Area = 2 × π × σ² [arcsec]
where the σ of the Gaussian beam can be calculated from the JCMT FWHM values at 850 and 450 microns (reminder the beam components are provided in Dempsey’s 2013 paper).
FWHM = 2 σ √(2 ln 2) [arcsec]
So we can use the FWHM to obtain σ to calculate the Beam Area and report the beam area in terms of pixels:
number of pixels in a beam = Beam Area [arcsec] / (pixel length)²
JCMT OT (11)
Normally a repeat counter is not necessary. A single MSB should be between 30-70minutes in length. To build up the total time require on a source you should increase the “Observe Counter”. A repeat counter may be used when performing a Heterodyne stare observation. In this case it may be ideal to have each stare last ~15-20minutes and use the “repeat” counter to produce a sensible MSB length.
Observers usually base a reference/off position on knowledge about a region/source from previous data or information from the literature.
If you are unsure of your reference position you might want to add a quick 5 minute stare observation of your reference position in the same set up as your science observation. You can then add to the notes that the science observation must only be taken if the reference position is clear.
Use what you need. i.e. only request wideband mode if your source requires it. Only request multi subband observations if you need it and not to get “free lines” – typically the more complex an ACSIS set up the higher the chance for baseline issues due to less stable power supplies. Choosing two 250 MHz bands with lines in the center of each band is better than choosing a 400 MHz band centered on one line.
A basket weave is an observation in which one scan ha a “Scan PA” component set to “Along Width” and a second scan has the “Scan PA” set to “Along Height”. If you are mapping a small region you can simply do this within the same MSB. To do this copy the scan component and paste it below the original scan component and adjusting the “Scan PA” accordingly. You might also need to update the Sample Time to ensure your MSB remains a sensible length.
For larger scan areas (>0.5 degrees in size) you might have to have a separate MSB for the “Width” and “Height” due to the total length. If this is the case it is recommended you request in the notes that two observations are taken back to back to ensure an even coverage in terms of sky transmission (in terms of elevation and weather).
Do not edit an older copy you have on disk and upload.
In JCMTOT click on Fetch Program to retrieve the MSB’s from the database. Then do any necessary modifications and Store to the Online Database. This will prevent repeating observations which already have been done, and keeps modifications done by your FoP.
Heterodyne: The aspect of the MSB (Minimum Schedulable Block) you most want to think about is its length. If you have been allocated e.g. eight hours for a single source, you could submit a single 8-hour MSB if you wanted. But that would be a very silly thing to do. If your source is not up for more than eight hours, it would never be scheduled as our software would detect that it would set before the MSB could be completed. But even if your source were observable for 8 hours solid, the observer won’t choose to undertake it except near the very beginning of the night, which vastly decreases your scheduling opportunities.
On the other hand, if many short observations are all scheduled one after the other they would have to be sent to the queue one by one, thus driving the TSS and observer insane.
If your sources are well separated across the sky a pointing will be required between them (even if they are only separated in time by ten minutes). However if they are close by each other they can be done consecutively. If you are including multiple sources in an MSB try to pair or group them so they are all are all close together. If this is not the case then include an note highlighting this to the operator.
The golden mean? A 30-to-90 minute MSB. If you have any questions about the best way to distribute your sources please consult your Friend of Project for ideas.
SCUBA-2: We have a 40 minute limit on SCUBA-2 observing blocks. This upper limit usually concerns large pong maps while small daisies fall at the other end of the scale being potentially only a few minutes each. Having short MSBs for SCUBA-2 does not incur the same overheads as heterodyne. Like heterodyne observation consecutive sources that include a large slew will likely require a pointing between them, however SCUBA-2 has the additional factor or requiring the arrays to be setup again after a move between sources.
There isn’t one. However if you don’t submit MSBs for your sources by the time they are observable you could be throwing away opportunities of having your sources observed. Nevertheless, note that there is no requirement that you submit your entire project at once. Therefore you can submit some MSBs, wait for them to get done so you can analyze the results and then submit other MSBs to follow up on those results. Your MSBs will keep on being scheduled until you have exceeded the total time allocated to your project.
You probably forgot to enter your co-ordinates! If you really meant to observe 0:0:0, 0:0:0 just ignore it.
You certainly can. However I suggest you let us know for two reasons. First, for your benefit, we’ll be able to look your MSBs over to ensure that they will actually do what you intend. Secondly, for our benefit, we would like the chance to create a library MSB that matches your observing mode in case that will be useful to other users.
We would rather you did not. Your Friend Of Project will not enable your program for observing until they are sure the construction is good. Uploading to the database is the best way to work with us, and get help. Upload it and then notify your F.O.P. so they can review it and suggest or make changes. Also there is a risk with xml sent via email that the lines are not wrapped – this will produce illegal xml.
Please see the “Observing Strong Continuum Sources with Heterodyne Receivers” page for information on overheads and instructions for observing targets such as the moon, the Sun, or planetary atmospheres.
Starlink software (6)
For details on the various frequency and velocity definitions and rest frames used in JCMT heterodyne observations, please see our Velocity Considerations page.
Common requests:
- to convert processed data from the JCMT Science Archive, which is in Barycentric frequency, into radio line-of-sight velocity (
) in LSRK. You can use the following Starlink commands to do this, assuming you have started with a file named ‘archive_file.fits’. These would be copied into a terminal, after setting up the Starlink software within that terminal. The lines starting with a # symbol are comments.
# Load the convert package to enable conversion from FITS to NDF convert # Convert your archive file into Starlink Data Format (NDF) fits2ndf archive_file.fits archive_file.sdf # Load the KAPPA package (contains many useful routines) kappa # Set the 3rd axis of the coordinate system to be in units of radio velocity wcsattrib ndf=archive_file.sdf mode=set name=system\(3\) newval=vrad # Set the standard of rest to be the LSRK wcsattrib ndf=archive_file.sdf mode=set name=StdofRest newval=LSRK # OPTIONAL: if fits output is required, convert the file back to fits ndf2fits archive_file.sdf archive_file_radiovelocity.fits
- to add together spectral data from moving targets (eg comets) onto a ‘source’ (‘cometocentric’) velocity scale:
makecube <rawdatafile00099> system=GAPPT alignsys=TRUE out=out99.sdf wcsattrib out99.sdf set alignoffset 1 wcsattrib out99.sdf set skyrefis origin wcsattrib out99.sdf set sourceVRF topocentric wcsattrib out99.sdf set stdofrest source wcsattrib out99.sdf set alignstdofrest source wcsattrib out99.sdf set SourceVel <velocity> wcmosaic out*.dat . . .
We have a PICARD recipe named SCUBA2_MAPSTATS which will calculate various properties of the observation, its noise and its average NEFD given a single reduced SCUBA-2 observation.
You can run this recipe as follows (in a terminal, after setting up the Starlink software):
picard -log sf SCUBA2_MAPSTATS scuba2_reduced_file.sdf
This will produce an output file named ‘log.mapstats’ in the directory specified by the environmental variable ‘ORAC_DATA_OUT’ (if set), or in the current directory if that is not set.
This file currently contains entries for each of the following columns:
# (YYYYMMDD.frac) (YYYY-MM-DDThh:mm:ss) () () () (um) (deg) () () () () (s) (s) () () () () (") (") () () ()
# UT HST Obs Source Mode Filter El Airmass Trans Tau225 Tau t_elapsed t_exp rms rms_units nefd nefd_units mapsize pixscale project recipe filename
with some of the units indicted in the top line (ones that are always the same), and others specified as a column (these can be different depending on what was applied to the dataset).
These tell you information about the observation — the time it was started (UT and HST), the observation number (column labeled Obs, i.e. was it the 1st, 2nd,3rd etc SCUBA-2 scan of the night), the sourcename, the Mode (Daisy or Pong), the filter (450um or 850um), the Elevation, Airmass, Transmission, Tau225 and Tau at the start of the observation (taken from the fits headers of the file). The total time spent on source is given in t_elapsed, and the average exposure time for a pixel is given by t_exp.
The RMS is calculated from the variance array of the observation, and its units are explicitly given. The NEFD is calculated from the data in the NDF extension ‘MORE.smurf.nefd’, and its units are explictly given.
The RMS, exposure time and nefd are calculated over the central square region of the map, defined by the MAP_WDTH and MAP_HGTH headers.
If multiple files are run through SCUBA2_MAPSTATS, either in a single call of PICARD or by repeatedly running PICARD in the same terminal on different files, the results will be appended to the existing log.mapstats file. The final columns — project, recipe and filename — are given to ensure it is clear to users which line of the logfile corresponds to which input file.
SCUBA2_MAPSTATS is only designed to work on reductions of a single observations. On coadded observations it could produce misleading results, or even fail completely to work.
If your data is calibrated, this will assume that the units are correctly set in the file, and that the noise and NEFD extensions have also been correctly updated. This can be done by using the PICARD recipe CALIBRATE_SCUBA2_DATA.
You can download the Starlink suite of data reduction, analysis and visualisation tools from http://starlink.eao.hawaii.edu. Binary installations are produced for Mac OSX and for Linux Centos-6 compatible systems.
Please follow the instructions on the download page for installation and required dependencies.
Before you can use the Starlink software in a terminal, you will have to set it up in the current terminal session. If you are running a sh derived shell( sh, bash or ksh) please enter the following commands into your current terminal session:
export STARLINK_DIR=/path/to/your/starlink/installation source $STARLINK_DIR/etc/profile
If you’re using a csh derived shell (csh or tcsh) please instead run the following commands:
setenv STARLINK_DIR /path/to/your/starlink/installation source $STARLINK_DIR/etc/login source $STARLINK_DIR/etc/cshrc
After running these commands, you will be able to start running Starlink commands in the current terminal. If you switch to a new terminal, you will need to repeat those commands before you can run Starlink software. We do not recommend setting these files up in your standard login configuration scripts, as there are name conflicts between some Starlink software and some commonly used linux software — for example, we have a command named ‘convert’ which allows use of astronomy-specific file format conversions. This would conflict with the common command ‘convert’ from ImageMagick.
Under Linux, the starlink set up will also include Starlink libraries in the LD_LIBRARY_PATH variable, and these can conflict with other packages such as CASA. By only setting up the software in a specicifc terminal, you can have one terminal running Starlink and another running software such as CASA without any conflicts.
Once Starlink is setup, you can run commands and load the various Starlink packages. For example, to run commands from the package KAPPA you would simply type the command kappa into your terminal, and you would be shown the following output:
$ kappa KAPPA commands are now available -- (Version 2.3) Type kaphelp for help on KAPPA commands. Type 'showme sun95' to browse the hypertext documentation. See the 'Release Notes' section of SUN/95 for details of the changes made for this release.
Dealing with data from different telescopes is a common activity for astronomers. Here is a rough method for convolving a beam (i.e. PACS, Herschel) to another beam (i.e. SCUBA-2 at 850um).
A very rough and ready method is to assume that both beams are Gaussian. Let’s say PACS has an FWHM of “A” arc-seconds and SCUBA-2 has an FWHM of “B” arc-seconds. If “A” is larger than “B”, then you need to smooth the SCUBA-2 map using a Gaussian kernel of FWHM equal to sqrt(A*A – B*B) arc-seconds. If the SCUBA-2 map has a pixel size of P_b arc-seconds, then first convert the above size into pixels by calculating:
width = sqrt( A*A – B*B )/P_b
and then smooth the SCUBA-2 map using the “gausmooth” command in the starlink kappa package:
kappa
gausmooth in=<your scuba-2 map> out=<smoothed map> fwhm=<your "width" value>
The smoothed map is put into the file specified by the “out” parameter. Alternatively, if “B” is larger than “A” smooth the PACS map inthe same way, using a width of:
width = sqrt( B*B – A*A )/P_a
where P_a is the pixel size in the PACS map.
You will need to know what the A and B values are (at 850 microns “B” is about 13.5 arc-seconds). If your maps have point sources in them, then you could determine A and B by measuring the widths of the point sources in your maps. For instance, the “psf” command (“Point Spread Function”) in the starlink kappa package allows you to determine a mean beam shape from one or more point sources in an image. It does this by fitting a generalized Gaussian function to the mean radial profile of the indicated point sources.
The above assumes that both beam shapes are Gaussian. The SCUBA-2 beam shape is not quite Gaussian and so the above method can be improved, but it involves a lot more time and effort. You need first to get accurate models for the two beams (either as analytical functions or as 2D images), then you smooth the SCUBA-2 map using the PACS beam, and then smooth the PACS map using the SCUBA-2 beam. This approach requires no deconvolution, but results in maps that have lower resolution than either the PACS or SCUBA-2 maps. The kappa package includes the “convolve” command that will smooth a map using a beam shape specified as a 2D image (the kappa “maths” command can be used to generate a 2D image if your beam shape is expressed as an analytical expression). The details of this method depend on the form in which you obtain the beam shape information.
Sometimes you might wish to ignore certain receptors form your HARP reduction. For example let’s consider that I wish to reduce only the central four HARP receptors form some data. As a reminder the two places to look for information on heterodyne data reduction are:
Quick Guide – short description on how to reduce heterodyne data.
DR Cookbook – should be consulted for a more detailed description.
So to reduce data without certain receptors will require using the bad_receptors calibration option. It is possible to put a list on the command line, or use a file. Given that in this example we want to make twelve receptors “bad” (i.e. ignored) a file seems better. Create a file called $ORAC_DATA_OUT/bad_receptors.lis and space-separate a list of those you want to EXCLUDE from the reductions like this example:
H00 H02 H03 H05 H06 H07 H08 H09 H11 H12 H13 H15
Then run oracdr with the following:
oracdr -loop file -file mylist.lis -nodisplay -log sf -verbose -calib bad_receptors=FILE
This will instruct ORACDR to read a bad_receptors.lis file in ORAC_DATA_OUT, which it expects to contain space separated detectors. Alternatively provide a colon list of receptors, i.e. H02 and H08:
oracdr -loop file -file mylist.lis -nodisplay -log sf -verbose -calib bad_receptors=\"H02:H08\"
It is often useful to know what version of the starlink software you are using. This is especially important if you wish to report a bug to the staff at EAO. To find out what version you are running simply use the command starversion. The output provides you with the version and when the software was last updated. i.e.
starversion 2017A @ bfdc8534a17c406c59302030ed1c1ae1a1223bd1 (2017-07-28T19:12:59)
UHH Student JCMT Observers (5)
There are two pieces of EAO paperwork that need to be completed and returned. These are an accommodation request form and a medical waiver form, available here. Please note that even if you live and study in Hilo, a completed accommodation form is required, as it is needed to arrange mountain accommodation, transportation, etc. Please also note that all prospective UHH student JCMT observers are required to have medical insurance coverage.
In addition, since the UH IfA Principal Investigator (PI) of the science project is normally expected to cover the Hale Pohaku accommodation costs for the duration of the observing run, it will usually be necessary to complete this form and return it to Amy Miyashiro at the IfA.
The project code and the PI name can be found by consulting the JCMT telescope schedule, available here. Select the most recent semester and scroll down to the dates that you expect to be using the telescope. The project code will be something that looks like “M18AH01A” or similar, and the surname of the project PI will be listed just after that.
For the “Arrival in Hilo” parts: UHH students should be able to just put in “N/A” for the arrival date and time.
You should be aware that you will still need to attend a sea-level safety and orientation briefing from your Support Astronomer. They will contact you by e-mail to set up a date and time for that. This should be during normal working hours, whenever possible.
UHH students can usually skip the Hilo hotel and rental car sections of the form for before (and after) the run altogether.
UHH students should complete the Hale Pohaku section, bearing in mind that all observers need to spend at least one additional night up at HP acclimatizing before the start of their observing run. Note that observers who have not worked at the summit of Maunakea before are usually recommended to spend two nights at HP for acclimatization purposes. You can discuss this with your Support Astronomer.
For the first meal, assuming that you’re able to drive one of our cars at the usual 3pm time, then you’ll want that to be “dinner”. (If you don’t drive then your Support Astronomer will discuss other possible Hilo/HP transportation options later on).
For the “Acknowledgement” section: that should be your name & email address. You might also want to forward a copy of the booking confirmation that you will eventually receive from EAO to Dr. Marianne Takamiya at UHH for reference as well.
If you know that you’ll be going up with a second observer, please supply their name in the appropriate part of the form. Otherwise, feel free to leave the “Other Observers” box empty.
The rest of the form is fairly self-explanatory, but please just contact us if you’re still unsure about anything. And don’t worry: we’re already that assuming you’ll reply with a “No” to the seminar question at the end!
You should ideally try to read through at least these web pages:
It would also be useful to review these pages, to get a feel for the computing environment you will be using while observing:
A selection of videos on the JCMT and sub-mm astronomy are available here. This link includes overview videos of the JCMT, videos on what it’s like to be a visiting JCMT observer, and videos on the JCMT instrumentation.
The computer systems used by JCMT observers run Linux, which is a Unix-like operating system. If you are only familiar with (e.g.) Windows-based systems, it would be useful to learn at least a little about Linux before you observe at the JCMT. There are many excellent introductory online resources available for users. For example, one very good introduction is available here.
Note that if you have a Mac, then you already have access to a Unix operating system, as macOS is actually a certified Unix variant. The standard Unix commands that are commonly used are available via your Mac’s built-in “Terminal” application.