• Introduction
• Three Ring Stacking
• Single Ring Stacking
• Code and Procedure for Three Ring Hysteresis Corrections
• Code and Procedures for Single Ring Hysteresis Corrections
• Stacking an Arbitrary (Small) Single Group of Mirrors
• Stacking Three Arbitrarily Selected Groups of Seven Mirrors
• Measuring Encircled Energy: EE(50) and EE(80)
• Fitting Moffat Functions and Gaussians
• Producing a Nightly Log From FITS Headers for PI's
• CCAS Profile Fitting to Determine Mirror Dispersion
• Analyzing Hexburst Data
• Code and Procedure for GETPIST
• Exposure Time Calculator for Fiber-Fed Instruments
• Using Hartmann Data to Predict On-sky Image Quality
• Creating New Tipfiles on the Fly

The second decision to be made regards the size of the burst pattern. The normal size burst is accomplished by running either flbst.tip or frbst.tip. These produce rings of 5, 9, and 13 arcseconds in mirror coordinates. The anti-burst patterns are created from a burst configuration by running either flcom2.tip or frcom2.tip. If for any reason, the anti-burst patterns are desired from a stacked state, this is accomplished via the flcom.tip and frcom.tip files. Sometimes, the stack is not quite good enough to allow the normal size patterns to be used. In this situation, larger patterns can be created using all the same tip files as discussed above but with the prefix big, for example bigflbst.tip. These produce rings of 5, 10, and 15 arcseconds. Stacking using these patterns will not do as good a job as the normal size but will improve things enough that the normal size can be used. Presently, only the manual code (see below) works with the big patterns.

After saving images of the burst and anti-burst configurations the TO has to decide what kind of stacking code to run. There are several flavors. All will automatically ftp the images from the nightly working directory to the iraf subdirectory of the guider account for manipulation by the stacking code. Typing bs9a from the iraf command line runs an iraf script called bigstack9a.cl which can be found in iraf/scripts/91. This is the most automatic version of the three ring stacking code. The script calls from within it a fortran program called bigstack9a. The source code can be found in iraf/scripts/91/source and the executable is in iraf/scripts/91. The TO needs to have an ximtool display up before running any stacking codes from within iraf.

The first thing that bs9a attempts to do is find all the mirrors in the anti-burst image. If it does not find the correct number it will beep and warn you. The cursor can be used to either add or delete mirrors with the a and d keys respectively. When satisfied that the mirrors have been found correctly the TO types the letter q with the cursor positioned on the ximtool display. The rough mirror locations are passed to a centroiding routine which more accurately determines their locations and then redisplays them. This process is then repeated for the burst image. At this point, the script looks at the image FITS headers and reads the tracker position so that the stacking code can automatically decide which side is being stacked. This option is currently commented out though since it has been found that the SENSYS camera software does not reliably put the correct tracker position into the FITS header.

At this point, the fortran part of the script takes over. It reads in the lists of mirror locations and checks the correct number were found. If not, the program exits. The capability to check that no two mirrors are too close together is in the code but has been commented out because it is somewhat redundant. The IRAF front end of the script uses the task STARFIND for the initial find and it has parameters which allow one to guard against this sort of thing. The code automatically finds mirror 43 and the starting mirrors in each ring on both images and circles them with different colors from the default red used for all mirrors. A file called stackpar8.dat is also read in. This file is in the iraf/scripts/91 subdirectory and tells the code a number of important parameters. In order these are the ring sizes, where to expect the gaps in the rings, X and Y offsets for location of mirror 43, the direction from which the SENSYS camera looks at the faceplate, the ratio of the axes of the ellipse created from circular patterns, the numbers of mirrors in each ring and where the burst and hysteresis tip files are.

The TO is asked which side of the mirror is being worked with and gives two choices. Picking a number other than the ones offered will force an exit from the program. The code tests that the three rings are sufficiently well separated to avoid confusion. If not, the TO is asked to decide whether to continue or not. After sorting the mirrors according to ring membership and angular position within rings, the program fits ellipses to the rings and de-projects the positions to compensate for the effects of viewing angle. Execution is finished by generation of a tip file called align.tip and an echo to the screen of various parameters that are solved during the stacking process. Deviation of these parameters from their normal values is often a clue that something has gone wrong and the align.tip file should not be applied. These parameters are stored in the header of the align.tip file.

