[CXC logo]
Skip to the navigation links
Last modified: 15 August 2012

URL: http://cxc.harvard.edu/iris/v1.1/releasenotes/index.html

Iris 1.1 Release Notes

The following updates to Iris functionality have been made since the 1.0 release.

Highlights

Version 1.1 summary list

o New integrated application framework - all components now run as a single, self-contained Iris Desktop

o SED Importer/SED Builder improvements:

  • Support for Photometry Catalogs
  • Support for Photometry Points
  • Several enhancements to User Interface

SED analysis improvements:

Support for custom models:

  • Templates
  • User defined tabular models
  • User defined python functions

Interoperability with SAMP enabled tools (e.g., TOPCAT and Data Discovery Tool).

New support for third party components installed as plugins.

This is experimental for Iris v1.1; please contact the VAO Helpdesk for assistance if you are interested in this feature.


Updates to Individual Iris Components

SED Builder
Fitting Tool and Custom Model Manager (Sherpa)
Iris Visualizer (Specview)
SEDLib I/O Library

SED Builder: Loading and Managing SED Data

New Main Window

- The new SED Builder main window keeps track of all the open SEDs

- It is now possible to create an SED as a clone of an existing SED.

- When an SED is broadcast to SAMP a warning message is shown in the case where there are no suitable SAMP clients that can receive the message.

- From the main window it is now possible to add a new photometry point to the SED by providing its values.

- It is now possible to change the Target information for all the segments in an SED by using the "Apply" button. Coordinates can be expressed manually or by resolving them using a name resolver.

- Target information can also be edited individually or for a group of segments by selected a segment or a group of segments and then clicking on Edit. If the segment was imported, Edit will allow to reconfigure the import.

Photometry Filter Browser

The SED Builder now contains a database of about 1700 photometry filters, sorted by Facility. The Photometry Filter Browser is available from the Tools->SED Builder menu. The Browser is also available in the new Photometry Catalog Importer, so that the user can select the photometry filter used to get a photometry point.

Photometry Catalog Importer

This importer allows to import points from photometry catalogs: this is a file where photometric information is arranged in column (one column per flux/magnitude) and each row corresponds to a different astronomical source. The importer allows to build configurations for an arbitrary number of photometry points and to select which sources to include in the SED.

Interoperability, SAMP I/O

Input: given that the Builder offers several options and that there are different SAMP messages that can carry SEDs or SED Segments (plain votables and fits table messages or specific SSA ones) and that each Segment might be a photometry catalog or a spectrum/SED, a SAMP Chooser window will be opened for each incoming SAMP message. The user can decide whether to ignore the message or to import the incoming table as a photometry catalog or a spectrum/SED.

Output: SEDs and Segments can be broadcast using a generic votable message that can be handled by most VO applications. According to the SAMP specifications, since each message can only contain one table, the SED is split into the single segments and sent to the SAMP Hub. Additional information would allow a SED-aware application to reconstruct the original SED.

Sherpa: Fitting SED Data and Loading Custom Models

Iris 1.1 ships with Sherpa 4.4. This is the first version of Sherpa that provides support for template models.

Iris 1.1 also includes a new Custom Model Manager. This is a new Iris desktop component, that allows the user to define user models at runtime, and add them to Iris for modeling and fitting. User models can be table or template models read from file, or Python functions imported into Sherpa. The Custom Model Manager provides a new GUI allowing users to define table, template and user models, and to provide information on model parameters for each new model.

sherpa-samp

Communication between Iris and Sherpa is managed via Simple Application Messaging Protocol (SAMP). The sherpa-samp Python module, built to provide this SAMP interface to Sherpa, provides access to the Sherpa interface using a collection of MType subscriptions that map to Sherpa commands. In Iris 1.0, this package included a set of SAMP MTypes designed to package together SED data, model definitions, parameter starting values and ranges, and selection of Sherpa optimization function and fit statistic.

In these notes, we describe the modifications made to the Sherpa SAMP MTypes to accommodate table, template and user models in release of Iris 1.1:

       spectrum.fit.calc.flux.value

       spectrum.fit.calc.model.values

       spectrum.fit.calc.statistic.value

       spectrum.fit.calc.statistic.values
 
       spectrum.fit.confidence

       spectrum.fit.fit
    

In each MType listed above, there is a new attribute, "usermodels", that lists information concerning the new user model to be loaded into Sherpa. The usermodels attribute is a list. Each entry in the list is a map or dictionary, that contains the name of a model, the file from which it is loaded, and (for user models) the name of the user function. For example,

  usermodels = [ { 'name' : 'tablemodel.c1',
            'file' : '/home/jdoe/table.dat',
  'function' : '' },

{ 'name' : 'templatemodel.c2',
            'file' : '/home/jdoe/template-toc.txt',
  'function' : ''  },

{ 'name' : 'usermodel.c3',
            'file' : '/home/jdoe/myfunction.py',
  'function' : 'myfunction' } ]
 
    

In this example, the "usermodels" attribute lists three user models. Each entry has a name, where the name follows the Sherpa rule of containing type of model and the name of an instance of the model, separated by a period.

For example, the first model is a table model, so its type is "tablemodel". The name Iris attaches to it is "c1". When Sherpa receives this information in an MType, Sherpa will create its own copy of a table model, and label it "c1" in the Sherpa session.

The table model data will be read in from the file named under the "file" entry in the dictionary--in this example, /home/jdoe/table.dat. (The "function" attribute can be left as an empty string, since user defined functions are not added to table models.)

