The heart of the software is contained in the Extraction step, where essentially all of the heavy lifting occurs.  It is a slow process, taking roughly 15 minutes per science frame on a fairly modern MacBook pro.  During extraction, the following steps are performed:

  1. A 2D wavelength map is determined by matching each order to a template spectrum of the OH sky lines and/or ThAr arc lamp spectra.  This produces an output file containing the log of the wavelength for each pixel on the array (and in an order).  The wavelengths are corrected for heliocentric velocity shifts, and are in vacuum units by default (since the instrument is in vacuum).
  2. The software calculates tilt of the slit in each order for accurate sky subtraction.
  3. A first pass 2D sky subtraction is performed for the purposes of object finding.
  4. Each order is collapsed in the wavelength direction to locate the object trace.  The trace is then fit over the full order.
  5. An iterative procedure is used to perform a simultaneous fit of both the object profile and background sky residuals.
  6. An optimally-weighted extraction is performed using the profile determined in (5).  
  7. Spectra are stored on an order-by-order basis in units of counts vs. wavelength.

For high signal-to-noise ratio data, a non-parametric b-spline is fit to the object profile; at lower SNR a Gaussian model is used. 

This process was fully automated in early versions of the pipeline but we have begun adding the ability to set user preferences for extraction.  To edit the preferences, click the corresponding button on the lower left hand corner of the "Extract" tab:

This will bring up a separate preferences panel that looks like the following:

Ongoing development for the pipeline is currently focused on increasing the range of options available to the user, but at present a few have been implemented:

  1. Slit tilt mapping: Fit of the slit tilts is a critical part of the sky subtraction and wavelength calibration process.  Usually this happens in the background but it is sometimes useful to see the results, particularly if an error has occurred downstream in sky subtraction.  Setting this tab from "Silent" to "Inspect Results" allows you to see which lines were used to define the slit tilt and how the fit performed.  This mode is very slow since it displays rectified arc images for each of the 20 orders one by one for each exposure.  In normal operation it should not be used, only to diagnose problems, or to familiarize yourself with the pipeline on first use.  Debug mode includes additional stops in the code and is generally not useful for non-experts.
  2. Wavelength Calibration file type: The default in FIREHOSE is to use the OH sky lines for slit-tilt mapping and wavelength calibration for exposures longer than 300 seconds.  For those less than 300 sec, ThAr lamp exposures are used.  Using this tab the user can force ThAr to be used for all exposures.  In principle one could force OH for short exposures but in our expedience this has not worked well.
  3. Interactive Wavelength Fits: If you have lots of time on your hands, you can inspect the arc line fits for each order and each exposure interactively.  Turning this on will pop up a GUI for each order's fit showing the automatic line IDs, and allowing you to add or reject points and adjust the fit by hand.  Plan on spending an hour or more per exposure if you use this mode, but it does give you total access if you are a control freak.  The GUI is much like iraf's reidentify.  It is based on the x_identify.pro procedure distributed with xidl.
  4. Object/Aperture Finding: The FIREHOSE automated object finder works well for point sources with continuum detection in many/most orders.  However if your exposure shows only emission lines, or has no continuum (but you know where it should fall on the slit), or if you want to force a particular aperture, then there are options to set the trace location and apertures by hand.  
    1. User/interactive aperture definition: In the case where many orders have no flux but one or a few emission lines are visible, it is possible to define the aperture around these emission lines.  There is a separate GUI associated with this operation. See this link for a page describing how to perform this operation.
    2. Reference Star tracing: This mode is useful when there is no flux visible from the science object, but you expect the science target to fall at the same slit position as a reference object (e.g. a blind offset pointing star, or a telluric standard star).  It is available in beta mode only and the mechanism for associating reference star exposures with science frames is somewhat clunky.  Nevertheless by popular demand we include information on how to run it at this link.  Note that it is now possible to use this in conjunction with post-processing routines to make a rectified and flux-calibrated 2D spectrum that is appropriate for running extraction with your own routines.
  5. Extraction Options: The default mode is to extract optimally (a la Horne) using either a non-parametric weighting function fit to high-SNR data, or a Gaussian fit in the low-SNR regime.  The user can change this option to run in straight boxcar mode as well (i.e. simple sum of flux within the defined aperture).  Users observing bright objects, where saturation or high counts are an issue, will want to extract in boxcar mode.  Users extracting faint objects will find better performance in optimal mode.  Note that in optimal mode the sky subtraction performs better because FIREHOSE performs an iteractive local correction to the sky and object model to minimize sky residuals after the standard Kelson-style 2D sky subtraction.  Boxcar does not perform this second iteration, but it does run much faster (10-15 seconds, as opposed to 10 minutes).
  6. Clobber toggle: By default the pipeline does not overwrite working and ancillary files during the reduction process, in order to save time.  With this flag turned on, the full reduction is overwritten.  This ensures a clean run but is slower.  In future releases we plan to separate out the clobber functions for arcs, extraction, etc independently.