Another stacking option, is to type bs9m on the iraf command line. This runs the script bigstack9m.cl which includes a call to the fortran program bigstack9m. The script, source and executable all reside in the same places as noted above. The letter `m' in this case stands for manual. The TO uses the mouse to pick the mirrors, sort them into rings and provide initial angular information within the rings. The code instructs the user as it runs on what to do. In all other aspects this code runs the same way as the automatic version. This code allows the TO to stack in those situations where they are able to visually tell which ring mirrors belong to but the automatic algorithm might fail.

If forced to use the Pulnix camera, there is code available to do this. Pulnix versions of the above code is run by typing bs9pa or bs9pm on the iraf command line for the automatic and manual versions respectively. The scripts, source and executable all reside in the same places noted above and adhere to the same naming convention.

Table Of Contents

In the interests of automation and time-savings, there is some lack of flexibility in the ts7 code. One must start with the left side of the mirror and work through the mirrors on that side in a pre-defined order. One then moves to the right side and works through it in a predefined order. Part of the time-savings are accomplished by using only burst configuration images. Without using anti-bursts, hysteresis corrections are larger and thus definitely needed. A more flexible, but slower and less automated code ts6 exists but will not be described here.

The first tip file applied by the TO is called sl1a.tip All the tip files described here can be found in the iraf/tipfiles/91/new subdirectory of the guider account on mcs. The sl1a.tip file is a combination of three other tip files: flout.tip, sl1pout.tip and sl1bst.tip. These three tipf files if invoked individually would move the right side mirrors out, then move all but the dozen mirrors in the first single ring of left side mirrors out, then burst those dozen mirrors. At this point, the TO takes an image, runs ts7 and applies the resulting align file. This stacking code runs similarly to the ones described in the previous section. Application of the align.tip file brings together the dozen mirrors in the first ring.

The TO then applies a tip file called sl2b.tip which is the combination of three other tip files called sl1pin.tip, sl2pout.tip and sl2bst.tip. If each of these files were invoked individually, they would bring in the rest of the left side mirrors, send all but the next dozen back out, then burst those dozen. Single ring stacking thus consists of working through a number of tip files, taking images and running ts7. The rest of the left hand tip files with the files they are a combination of in brackets are; sl3c (sl2pin, sl3pout, sl3bst), sl4d (sl3pin, sl4pout, sl4bst). At this point all the left side mirrors are sitting in an improved but probably still poor stack. Generally at this point a 3-ring stack is performed on the left side mirrors.

With a pretty good left side stack now in place but the right side mirrors still needing to be single ring stacked the TO works through the tip files sr1e (flin, sr1pout, sr1bst), sr2f (sr1pin, sr2pout, sr2bst), sr3g (sr2pin, sr3pout, sr3bst), sr4h (sr3pin, sr4pout, sr4bst) and then 3-ring stacks to finish off.

An even more automated version of the single ring stacking code was written in which each align file that is created also contains the next tip file to be invoked as well. This code ts8 was not fully de-bugged before I left.

Table Of Contents

Fundamentally, finding hysteresis corrections simply consists of stacking and measuring how much each mirror misses mirror 43 by. The measurements are made on images in which each mirror is brought in one-by-one for the sake of clarity. For three ring stacking corrections, the TO proceeds as if stacking the side of the mirror in question. The procedure should be started from as good a stack as possible given the corrections that are in place. If the mirror is to be pistoned, this should be done before attempting to obtain hysteresis corrections. Once the burst and anti-burst images have been obtained, the TO types bs8h from the iraf command line rather than the current command for stacking. The burst and anti-burst image are expected to be placed in the nightly working directory and are automatically ftp'ed to the iraf subdirectory for manipulation by the hysteresis code. The command bs8h runs an iraf script which resides in iraf/scripts/91 of the guider account on mcs. The script is called bigstack8h.cl and contains within it a line which runs the fortran program bigstack8h. The source code for this program resides in iraf/scripts/91/source and the executable is in iraf/scripts/91.

The code runs the same way as the stacking code except it does not apply whatever corrections happen to currently be in place. Like the stacking code, bs8h will generate a file called align.tip which can be used to bring the mirrors in to a stack all at once. This file uses the corrections currently in place. When running, the code will ask the TO whether to fall short, or long. This refers to whether the mirrors are to be intentionally brought up short of mirror 43 or sent past it by known amounts. This allows hysteresis to be determined for mirrors which otherwise would fall too close to mirror 43 for easy measurement. The amounts by which each mirror is either pulled up short or sent long are contained in a file called addto.tip that is generated each time bs8h is run. These numbers thus have to be added back in at a later point in the hysteresis determination hence the file name.

The TO's task once bs8h has finished running is to bring mirrors in one-by-one, snap an image, and then send them back out. This is accomplished by way of individual files called bringinXX.tip where the XX is the mirror number. The fortran code bigstack8h generates a single large bringin.tip file which is then broken up into 45 smaller single mirror files by the program split45. These single mirror bringinXX.tip files are not automatically ftp'ed to smoke. I found the automatic ftp very slow, perhaps due to excessive hand-shaking but I have to admit, I made little effort to find a way to speed things up. Instead, these files are all just dumped into the iraf subdirectory and it is left up to the RA, to mput them over to smoke, a process which runs very quickly. When bringing in the mirrors one-by-one, somebody needs to watch the TV monitor as the mirrors come in, to ensure that they either come short or go long as intended. If not, this needs to be noted for later in the image analysis. If the RA is attempting to measure the images as fast as the TO obtains them, it is most efficient for the TO to watch the mirrors come in. If the RA intends to measure the images at a later date, he/she can watch the mirrors come in.

Measurement consists of running the iraf script smh. This script can be found in the iraf/scripts/grant subdirectory of the astronomer account as smhyst.cl. This script trims the images so will probably need to be edited for the correct trimming before running. When running, the script should find mirror 43 and the subject mirror automatically. Hitting the l key with the cursor on the ximtool will show with red circles what has been found. If one or both mirror were not found automatically, you will need to move the cursor to the mirror you wish to add and type a. Once all mirrors have been located, type q. The approximate mirror locations are passed to another part of the script where centroids are calculated, and the image redisplayed. Typing l and then q will show the centroided positions, and continue the running of the script. Occasionally mirrors fall too close to mirror 43 and the centroiding smears them together. In these cases, the iraf command daofind may allow the mirrors locations to be found. The iraf command tvmark will allow you to display the locations found by daofind.

Prior to running smh, I open a file that has a name something like left.20000523s.meas which is where the measured mirror locations will be placed. This is in iraf/for/hyst. The naming convention, denotes which side of the mirror and the date. The last letter before .meas is either an s for short or an l for long. The file is just a free-format ascii file. Column 1 is the mirror number, columns 2 and 3 are the X and Y location of mirror 43 in CCD space. Columns 4 and 5 are the X and Y location of the subject mirror in CCD space. The fact the images have been trimmed does not matter. It is only the location of each mirror relative to mirror 43 which is important. You can thus change the trimming part way through obtaining the hysteresis images if need be.

After the all the images have been measured, I close the file and copy it to another file called xy.in. This file is read in by the program hystcal2.f which converts the measurements to hysteresis corrections in tip-tilt space. Prior to running this code, make sure that you have a file called addto.tip sitting there which is the correct one for the case at hand (either long or short). The output file is called hyst.out. I immediately copy or move this output file to one called something like left.20000523s.hyst.

Generally I like to test each set of corrections individually. Measurement blunders tend to stand out as obvious outliers. When satisfied that each of the long and short corrections are okay, I average them using a little fortran program called avg. This expects two files called hyst1.tem and hyst2.tem and generates output called avg.out. The avg.out file can then be copied to either flcor.tip or frcor.tip (left and right respectively). These files reside in iraf/tipfiles/91/new

Table Of Contents

The first step involves running the script mkarb from IRAF within the guider account. Previous runnings of the code will have created a bunch of files starting with the 3 letters arb. Copies of these will exist in tipfiles/91 and will be overwritten unless they are moved somewhere else or renamed first. These are the tip files needed to burst, anti-burst, isolate, etc. the desired group of mirrors. The mkarb.cl script is in the iraf/scripts/91 subdirectory of the guider account. The next step involves running the Fortran code mkarb, the source and executable of which both reside in iraf/tipfiles/91. The mkarb script calls the Fortran code automatically. The user will be prompted for the ring radius, the offset of the mirror from 43, the number of mirrors in the ring, the starting angle and the last angle for mirrors in the ring. The smaller the ring radius the better. If undecided or if the stack is poor, pick some fairly large number and then use a much smaller number on a re-stack. If mirror 43 is to be the center mirror then enter zero for the offset, otherwise pick some number such that there will be no confusion as to which mirror is 43. The user is then prompted for the center, 1st, 2nd, 3rd and so on mirrors in the ring. You have now created all the tip files necessary to go on to the next step. They will be automatically ftp'ed to the PMC/log subdirectory on smoke and the user notified as they move over.

After using the various tip files just created to form burst and anti-burst configurations of the mirrors and save images the TO is ready to run the script stackarb from within IRAF. This code behaves similarly to most other stacking codes and will automatically find and centroid mirrors. If mirror 43 is not meant to be part of the stack, it will have to be deleted. If the rest of the mirrors have not been moved out far enough, they will create a lot of finds that have to be deleted. The script stackarb.cl and the executable for stackarb reside in the iraf/scripts/91 subdirectory of the guider account on mcs. The fortran source is one more subdirectory down in /source.

Before running this code, the TO needs two things; all 91 mirrors sitting there in something like a reasonable stack, and an ascii file in /home/mcs/guider/iraf called mirror.lis. This file is 21 lines long and contains a mirror number on each line. The first 7 lines must be the mirrors in the list are the mirrors in group 1, lines 8 through 14 are in group 2 and the last 7 lines are in group 3. The first mirror in each group will be the center mirror of its pattern (i.e. lines 1, 8 and 15). Mirror 43 does not have to be any of the 21 mirrors, but obviously if it is, it will have to be one of the center mirrors. Probably the most convenient place for it is line 15 (i.e. the center of the pattern for group 3). The groups don't have to be physically clustered together on the telescope, nor does the center mirror have to be the center of a 7 segment sub-array on the telescope.

The next step is to run the script mk3x7 from within IRAF on the guider account. You will be prompted for the ring radius and group offsets. The smaller the ring radius the better. 3.0 arcsec will work but you may want to experiment by using less. In theory the smaller the better. This script, makes a bunch of tip files and automatically ftp's them to smoke. The in/out tip files all have names like first3x7out.tip, second3x7in.tip, etc. The bst and com files have names like bst3x7a.tip, com3x7b2.tip etc. The a,b,c after the 3x7 reflects whether they work with the first, second or third group. If there is a 2 after the a,b,or c, then its a double motion.

If mirror 43 is in one of the groups, you will want to answer 0.0 for the offset for that group. If it is not in any of the groups, you will want to design your offsets such that it is easy to spot and delete during the automatic find part of the image analysis.

A lot of tip files are created when running mk3x7 and the automatic ftp takes awhile. I have ordered the ftp though so that all the ones you need to get started can be used while the others are still going. For example, first3x7out is the first one to go over. After running the first3x7out tip file and the bst3x7a and com3x7a2 tip files and saving your images you run the script stack3x7 from guider's IRAF. This stacking code will prompt for the ring radius being used and which group of 7 being worked on. While stacking some mirrors not being worked on can be hidden in the pinhole.

After sending out and stacking the second and third groups, you will have 3 groups sitting there and may want to improve one or more of them before sending one down the pinhole. This can be done using the bst and com files already created or a second running of mkarb can be attempted with a smaller ring radius given. If you do this though, care must be taken to give the same answers to the other questions.

Table Of Contents

The script ee.cl calls some fortran code, eeconvert, both the source and executable of which live in the same place as the ee.cl script. One of the purposes of this code is to convert the measured EE(50) and EE(80) values from pixels to arcseconds. In theory, this can be handled by the iraf portion of the code, but in practice there is a bug in the task which is called (psfmeasure) and it is unreliable when asked to do the conversion.

If wild cards are given in the image list, and multiple images are measured then the average value of the N measurements is output. The version of the ee.cl script on the astronomer account goes a step or two further and outputs the min and max values, the median values and the standard deviations about the means.

Depending on the image sizes and crowding in pixel space it may be desirable to change the radius, sbuffer, swidth and iterations parameters. For crowded images, one is sometimes forced to use fewer iterations. The radius parameter is the radius of the part being measured. The swidth parameter is the width of the annulus for sky determination and sbuffer is the width of the region between that being measured and the sky annulus. A logfile of the results is produced called ee.out.

There is an iraf script, run by typing mof from the iraf command line. This script runs and behaves exactly the same as the script for measuring encircled energy. The script itself can be found in the iraf/scripts subdirectory of the astronomer account on mcs. The script is called mof.cl and it calls the fortran code mofconvert, both the source and executable of which can be found in the same subdirectory as the script. This code handles the same part of the job as eeconvert for the same reasons. Wild card in the image list are handled the same way as when running the encircled energy script. The parameters radius, sbuffer, swidth, and iterations have similar meanings to those in the encircled energy script and may need to be changed accordingly.

Where this script differs from the encircled energy script is that it fits moffat profiles and gaussians to the images. The moffat beta parameter is free to vary as is the MFWHM. A logfile is created of the results called mof.out.

I have also written some fortran code which can be used to fit moffat functions and gaussians to one dimensional profiles. The source and executable are in the for/misc subdirectory of the astronomer account on mcs. These codes are run from the unix command line by typing either mfit or gfit respectively. Each one expects an input file called prof.dat. These input files can be very large, free format, files. The code will prompt the user for how many points, and what kind of binning is desired. The mfit code produces two output files. The mfit.curve file is the fitted moffat function and mfit.points are the input data re-binned as desired. Similarly, the gfit code produces gfit.curve and gfit.points. The files of input points can be generated using the iraf task pradprof which is in the plot package. The list parameter needs to be turned on.

Typically when one is running LRS one has two iraf windows open. For one of these, one starts in the ICE subdirectory, starts iraf then loads the icex and het packages. For the other, one starts in the iraf subdirectory, cd's to the ../ICE subdirectory and then loads the icex and het packages.

To generate the README file, use the window that was in the iraf subdirectory when iraf was launched and cd to the subdirectory where the night's worth of data for a given instrument is stored. Type pirm on the command line. This will run the script pirm.cl which resides in the iraf/scripts subdirectory of the astronomer account on lrs. This script also calls a fortran program called pirm. The source and executable also live in the same place as the script.

There is a version of the script described above for ufoe data but at this writing it is not anticipated it will ever be needed again. Nevertheless, for completeness sake, that script, and the fortran source and executable are in the iraf/scripts subdirectory of the astronomer account on mcs.

Table Of Contents

The process of finding the dispersion of the mirrors within the stack starts by building up a library of individual mirror profiles. EE(50) and EE(80) have become the `coin of the realm' at HET and as a result it is often forgotten that these numbers are just measurements of the stack. They do not provide extensive information about the actual shape of image profiles. It is my belief that Moffat function fits provide a good compromise between giving detailed information about profile shapes and ease of use for the purposes discussed here.