The template and user models are treated similarly--Sherpa models are created and named as indicated in the "name" entries of these dictionaries. When a template is read in, the file is treated as a "table-of-contents" file, that lists the locations of all the templates to be read in. (The "function" attribute can be left as an empty string, since user defined functions are not added to table models.)

When a user model is read in, the file entry is the Python file that needs to be imported into Sherpa. Within that Python file, there must be a function defined as:


  def myfunction(p, x):
      <Python Code>
      return y

    

Here, the arguments of the function are a NumPy array p of parameter values, and a NumPy array x of x-values (i.e., the spectral coordinate of the SED--for these models, the user function should assume Angstroms as the unit of the x-axis). The return value is a NumPy array y, of calculated fluxes, and the array y should be the same length as the array x.

The name of the function defined in the Python file must match the name given to the "function" attribute in the Sherpa MType.

Since receipt of each MType results in the start of an entirely new Sherpa session, the user model information must be sent each time, via the "usermodels" attribute, so that the new models are created for each new Sherpa session.

Finally, if there are no table, template or user models to be created in Sherpa, then the "usermodels" attribute should be set to be an empty list:

  usermodels = []
      

The names, initial values, ranges and freeze flags for parameters are contained in the "models" attribute of these MTypes, just as in Iris 1.0. In this version of sherpa_samp, the "usermodels" attribute is processed first. Table, template and user models are created as needed. Then, when the "model" attribute is later processed, the model parameters are found, and are attached to the appropriate table, template or user model in the Sherpa session.

Custom Model Manager

The Iris 1.1 desktop provides a new component, the Custom Model Manager. This component provides a GUI that allows users to define table, template or user models. The Iris Fit Manager then becomes aware of the definitions of these new models, and can send Sherpa instructions (via the Sherpa SAMP MTypes listed above) to create these new models and include them in fits.

The GUI provides the following options:

- There are radio buttons to set the new model as either a table, template or user model.

- There is a text field where the user can type the name of the file from which the table, template or user model is loaded. The path to the file can be a fully qualified path, or can be relative to the current working directory. The user may also click "Browse" to launch a file browser and select the file to be loaded.

- There is another text field to enter a name or ID to be attached to the model.

- For user models, there is a text field to enter the name of the user Python function, as described above.

- Finally, there are several fields to allow the user to define model parameters: name, values, mins, maxs, and frozen. The "name" field allows the user to type in a comma-delimited list of strings, that are the names of the model parameters. The "values", "mins", and "maxs" fields are comma-delimited lists of floating point numbers, defining initial values, minima and maxima respectively. The "frozen" field is a comma-delimited list of boolean values, indicating whether the parameter is thawed or frozen during a fit.

See the Iris Bugs & Caveats page for known issues with Sherpa functionality in Iris v1.1.

Iris Visualizer: Displaying and Manipulating Data

- The Visualizer was fully integrated into the desktop environment.

- Improved metadata browser: individual data points can be selected and visualized interactively, and assembled into new SEDs. Selections can be performed either on metadata table rows, or based on which data points are currently showing up through the Visualizer's viewport.

- Metadata table supports hierarchical sorting of table columns, via the use of mouse clicks on the column headers. The mouse can be clicked with the Ctrl key down, in which case the sort state of previously sorted columns is preserved. This hierarchical sorting can be used as a simple device to select data points based on Boolean conditions.

- The Model Manager can handle user-defined spectral components using the same window previously available to handle pre-canned spectral components.

- Support for the ASDC file format was added.

- There is now a separate preferences file for Iris, allowing the use of both applications, Iris and Specview, on the same computer, without they interfering with each other.

- The cross hair cursor was shut down due to incompatibilities in between the JDesktopPane now used as a container for all Iris' GUI elements, and Java2D (plotting package).

See the Iris Bugs & Caveats page for known issues with the Iris Visualizer in v1.1.

SEDLib I/O Library: Creating and Manipulating SED Data

- Fix FITS serialization problem with NaN valued kerywords (JIRA:BR-77). Keyword is now written according to FITS-3.0 standard, Sec. 4.2.1 for an undefined keyword. This form has indeterminate data type, so is approprate for Double type values.

- Fix VOTable load problem when a segment with 1 Point is serialized entirely as PARAM elements. Correctly allocates Points rather than throw NULL pointer Exception.

- Fix VOTable load problem for NaN valued parameters. Now retains NaN value, rather than interpreting as NULL.

- VOTableMapper updated to properly handle utypes providing Axis attribute information for Unit and UCD (Utype = Data.*Axis.Unit/UCD )

- Segment.getSpectralAxisUnit(), getFluxAxisUnit() updated to obtain the default value from Characterization if they are not defined in Data.

- DoubleParam.getCastValue() now returns NaN when string representation is an empty, but not-null, string.

- RangeParam.equals() updated to correct small bug in equality check.

- ArrayOfPoint.setDataAttribute() new method to assign Unit/Ucd info to Points from an independent parameter. (eg. Data.FluxAxis.Unit)

- General code cleanup:

* a little consolidation with checking Segment Type
* removed return statements from 'void' methods
* style mods for brackets and methods
* added 'equals()' method
* use "" rather than new String()
* some consolidation of conditionals

- Enhanced testing for Param type classes.


Last modified: 15 August 2012
[CXC logo] [Smithsonian Institute]
[VAO] [NED] [STScI]
[NSF] [NASA] AUI AURA
Copyright 2011-2014 VAO, LCC
Copyright 2015 Smithsonian Astrophysical Observatory