During extraction, you will see plots of the object profile appear to indicate data quality.  The plots show a cross section of the object profile with errors, and the resultant fit.  As the iterative model fit and local sky subtraction improve, you should see the residuals in this plot diminish, through each iteration on a given order.  

Because this process is slow, it can take a day or more to reduce a full run or data.  In many cases you are interested in a particular object.  You can choose a subset of the full target list to extract to speed the process.  To do this, simply highlight the names of the targets you want to extract given the list at right of the panel. If you have already reduced some of your frames, firehose will not re-reduce them unless the "Clobber" button is pressed.

  • No labels

20 Comments

  1. Unknown User (palunas_1@touchstonenetwork.net)

    Hi Rob, I started reduction at the telescope and am resuming at home. The order mask is is saved with a full path name and is therefore not being found:

    /Users/obs1/proc_data/redux//Flat/Orders_0042to0048.fits

  2. Unknown User (jane.rigby_1@touchstonenetwork.net)

    FIREhose is crashing when I use a separate off-source spectrum for the sky:

    x_fndsplin: Warning -- val not bracketed
         objstruct = long_obj_create(norders, slitid=1, ny=ny)
                                                     ^
    % Syntax error.
      At: /Users/jrrigby1/Idl/FIRE/Extract/fire_findobj.pro, Line 187
    % Compiled module: FIRE_FINDOBJ.
    % Attempt to call undefined procedure/function: 'FIRE_FINDOBJ'.
    % Execution halted at: FIRE_PIPE         441 /Users/jrrigby1/Idl/FIRE/Utils/fire_pipe.pro
    %                      FIRE_EVENT       1063 /Users/jrrigby1/Idl/FIRE/firehose.pro
    %                      WIDGET_PROCESS_EVENTS
    %                      $MAIN$          

    1. Unknown User (kendrew_1@touchstonenetwork.net)

      I managed to run the pipeline with a dedicated off-source spectrum today. I didn't have to do any major hacking, I think it's just a question of getting the setting right. You need to edit the structure so that:

      • the sky frames have Object Type: SKY
      • the sky frames have Object ID: -1

      In my particular set of observations the sky pointings were classified as SCIENCE, and allocated an object ID that was the same as the source pointing. When you then try to run the pipeline, it will assume these are both science pointings, try to extract a source in the sky frames and subsequently crash because no source is found. 

      I still have to check the actual quality of the sky subtraction, but at least the pipeline seems happy with these settings in my case. Does this work for others?

      1. Hi, Sarah is right about this fix, and an improved version of the code is now checked into the repository.  There are instructions on how to use this feature here

  3. Unknown User (k.allers_1@touchstonenetwork.net)

    If I want to use the extracted spectra (before telluric correction), how do I read in the extracted spectra and wavelength solution for each order?

    1. The extracted spectra for each order are stored in the file Object/Obj_0123.fits.  If you read in extension 1 from this file using mrdfits or some similar program, you will see an IDL structure.  In this structure, the un-telluric-corrected, un-fluxed raw extraction counts are in the structure tags WAVE and FX.  In other words

      IDL> tmp = mrdfits("Obj_0123.fits",1)

      IDL> order_index = (some # from 0 to 20)

      IDL> wavelengths = tmp[order_index].wave

      IDL> counts = tmp[order_index].fx

      The FLUX tag (as opposed to FX) has the flux-calibrated individual orders, but only after telluric calibration has been completed.

       

  4. Unknown User (phil.massey_1@touchstonenetwork.net)

    deleted

               

  5. Unknown User (phil.massey_1@touchstonenetwork.net)

  6. Unknown User (gwen_1@touchstonenetwork.net)

    I am attempting to use the new "Object/Aperture Finding" feature that says "reference star" assuming that this allows me to use the trace of a bright star exposure to guide the extraction of my fainter frames where emission isn't detected in a single exposure in all of the orders. The one thing that isn't clear to me is how I tell the code which "reference star" exposure should be used for which science exposure. I tried running the code thinking it might just have a prompt that asked for the star exposure name, but it crashed (I assume because I hadn't told it what star to use) right after printing "Using trace reference star: will take extra time to sky-subtract before tracing...". Is there a variable within the structure I should be setting? Should I do so manually with e.g. mrdfits and mwrfits, or am I just missing a GUI that needs to be filled out? Thanks!

    1. Hi Gwen - You nosed ahead of the supported modes, and found the tags in there to activate some stuff that was under development.  But, there is no reason not to let you give it a try if you like.  As you correctly noted, the trick is how to get firehose to associate the correct reference star frames (typically tellurics) with their respective science frames.  I have updated the wiki with a new page (linked here) that explains in somewhat awkward language how I perform this operation.  Take a look and see if works for you - good luck!

      1. Unknown User (gwen_1@touchstonenetwork.net)

        Hi Rob - Thanks! I had found the OBJTRACEFILE keyword, and had gone ahead and set it with code I wrote myself. I had not notices the POSSLIT keyword - but the code seemed to run fine without that keyword set. Maybe it was just comparing an empty string for the ref. star with an empty string for the science frame? One quick question though, what does the code do if there is no detectable trace in the science frame? Is there a way to tell it to use both the center and the width of the ref star frame? Or does it only work with the width? Thanks!

        1. In reference star mode, the code should use the OBJTRACEFILE exposure to find both the trace center and its width by default.  This happens on line 546 of fire_pipe.pro where a 2D object finding image is generated and then passed to the object finding routine on line 565.  This creates an object structure that contains (among other things) the objet trace information for each order and its FWHM.  If you want to view the object structures, they are saved in the "Object/Obj_xxxx.fits" files in your reduction directory.  The TRACE tag shows where your extraction thought the trace center was for each order.

  7. Unknown User (enewton_1@touchstonenetwork.net)

    I'm getting some pretty large errors in the wavelength calibration using a 60sec ThAr spectra - as much as 1.2 pixels for the RMS. Most of the RMS values are split between 0.6 pixels and 0.06 pixels. Is this difference between orders normal?

    1. There are a few orders where the ThAr lamp has very few lines.  These will have large RMS because we can't perform many rounds of iterative fit and rejection of bad lines.  I'd expect a couple of orders to do worse, and the code should report NLIN for these orders which I'd expect to be pretty small, <~5 or so.  We try to keep most orders at <0.1 pix RMS but it tends to work better if you use the OH sky lines for wavelength calibration, since they are more plentiful than ThAr (I realize you don't always have that choice though).  If you are getting 1 pixel residuals for many orders, it would not be normal.  It should be worst for the orders that span the telluric absorption bands between J/H and H/K, where the data often get discarded.

      1. Unknown User (enewton_1@touchstonenetwork.net)

        Thanks, Rob! It's probably fine in that case.

  8. Unknown User (enewton_1@touchstonenetwork.net)

    Hi Rob, I've been looking in to the process behind fire_gprofile. I can see that starting from some fixed position based on the FWHM, the left and right limits of the extraction window are slid inwards until certain criteria are met. I'm sometimes getting very different left and right limits (e.g. 1.5-2.5 for one side, 3.5 for the other) that certainly don't look like they are sampling the same part of my fairly-Gaussian bspline profile model. Given that I'm not worried about S/N (unlike many users!), I'm happy to hardcode in some reasonable limits (and this does seem to be working fine).

    There's also a case statement for "degenerate profiles" which is always triggered, given that the left and right limits are defined as being less than and greater than 0, respectively. This seems to enforce exponential decay beyond the limits, and masks some sky. The forced profile doesn't always follow my data, and I'm wondering if that's an issue, or exactly what's supposed to happen.

    1. I will admit to knowing less about the inner workings of the gprofile code as this was inherited from xidl routines written by Hennawi and Prochaska.  If you are getting very asymmetric profiles, it could be that your star is very close to the edge of the slit.  My guess is that a hardcode will work fine in your case but that's for you to decide based on your requirements.  It is worth mentioning that for very high SNR data, I usually advise people to use boxcar extraction rather than profile fitting.  The SNR advantage in the bright regime is not super strong, and the flux calibration for boxcar is slightly better because it doesn't depend on the precision of the profile fit.  The profile can vary ever so slightly across even a single order, and the errors become more pronounced when the object trace extends way out far away from the blaze peak.

      1. Unknown User (enewton_1@touchstonenetwork.net)

        Thanks, Rob. I have been finding that the flux calibration is significantly better with the boxcar, but that the benefit of better rejection of cosmic rays, etc. outweights it for some of my early observations.

  9. Unknown User (enewton_1@touchstonenetwork.net)

    If anyone is using long ThAr exposures for wavelength calibration and having issues, I'm happy to fill you in on the various changes I made.

     

    1. Unknown User (mreiter_1@touchstonenetwork.net)

      Hi Elisabeth, it would be great to hear about the changes you made for ThAr wavelength calibration.