The first step is thus to take the burst and anti-burst images that went into creating a stack and fitting Moffat functions to individual mirror images. This is best done using the task psfmeasure in the nmisc package of IRAF. There will be at least two burst images and two anti-burst images so one has some choice. The intention with this step is not to have a library that contains the exact profiles for every single mirror. Rather, it is to have 91 profiles that are representative in a statistical sense of the range of profiles present. Using the psfmeasure task, measure as many different mirrors on as many different images as possible until 91 mirrors have been measured. The output from the task will be a log file containing among many other things, the Moffat FWHM and beta parameter of each fit. Transfer these numbers to a file called singlemirror.dat. The file must be 91 lines with MFWHM in the first column and beta in the second column. No other format restrictions are necessary. There is one point that one must be careful about when it comes to measuring the single mirror profiles. The three circular rings of the burst and anti-burst images are turned into ellipses by the viewing angle of the SENSYS camera. This implies that if one gets too far from the major axes of these ellipses, there will be some de-focus effects. It is thus best to avoid measuring mirrors too far from the major axes. In general, the compromise I accepted between using a significant number of different mirrors and limiting their distance from the major axis of a given ellipse was to avoid measuring farther from the major axis than roughly the radius of the middle ring.

The second step in obtaining the mirror dispersion in a stack is to fit Moffat profiles to the stack images. Another section of this document describes using the IRAF script mof to do this. This provides one with values of MFWHM and Moffat beta characteristic of the stack.

