Box Scan

Sample Box Scan commands

In the table below "spacing" is the distance between intersecting lines on the scan pattern.   See the documentation below for more details.

Table 1: Scan parameters

Requested Size (arcminutes)	Actual Size (arcminutes)	Exp. Time (minutes)	Scan Rate (arcsec/sec)	spacing (arcsec)	UIP Command	Sensitivity** (mJy/beam)
10 x 10	9.3 x 10	12.26	30	30.3	BOX_SCAN  557.143 600 30.0 45	233
10 x 10	9.3 x 10	14.71	25	30.3	BOX_SCAN  557.143 600 25.0 45	212
10 x 10	9.5 x 10	14.14	40	20.2	BOX_SCAN  571.429 600 40.0 45	216
8 x 8	7.5 x 8	14.48	25	20.0	BOX_SCAN  451.765 480 25.0 45	171
8 x 8	7.7 x 8	14.22	35	14.7	BOX_SCAN  459.130 480 35.0 45	173
6 x 6	5.6 x 6	13.58	20	15.0	BOX_SCAN  338.824 360 20.0 45	132
6 x 6	5.8 x 6	13.58	30	10.2	BOX_SCAN  345.600 360 30.0 45	132
4 x 4	3.8 x 4	11.31	20	8.1	BOX_SCAN  228.571 240 20.0 45	97
10 x 8	10 x 7.6	15.08	30	20.2	BOX_SCAN  600 457.143 30.0 45	187
10 x 5	10 x 4.8	14.14	20	20.2	BOX_SCAN  600 285.714 20.0 45	153
12 x 6	12 x 5.8	13.58	30	20.4	BOX_SCAN  720 345.600 30.0 45	187
** 1 sigma sensitivity in one scan, assuming NEFD of 1 Jy/sqrt(s) per beam.  Numbers are tentative.....

First, note you can rotate the orientation of the box by using the /PA switch in the UIP command.  The scan can be done in the alt-az or ra-dec coordinate frames (/altaz or /equ in UIP). We have noticed that equatorial scans sometimes appear more striped, especially when parallactic angles are near +/- 45, 135, 225 degrees (which means the array is scanning along detector rows). We have the ability to rotate the array to avoid this, and the problem is being addressed in the data reduction. But for now, contact us if you want to do equatorial box scans. We also recommend adding about 30 seconds to the integration time to take care of delays within the data aquisition system between starting the scan and it actually recording data.

Designing your own scan

There are a number of constraints on the scan pattern:

1. It turns out that by starting the scan from the center of the map, the map size cannot be perfectly square, otherwise the scan will hit a corner, and the algorithm will fail.
   
2. There is also a choice in how far apart the intersection points are.  You want them to be less than the size of the SHARC array (to ensure the whole map gets sampled), but having them too close together means it will take longer to complete a scan.  
   
3. The scan rate should be fast enough to close out the scan in a reasonable time, but not so fast as to smear the beam.  Also, faster scans mean it is harder for the telescope to handle rapid change in direction at the boundaries.  

To adress the first constraint, first note from the figure that the scan pattern looks like a stack of "diamonds".  Doing the math, one discovers that for a scan pattern that starts at the center of the map, the number of "diamonds" on the X-axis and the number on the Y-axis must be different in the following way:  One must be an odd number and the other even.  Also note the the number of diamonds in the X and Y directions must not share a common factor.

How oversampled the map should be (via the spacing between intersection points) is not well studied, though with all of the maps made so far, there is nothing amiss with almost any reasonable choice.  In general, the spacing should be < 40 arcseconds, otherwise the map can potentially be undersampled.  Values under 10 arcseconds will take too long to complete for most maps, therefore should choose a value somwhere between 10 and 40 arcseconds.  Note that the beam width at 350 micron is about 9 arcseconds.  

The final constraint, scan rate, is also a matter of study, but we have typically used values between 20 and 40 arcseconds/second. These last two constraints should be made such that the total scan time takes less than about 15 minutes.  (protects against losing the whole scan if there is a problem, keeps the file size low, etc).

For mapping regions that are "square", it is a good idea to make the X axis the shorter one. The SHARC array is rectangular, and is aligned (more of less) withe X-direction. Thus you actually fill out the region more in this direction, and make up for the shorter size of the mapping area.

To help plan your scan, download, and compile the program boxscan.c.  Here is an example of it in action:

I want to scan a 10x8 arcminute region, relatively finely (ie small spacing).  

I start with a 10 arcsec spacing, and a 40 arcsec/sec scan rate

>./boxscan 600 480 10 40
BOX_SCAN  600.000  471.429 40.0 45 :      23.33 minutes
# WARNING: scantime exceeds 15 minutes

Hmmm...that won't work.  Scan length is too long.  I'll try a larger spacing (20.0 arcsec)

>./boxscan 600 480 20 40
BOX_SCAN  600.000  457.143 40.0 45 :      11.31 minutes

That's better, but now I wonder if 40arcs/sec is too fast.  I'll try an even larger spacing and a slower scan speed:

>./boxscan 600 480 25 30
BOX_SCAN  600.000  494.118 30.0 45 :      13.20 minutes

Wondering what the "45" is in the "BOX_SCAN" output?  It is the angle at which the scan starts.  This should always be 45.  Consult with us if you want to try other things.

One last thing

When the telescope does this scan, you note that the motion in each direction is a sawtooth.  ie:  plotting X position against time or Y position against time.  In order to avoid hard turns at the map boundaries, we have fourier expanded the equation for the sawtooth and keep only the first few terms (default is 3).  Thus the pattern is more "wavey" than shown in the above figure.  Use the /order switch when entering the BOX_SCAN command to set the number of terms used in the expansion.  The default should be fine, and we don't encourage using anything much higher.