This document gives an overview of object-specific features of the sofwtare. This guide does not describe the command-line user interface, which is described in the Overview of the HESSI Command Line Interface. Prior using this software you must have installed IDL 5.3 (or higher) and the solarsoft tree with the HESSI branch of the tree (see the installation instructions).
As shown in the Overview of the HESSI Command Line Interface, objects (and object references can be used to generate HESSI images. For instance, the image generated from the default simulation settings, can be generated as follows:
IDL> obj = HSI_Image()
IDL> im = obj->GetData( )
obj is the object reference used to access the image stored in the object of class hsi_image As explained in other documents, the following other methods (i.e. procedures or functions associated with an object):
IDL> param = obj->Get() IDL> obj->Plot IDL> obj->Print IDL> obj->Set, KEYWORD=value
where KEYWORD is the name of a HESSI parameter and value is the value to assign to this parameter.
(See the Overview for details.)
The image object reference gives access to images and associated functions, but this is only the top of the iceberg. To generate an image, the sofware is going through a number of data transformations that include reading telemetry packets from a file, unpacking the observed data, binning them in time and energy, calibrating them, processing modulation patterns, back-projecting the observed data with the modulation patterns, cleaning the back-projection map with a specific image algorithm, and finally passing it to the image object.
Each step of this chain of data transformation is assoiated with an object. There is an object for reading data from files, for creating event lists (which are the unpacked data), for binning them, for calibrating them. There is an object for modulation patterns, an object for cleaning images, as there is an object for holding the final image. An object at a specific step of the image generation gets the data it needs to process from a source object, which is the object associated with the previous step in the reconstruction. This object again gets its source data from the previous object in the chain. The software sctructure is represented in a chart that shows the name (or class name) of each object, and their relationships.
A HESSI object can therefore be considered as an instance of a general, abstract object, called framework. The framework provides each object in the reconstruction process with function to transform a source data into the data type associeted with the object. Therefore, each object is reusing the sam function to get the data, to set control parameters and to process data. What change are the "semantics" of the framework, that is, the primary data type the framework deals with, the control and information parameters (see below) associated with that data type, and, of course, the transormation algorithm.
The object obj allows to access any data from the chain described in the secion above. Therefore, once you've created an image, you can check any intermediate data that has been used to generate a given image. Here is how to do it:
IDL> data = obj->GetData( CLASS_NAME = 'hsi_foo' )
This returs the data associated with the object hsi_foo in the "chain".
A simple "dirty" image (before any image processing is applied) is generated by summing the back projections associated with each collimator selected. The back projections are generated by multiplying the modulation patterns with the observed count rates for a given time binning in a given time range. If you want to plot the back projection maps used to generate the image associated with obj, you do:
IDL>!p.multi = [0,3,3]
IDL>obj->Set, DET_INDEX_MASK=bytarr(9)+1B ; selects all detectors
IDL> FOR i=0,8 DO Plot_Image, obj->GetData( CLASS_NAME='hsi_bproj', THIS_DET=i )
You can compute the modulation profiles associated with the modulation patterns for an arbitrary input image, for instance:
IDL>image_dim = obj->Get( /IMAGE_DIM )
IDL>vimage = FltArr( image_dim[0], image_dim[1] )
IDL>vimage[25, 45] = 1
IDL>!p.multi = [0,3,3]
IDL>modprof = obj->GetData( CLASS_NAME = 'HSI_MODUL_PROFILE',
VIMAGE=vimage, THIS_DET_INDEX=5 )
IDL>for i = 0, 9 do plot, *modprof[i,0], xs=3
will return the modulation profile associated with an arbitrary image (vimage) which has the same dimension as the actual (observed) backprojection image. The variable modprof is an array of 9x3 pointers. There is one pointer for each detector (9 total) and one pointer for each harmonic (3). Pointers allow to accomodate structure with variable-length arrays. A pointer is like an ordinary variable, except that its contents must be dereferenced to be used, with the star * operator, as shown above.
The calibrated event list contains the count rate and grid calibration required to reconstruct an image for a given UT time, time range, energy band. It is retrieved in the following manner, for instance:
IDL>cbe = obj->GetData( CLASS_NAME ='HSI_CALIB_EVENTLIST', THIS_DET_INDEX=4 )
In the calibrated event list, you have many calibration parameters associated with the observation, one important being the fine spacecraft pointing called aspect solution. You can plot this information:IDL>plot, cbe.dx, cbe.dy, xs=3, ys=3
IDL>evenlist = obj->GetData( CLASS_NAME='hsi_eventlist' )
IDL>help, eventlist, /str
and you will get an array of structures of type {hsi_event} which contains the time-tagged photons associated with the image.
Control, information, or administration parameters can be retrieved for each class individually. For instance,
IDL> control_param = obj->Get( CLASS_NAME = 'hsi_eventlist', /CONTROL_ONLY, /THIS_CLASS_ONLY )
gets the control parameters for the eventlist class only. Ommitting the THIS_CLASS_ONLY would return all control parameters of the eventlist class and all control parameters of all source classes under hsi_eventlist in the chain.
Note that altough control parameters are associated with a specific class they can be set at all levels directly, i.e. it is unecessary to give the class name while retrieving the parameters by giving their names as keywords.
A. Csillaghy