The third step is to run the program fitstack. It will prompt you for the MFWH and Moffat beta values for the stack. It will use these to recreate the stack. The user is next prompted for a seed for the random number generator. There are sophisticated ways to do this in a truly random and automated sense but I did not have the time to code these up so it is up to the user to enter some random integer. Enter your phone number when you were a kid or your wife's birthday or whatever. The next prompt is for the maximum number of iterations. Typically the code converges in about 40 or 50 iterations so picking 100 is safe. If it hasn't converged by then, then something may be wrong or you picked really strange initial values. The next prompt is for an initial value for the dispersion in arcseconds. The last prompt is for a starting value for a scale factor. This is a number explained below which typically lies in the range 30 to 60.

As the code runs, it generates a two-dimensional recreation of the stack. A set of 91 random directions from the origin are generated, with each generation equally likely. A set of 91 distances from the origin are generated with a Gaussian distribution (unit sigma). The library of MFWHM and Moffat betas are used to generate 91 two-dimensional single mirror profiles and place them at the locations specified by the distances and directions previously generated. They are numerically summed to create a stack that is the sum of 91 single mirror profiles which can be compared to the recreation of the real stack in a chi-squared sense. The rest of the program execution involves varying two parameters to search chi-squared space and find a best fit. Of the two parameters, the one that is of most interest is the dispersion about the origin. The other parameter is a scale factor needed to normalize the sum of 91 single mirror profiles to the recreated stack. It is simply a multiplicative factor.

