The RHESSI spectrum software can be used from the IDL command line or the RHESSI GUI.  A useful guide to accumulating a spectrum from the command line or the GUI is here.

The spectrum software starts with an hsi_spectrum object.  By setting parameters in the spectrum object, you control the spectrum accumulation. 

The spectrum control and info parameters are listed in the Spectrum Object Parameter Table.  The control parameters most commonly set in the spectrum object by users are as follows (control parameter name in parentheses).  Look in the table for more description of each parameter.

• time intervals (obs_time_interval, time_range, sp_time_interval)
• energy bins (sp_energy_binning)
• detector segment selection (seg_index_mask)
• front segment decimation correction (decimation_correct)
• rear segment decimation correction (rear_decimation_correct)
• data units (sp_data_unit)
• structure or array returned by getdata (sp_data_struct)
• separate detectors or combined (sum_flag)

To make a spectrum from the command line, you create a spectrum object, set your options, and request the data.  As with all the RHESSI objects, all of the parameters are set to default values (shown in the parameter table, or by typing print,o->get(/xxx)) and you need to set only the values that you want to change.  The only parameter for which there is no valid default is the time interval - you must set the obs_time_interval and/or sp_time_interval parameter.  For example,

returns the spectrum in an array dimensioned [77,180] in counts units binned into 4 second bins covering the time interval specified, and binned into energy bins specified by binning code 14 which gives 77 energy bins.  If sum_flag were 0, then the array would be dimensioned nenergy x ntime x ndetector.

Energy Binning

There are a number of pre-defined binning schemes that set up the energy bins appropriately for different kinds of studies.  Select one of the binning codes, e.g. code 11 for gamma-ray line flares,as follows:

If you have a binning scheme that you think would be of general use, send your binning specifications to hessibugs@hesperia.nasa.gov, and we can add another binning code.

You can also define your own bins by specifying either a 1-D array of edges, or a 2-D array of start/end values, e.g.

Time Binning

There are three control parameters that specify the time interval and binning:

• obs_time_interval - start/end of overall time interval in absolute time format
• time_range - normally [0.,0.] meaning use all of obs_time_interval. Or, can specify a start/end time in seconds relative to start of obs_time_interval to use. Or can specify an absolute interval, which will supercede obs_time_interval.
• sp_time_interval - If scalar, then this is width of bins in seconds. If an array, then defines the edges of the time bins, and must be in absolute time.

Note: Absolute time format means a fully referenced time in any ANYTIM format, e.g. '3-mar-05 12:36:44'. If you supply an absolute time as a number, it is interpreted as seconds since 1-jan-1979 00:00 (and should be double precision).

For example, to set up 2-second time bins for the period 31-Oct-2010 01:11:56 to 31-Oct-2010 01:23:28,

o -> set, obs_time_interval = ['31-Oct-2010 01:11:56.000', '31-Oct-2010 01:23:28.000']
o -> set, sp_time_interval = 2.

The sp_data_unit and sp_data_struct control parameters specify how the getdata method returns the spectrum data.  The units of the data are specified by setting sp_data_unit to 'counts', 'rate', or 'flux' (default is 'counts'). Note that for rate, the units are per detector, i.e. counts sec^-1 detector^-1.

By default ,getdata returns an array dimensioned [nenergy,ntime].  If sp_data_struct is set to 1, then it returns an array of ntime structures containing the following tags

when the requested units are counts. The counts, ecounts tags become rate, erate for rate units, and flux, eflux for flux units.  For example, if you have 173 time bins and 897 energy bins,

The time bins (also in the data structure, d.ut, above) and energy bins can be retrieved by calling getaxis.  For example,

returns the midpoints of the time and energy bins.  Use /mean, /gmean, /width, /edges_2, or /edges_1 in the getaxis call to return the arithmetic mean, geometric mean, width, 2xn edges, or 1-D edges.

So, for example, to plot the lowest energy bin of the flux as a time profile:

or to plot the spectrum of the fifth time interval:

Livetime Counter

The livetime fraction for each spectrum time bin from the livetime counters for each of the 18 detector segments is available in an info parameter, livetime_ctr, e.g.

Livetime Used

However the livetime that is used to calculate the spectrum in rate or flux units includes the effect of data gaps, decimation, and any other mechanism that reduces the data counts.  This 'used' livetime is available when you call getdata and request structure output, e.g.

data.ltime is dimensioned nenergy x ntime just to  have the same dimensions as the counts and ecounts fields, but the values for each time bin are the same for all energies.  Also, note that the values are not available for separate detectors.

Since the corrections for decimation and data gaps (and other effects?) are handled by adjusting the livetime, if you view the data in count space, the corrections are not in effect.

Decimation Correction

Front and rear detector decimation correction can be controlled separately via the decimation_correct and rear_decimation_correct control parameters.  There are two info parameters you can examine for information about the decimation correction that was applied - decim_table and decim_warning.

As mentioned above the decimation correction is applied through changes in the livetime.

Attenuator Changes

Changes in attenuator state are not corrected for in the spectrum object.  There are two options for generating a plot without the jumps caused by attenuator state changes:

• Use the heuristic corrections in the Observing Summary Data
• Import the spectrum and SRM data into OSPEX and determine the best-fit model.

For more information, see the FAQ question on this subject here.

In order to perform spectral analysis, you must write a spectrum and response matrix (also called SRM or DRM) file from the spectrum object via the filewrite method.

To write the spectrum and full SRM files with auto-generated names, use this command:

The full list of keywords for the filewrite method are:

• buildsrm: 0/1 means don't / do write SRM file
• namedialog: 1 means provide widget for specifying names for output file(s)
• specfile: Name of spectrum FITS file
• srmfile: Name of SRM FITS file
• all_simplify: Specifies the type of SRM matrix to write
  • 0: Full calculation of diagonal, off diagonal terms
  • 1: Off diagonal terms are an approximation
  • 2: Diagonal terms only
  • 3: Diagonal terms only, and all = 1 (or zero if it's a normally off-diagonal matrix)

Unfortunately since information is combined when writing the files, these files can not be read back into the spectrum object.  They can be used as input to OSPEX.

To write separate detector files with native energy bins (preserves the highest fidelity of the detector resolution), use the hsi_spectrum_sep_det_files routine (see header for calling arguments) or use the button in the Spectrum GUI.

If the spectrum time interval crosses attenuator state changes, the SRM file that is written will include the response matrix for each attenuator state encountered (and OSPEX will use the correct one during spectral analysis).

The spectrum object has the option to produce semi-calibrated data, and to correct for pileup.  Neither of these options is very accurate and we recommend not using them.

If you enable the SP_SEMI_CALIBRATED option, the diagonal response is used to compute an approximation of the photon spectrum, however no correction for grid variation, pileup, or background is done.

The pileup correction used in the spectrum object (enabled by setting PILEUP_CORRECT) does not ???.  A better option is to disable the pileup correction in the spectrum object, but in further analysis in OSPEX, include the pileup_mod function component if you think there is pileup in the spectrum.  In OSPEX, the pileup correction is more reliable because it is done in the forward direction, finding the values of pileup parameters that best approximate the photon model.

• 432 bytes are required per Time/Energy bin.  Choose time resolution and energy binning with this constraint in mind.
• It is most efficient to process all energy bins needed for a given time range.
• To produce a spectrogram from 80 Mbyte of event data using a 1.7 GHz PC,  allow 100 seconds.