The output from the code is printed to the screen, letting the user know what Gaussian sigma and scale factor were found, how many iterations were required and what the final chi-squared value was. There is also provision in the code to generate ascii files of the recreated real and single-mirror-sum stacks as fit1.out and fit2.out respectively. This ability is commented out at the moment. If desired, these ascii files can be read into IRAF and displayed for measurement. Finally, it must be realized that the dispersion found via a single run of the program fitstack is dependant on what random seed number was given. One can only get some estimate of the dispersion in a statistical sense via averaging some large number of runs of the code. I never got around to automating this aspect of the code. The user will need to run the code as many times as they can endure to make the approach as Monte Carlo like as possible. Each time a different random number seed needs to be given. I recommend running the code at least of order a dozen times.

Table Of Contents

After copying one of the files containing Moffat parameters into a file called singlemirror.dat the next step is to run the program skystack. The source and executable for this lives in the for/hexbst subdirectory of the astronomer account on mcs. As it runs it will prompt the user for the dispersion, and the number of mirrors. It will then generate 10 artificial sky stacks with the given dispersion, built up from the single mirror profiles provided via the file singlemirror.dat. This can then be repeated for the other sets of single mirror profiles.

The 10 artificial sky stacks have the names fitXX.out where XX is a number. These are ascii files which can be read into IRAF using the task rtextimage with dimensions set to 121,121. These artificial (perhaps reconstructed is a better word) stacks can then be measured for EE(50) using IRAF and compared to EE(50) for the stack as actually observed on the sky. One can define an X-factor as being the square root of the difference between the squares of these two. One must be careful though not to attach too much physical significance to this number since neither the stack, nor the single mirror profile are Gaussians. In fact even though the dispersion is assumed to be Gaussian in the modeling described here and in the previous section, we do not know to what degree this is absolutely true.

An interesting additional number can be found by entering zero, when prompted for the dispersion, the value for a perfect stack with a perfect SAC can be found as well. In this later case, all ten artificial stacks will be identical since there is no dispersion.

A second way is to make many more measurements than the minimum necessary and then solve for the ``best'' corrections in a least-squares or arithmetical average sense. Currently, for 150 measurements, doing the arithmetic by hand takes about 2.5 hours.

There is C shell script which resides in /home/mcs/astronomer/for/piston that solves for the ``best'' corrections in a least squares sense in about 5 to 10 minutes. The script is called getpist. Since it is a C shell script, it is run by typing csh getpist from the unix command line. The script calls two fortran program called piston1 and piston2. The source code and executable for each of these program reside in the same directory as the script.

In /home/mcs/astronomer/for/piston is a file called piston.init which normally will not need to be changed but can be. Each line of this file is the mirror number, the initial value for that mirror's correction, and the starting step size for a coarse grid search. Note that mirror 43 has a step size of zero. This forces the code to return a zero correction for that mirror. If any other mirrors are either not measured or desired to have null corrections the step size of those mirrors can be changed to zero. The default starting values are all zero under the assumption that corrections are as likely to be negative as positive. Note that 110 microns is the step size for the coarse grid search. This will be divided by 10 for the medium grid search and by 10 again for the fine grid search so that the step size for the fine grid search is 1.1 microns. I suspect that a step size of exactly 1.0 microns could lead to numerical instabilities hence the choice of 110 microns for the starting coarse grid search. Normally when I write code I prefer to avoid formatted input but for reasons which will become apparent below I have written this code so that I/O is formatted so you will need to pay attention to this if/when you edit piston.init.

The other file which needs to be in /home/mcs/astronomer/for/piston is called piston.measure. This file contains the actual measurements. It is formatted and examination reveals why. Each lines starts with two digits, then the letters `wrt' and then two more digits. This forces you to enter measurements in the correct sense, for example 32wrt43 means the measurement of mirror 32 with respect to mirror 43. The second column is the measurement and the third and final column is the weight. Currently there are 150 lines which is the total number of possible measurements if none are made which `circle the mirror'. If a given measurement is not made, the weight can be set to zero.

The output is a file called getpist.out. The first column is the mirror number, the second column is the correction to be applied, and the last column is the step size last being used. In the absence of noise, (i.e. perfect measurements) these numbers would be the opposite of those in the measurements file. For example if there was a line in piston.measure:         32wrt43     148     1

then the correction would be -148 microns. In other words, 32 was measured to be 148 microns higher than 43 so it needs to be lowered by 148 microns.

I have tested this code a grand total of one time so some care should be taken before blindly trusting it. The one test involved taking the measurements made by Matt Shetrone, running the code on those measurements and comparing the output to the corrections he found by hand. Matt tells me it took 2.5 hours to do all the arithmetic. The code took about 10 minutes to run and found numbers virtually identical to the ones Matt found. The largest difference was about 6 microns and typical differences were about 1 or 2 microns.

Table Of Contents

As its name implies, the code was originally intended for use with ufoe but should be useful for HRS as well. The code assumes that ee50 is equivalent to GFWHM and then actually creates two-dimensional artificial profiles for each of the two ee50's entered. Each profile is then actually two dimensionally integrated out to the fiber in question. The ratio of these two quantities gives the multiplication factor necessary.

When hmstack is running it expects a file of moffat fwhm and beta values called realmirror.dat. The file can be any number of lines long but must have MFWHM in column 1 and moffat beta in column 2. The values are expected in pixels and a plate scale of 0.115 arcsec per pixel is hardwired into the code but is easily changed via a single parameter and re-compilation. Likewise, the hartmann x-y values are read from a file called xy.dat and are in pixel space. When looking over the source code as I write this, I see that the x-y values are multiplied by the plate scale and an additional multiplicative factor of 0.6. The reason for the factor of 0.6 escapes now but since this code was put together expressly for the purpose of dealing with data obtained with Booth and O'Donoghue, I suspect it had something to do with the x-y values furnished to me by Darragh. Future users are urged to consider whether the parameter is appropriate for their data.

The output of hmstack is an artificial image made by co-addition of individual moffat profiles placed at the locations specified in xy.dat. Each profile has a MFWHM and beta that is the average of all those in realmirror.dat.

A program called altertip will prompt the user for the name of an already existing tipfile. It expects 10 comment lines, followed by any number of lines with mirror number, tip and tilt in columns 1, 2, and 3 respectively. The user is next asked for a numerical expansion or contraction factor. This number can be negative to turn a burst file into an anti-burst file for example. The program ends with the user being asked for a name for the new tipfile, which it then creates.

Another useful program is called mkring . This bit of code allows the user to create rings of any radius, with any number of mirrors in them. The user is asked what angles they want the first and last mirrors in the ring to be (i.e. where the gap is). The next prompt is for the number of mirrors and then the radius. The output is not to a file but to the screen. This can then be pasted into a file if desired. Only the tips and tilts are spewed out so the mirror numbers need to be manually entered.