Spectroscopic Analysis in the Virtual Observatory Environment with SPLAT-VO

# Spectroscopic Analysis in the Virtual Observatory Environment with SPLAT-VO

Petr Škoda Peter W. Draper Margarida Castro Neves David Andrešič Tim Jenness Astronomical Institute of the Academy of Sciences,Fričova 298, 251 65, Ondřejov, Czech Republic Department of Physics, Institute for Computational Cosmology, University of Durham, South Road, Durham DH1 3LE, UK Universität Heidelberg, Astronomisches Rechen-Institut, Mönchhofstraße 12–14, 69120 Heidelberg, Germany Department of Computer Science, Faculty of Electrical Engineering and Computer Science, VŠB — Technical University of Ostrava
17. listopadu 15, 708 33 Ostrava-Poruba, Czech Republic
Department of Astronomy, Cornell University, Ithaca, NY 14853, USA
###### Abstract

SPLAT-VO is a powerful graphical tool for displaying, comparing, modifying and analyzing astronomical spectra, as well as searching and retrieving spectra from services around the world using Virtual Observatory (VO) protocols and services. The development of SPLAT-VO started in 1999, as part of the Starlink StarJava initiative, sometime before that of the VO, so initial support for the VO was necessarily added once VO standards and services became available. Further developments were supported by the Joint Astronomy Centre, Hawaii until 2009. Since end of 2011 development of SPLAT-VO has been continued by the German Astrophysical Virtual Observatory, and the Astronomical Institute of the Academy of Sciences of the Czech Republic. From this time several new features have been added, including support for the latest VO protocols, along with new visualization and spectra storing capabilities. This paper presents the history of SPLAT-VO, it’s capabilities, recent additions and future plans, as well as a discussion on the motivations and lessons learned up to now.

###### keywords:
Spectral Analysis, Virtual Observatory, VO, SPLAT-VO, StarJava
journal: Astronomy & Computing

## 1 Introduction

There are many tools for the analysis of astronomical spectra. The most commonly used of these are the various packages of MIDAS (Warmels, 1992, ascl:1302.017), IRAF (Fitzpatrick, 2012, ascl:9911.002), and Starlink (Disney and Wallace, 1982, ascl:1110.012), together with scripts written in Python (e.g., Astropy Collaboration, 2013) and IDL (e.g., Landsman, 1993). Very advanced processing is still often done in custom (especially FORTRAN) programs used by small communities. These tools tend to work with specially formatted files (quite often ASCII tables) stored on local disks.

The common tasks for astronomers during spectral analysis consist of finding the required spectra in various archives, downloading them, understanding and extracting metadata (such as date of exposure, spectral range, and flux units), converting to the custom format used by the particular tool, visualizing selected spectra and removing the bad ones (for example if they are noisy or have excessive numbers of spikes). They can finally run some massive processing or analysis on an improved list. Very often the measurement of some parameter, such as the radial velocity or equivalent widths of selected lines, is accomplished interactively and the spectra must be adjusted by zooming, panning and scaling.

A real scientific analysis of thousands of spectra is a very tedious task even from the same instrument, but the real modern challenge is an analysis of multi-wavelength spectra from different instruments, where all the metadata are different, there are various flux and wavelength, frequency or energy units and where the formats of storage also vary (including simple FITS, binary tables, and ASCII lists).

Making the handling of spectra obtained from world-wide distributed heterogeneous archives simple and efficient was the main motivation for developing the International Virtual Observatory Alliance Simple Spectral Access Protocol (IVOA SSAP; Tody et al., 2012). The key elements of this HTTP-based protocol are a standard spectral server discovery mechanism (a Google for astronomical data) called IVOA Registry (Benson et al., 2009) and the standard VOTable data format (Ochsenbein et al., 2004), that is used to describe the metadata of discovered spectra in a limited vocabulary of obligatory parameters.

### 1.1 The SSA protocol

SSAP allows astronomers to find all the world-wide VO-compatible archival spectra of their favourite objects, and it can also be used to get spectra for all the objects in a ‘circular’ region of interest on the sky. These simple queries can be refined using spectral ranges, dates of observation as well as more subtle criteria like spectral resolution or target class (even spectral type) if the server supports corresponding optional parameters. More capable servers provide extended facilities for converting spectra on-the-fly to the required format, and can create previews of spectra in PNG or deliver the fluxes and wavelengths in ASCII or CSV tables.

### 1.2 SSAP-compatible visualization clients

Although processing large amounts of data is more convenient when using SSAP from a scripting language for batch processing, a crucial part of understanding data is only gained by using advanced visualization and interactive exploration. Therefore, a very important part of the VO infrastructure is represented by VO-compatible spectra visualization clients. There are currently several tools for interactively manipulating spectra in the VO.

VOSpec (Osuna et al., 2005, ascl:1205.011), developed by ESA, is designed strictly on principles of IVOA standards and was rather focused on the analysis of high energy and space-based spectra with absolute flux calibration, lacking support for some common functions and custom data formats used in ground-based stellar spectroscopy. The most critical 1D FITS image format was added just recently. VOSpec contains quite complex non-linear model-fitting package and can handle photometric points as well as Spectral Energy Distributions (SEDs).

The other clients were developed as general spectral analysis tools prior to the conception of the VO, and have subsequently been extended to add support for querying and downloading spectra using SSAP. The advantage of this approach is the support for many legacy data formats and various domain-specific functionality, better tuned to requirements of scientists not familiar with VO technology.

Specview (Busko, 2002, ascl:1210.016), developed at STScI, was intended mainly for handling spectra from Hubble Space Telescope instrumentation and some other NASA missions, but gradually transformed into a VO-compatible general client supplemented with a library of theoretical spectra and various models for SED generation. While Specview is a very powerful tool compatible with a lot of very special formats from HST, IUE, FUSE, ISO and GALEX satellites, allowing for the advanced comparison of observations with a wide range of theoretical spectral models (such as power laws, Bremsstrahlung, emission line profiles, interstellar extinction, dusty rings or whole Kurucz library of spectral types), it is less flexible in the support of various SSAP features and is falling behind the rapid evolution in IVOA standards.

Because of its powerful spectral model handling Specview was selected as a core module for the visualization of spectra and SEDs in the VAO Spectral Energy Distribution Analysis Tool Iris (Laurino et al., 2014, ascl:1205.007).

The specific domain of CASSIS (Caux et al., 2011, ascl:1402.013) is the visualization and analysis of sub-millimetre spectra (with special emphasis on data from the Herschel Space Observatory as a plugin for its HIPE pipeline (Balm, 2012, ascl:1111.001)) using various databases of atomic and molecular transitions and several physical models of the interstellar environment. In order to be able to directly use spectra from VO resources, an SSAP interface was added recently.

The final VO-compatible client for spectra analysis and the main subject of this article is SPLAT-VO (Draper et al., 2013, ascl:1402.008). SPLAT-VO despite its early origin was revived recently and is currently under intensive development, serving as a test-bed for newly proposed VO standards and special features.

## 2 History of SPLAT-VO

### 2.1 Splat

The SPLAT-VO project is an extension to an older one simply called SPLAT (Bly et al., 2002, ascl:1402.007). The name SPLAT is based on the words SPectraL Analysis Tool, an application for the display and analysis of spectral data. The development of SPLAT itself was started by the Starlink Project (Disney and Wallace, 1982) in 1999 in response to a perceived need within the UK astronomy community for a spectral domain tool with capabilities similar to those of the successful GAIA tool (Draper, 2000, ascl:1403.024) that supported imaging data. SPLAT was also a leader project for moving future developments into the Java language, with the obvious benefits of improved portability, modern language capabilities (OOD, OOP) and core-level support for features like UIs and Internet protocols and services. This work eventually led to the formation of what became the StarJava project, containing also the well-known table processor TOPCAT (Taylor, 2005, ascl:1101.010).

### 2.2 Splat-Vo

The first VO capabilities added to SPLAT where released in 2005 (Draper et al., 2005), as support for querying VO registries for Simple Spectral Access Protocol servers was added. A selection of these servers could then be queried for any spectra they contained within a region on the sky and these could then be selected and displayed. SPLAT already had the ability to match a wide range of spectral coordinate systems and flux units, so the spectra could be displayed within the same plots for direct comparison. Since then SSAP support has been increased to support version 1 of the standard and various enhancements like being able to query for the SSAP TARGETNAME, not just a region, have been added.

The second phase of VO developments in SPLAT-VO were the incorporation into the VO-Desktop (Walton and AstroGrid Consortium, 2008), so that spectra and tables could be shared between applications. Initially, in 2006, this used the PLASTIC (Taylor et al., 2007) protocol and then, more recently, SAMP (Taylor et al., 2012).

In 2011 the development of SPLAT-VO was resumed by the German Astrophysical Virtual Observatory (GAVO) in Heidelberg, Germany and in the Astronomical Institute of the Academy of Sciences of the Czech Republic (AI ASCR). Because of the requirement for a spectral domain application with VO capabilities and good scientific analysis functions, GAVO decided to actively support developments now that SPLAT-VO was only being supported by unfunded best efforts, concentrating on an improved VO interface, benefitting from the in-house development of the VO server suite DaCHS. Around the same time requirements for some modifications of scientific functions (with emphasis on optical stellar spectroscopy) identified during the everyday analysis of spectra of emission line stars in the Stellar department of AI ASCR, resulted in Bachelor and successive Diploma theses focused on the implementation of new analytical and visualization functions in collaboration with VŠB—Technical University of Ostrava.

In this way SPLAT-VO can continue to be improved, and kept up-to-date with the changing requirements of both end users and data providers.

## 3 SPLAT-VO internals

### 3.1 Data formats

The SPLAT-VO spectral data model is specified by a single internal interface that is concretely implemented for the various data formats that are supported. Having a single interface decouples the data model and makes it practical to support a wide range of formats, but necessarily means that some format specific features will not be supported and can be lost when making transformative changes like saving back to file.

The SPLAT-VO data model is simple only requiring that spectra have a name, coordinate system and some data values. Other supported items are data errors, fuller descriptions, keyed properties (key, value, description), data units and labels, and the underlying dimensionality (if the spectrum is being extracted from a 2D or 3D array). Spectra can also have mutable properties, like the names of the table columns that contain the various data values.

Current implementations give SPLAT-VO access to spectra in simple text files, FITS (Pence et al., 2010), NDF (Jenness et al., 2014a), NDX (Giaretta et al., 2003), as well as FITS and VO tables. Tables are supported using the STILTS (Taylor, 2006, ascl:1105.001) library. In addition to these spectra can also be memory based so that they can become modifiable and be derived from data with higher dimensionalities.

### 3.2 Internal spectra handling

The presentation of all data types through a single interface works especially well when coupled with a further, higher-level, abstraction class. This abstraction is in effect how all the analysis and visualization code throughout SPLAT-VO see a ‘spectrum’ (these two elements that decouple an abstraction from the underlying implementations are in fact the well established ‘Bridge Pattern’).

This use of a single abstraction to all data formats makes it easier to write consistent code and extend the basic internal spectrum with new facilities (methods that do things like extraction sections, replace bad values etc.) as well as associate useful properties like graphics and formatting rendering hints, data and coordinate range limits. Extending the underlying model is also easy as new features strictly need only be handled in the abstraction (although clearly that would not be interesting) and new spectral types can extend the base abstraction (the basic spectral type is extended to also offer spectra that render as line identifiers and cached copies of remote spectra).

### 3.3 Presentation

The presentation of spectra is based on the model-view-controller pattern that pervades Java UIs and the same spectral data can be seen and operated on in many different guises, that is as a number of line plots, tables, property lists etc. Memory based spectra are also directly modifiable (as simple edits to table cells or generally using expressions). Through the model-view-controller infrastructure all changes are propagated to all views.

### 3.4 Coordinate systems and units

Early in the design of SPLAT it was decided that it would not be possible to replicate the considerable effort that had already been put into a comprehensive system for handling coordinate systems and units, including full support for reading and writing FITS WCS (Greisen et al., 2006). This led to the development of a JNI library for the Starlink AST library (Warren-Smith and Berry, 1998; Berry and Jenness, 2012, ascl:1404.016), JNIAST. AST itself is written in standard C so compiling it on many platforms is relatively easy, but, as discussed in Sec. 7.1, this remains a portability issue at the heart of SPLAT limiting one of the initial aims.

Some of the advanced features that SPLAT-VO offers based on AST are support for spectral coordinates in wavelength, velocity, frequency and energy. These can have standards of rest, so transformations of rest frame are also supported (important for velocity and laboratory data). SPLAT-VO also supports double side-band spectra for sub-millimetre spectra and flux unit matching. Many of these features have been improved in AST over time and SPLAT-VO gains from this.

AST supports all the units specified in the FITS standard (Pence et al., 2010) and can calculate scaling factors to allow matching of spectra with different flux units. Adding full VOUnits support (Demleitner et al., 2014a) to SPLAT-VO would currently require that AST is updated to match the standard. This would have the added benefit of expanding support for VOUnits to the entire Starlink software collection and in particular enhance the unit support of the VO aspects of GAIA (Draper et al., 2009).

### 3.5 Scripting of SPLAT-VO

The various classes of SPLAT-VO may be called directly from the BeanShell scripting language (Niemeyer and Leuck, 2013), in principle this allows complex workflows to be created, and is used to create example scripts that are part of the standard distribution. These support the batch fitting of single Gaussian line profiles, as well as composite models consisting of any number of Gaussian, Lorentzian and Voigt profiles for deblending complex lines (a feature that has never made it into the full UI). BeanShell scripts are also used for controlling SPLAT-VO from command line.

### 3.6 The power of SAMP in SPLAT-VO

Although all SSAP clients have powerful capabilities, they are naturally limited to their built-in features, which will not suit all the requirements of a wide spectroscopic community. However, almost all VO-compatible tools, including the important table processor TOPCAT and stellar atlas Aladin (Ochsenbein et al., 2005, ascl:1112.019), have built-in support for the Simple Application Message Protocol (SAMP), successor of PLASTIC. This supports the bringing together of basic VO applications, like bricks, to build complex visualization and processing pipelines allowing very complicated analyses of truly Big Data. The astronomer may, for example, visualize the spectra of objects they click on in some imaging survey frame displayed in Aladin, or identify the visual appearance of galaxies from the spectra which have been visually selected in SPLAT-VO. SAMP has successfully been used to send messages from a web browser displaying previews of a number of spectra to SPLAT-VO where they were subsequently automatically downloaded and then analyzed.

## 4 SPLAT-VO capabilities for spectra analysis

SPLAT-VO as a general purpose spectral analysis tool supports a very wide range of capabilities required by astronomers for every-day work outside of the VO. Input spectra may be loaded directly from local disk files in a number of formats, including several types of multicolumn ASCII tables, multi-extension FITS with binary tables or 1D spectrum FITS image, as well as Starlink NDF.

The list of capabilities of SPLAT-VO is enormous and are fully described in the associated documentation (SUN/243; Draper et al., 2013) which is also available as online help and includes example data from multi-wavelength observations.

Here we give a short overview of features not relevant to VO protocols. Several features are very specific to the analysis of hot emission line stars.

• Visual stacking of spectra introducing either constant vertical offsets or offsets based on functions of values of certain FITS keywords. For example the line profiles may be ordered by the circular phase computed for a certain period. Stacking is also useful for visualization of evolution of stellar line profiles in variable stars. Fig. 1 shows the evolution of an emission line profile for the star  Per observed with the HEROS spectrograph (Šlechta and Škoda, 2002) at the Ondřejov 2m telescope during the years 2001–2003.

• Measurement of radial velocities by the visual matching of a line profile with its mirrored image based on idea of oscilloscopic comparators. This is important for measuring asymmetric and distorted line profiles typical for hot emission stars. For a detailed explanation see Parimucha and Škoda (2007). This feature can be operated with a batch-like mode to quickly process a number of lines and/or spectra using a visitor list.

• Continuum estimation using flexible curves similar to those expected to be drawn by a human. The INTEP procedure based on Hermite polynomials (Hill, 1982) has been successfully used for decades in fitting stellar continua (typically of emission-line stars such as Be stars and symbiotic novae) in the program SPEFO (Škoda, 1996). An overview of the advantages of this procedure is given in Škoda (2008). Other curves types are also available such as Akima (1970).

• Powerful transformation of the spectral axis with respect to various coordinate systems; air and vacuum wavelength, optical and radio velocities, frequency, redshift, energy. The transformations can also include various standards of rest; topocentric, heliocentric, dynamic and kinematic local.

• Built-in spreadsheet processor supported by special astronomical functions. Allows the modification/transformation of coordinates and data values. Astronomical functions include the spectral line profile models.

• Filtering with smoothing (mean, median, rebin) and denoising with wavelets.

• Line fitting using Gaussian, Voigt or Lorentz profiles.

• Statistics of selected regions, mean, median, sum, mode, variance, skew, kurtosis, rms, quantiles.

• Region removal, replacement and extraction. Also replacement of part of spectra with an interpolated curve.

• Comprehensive overlay graphics toolkit with annotations and many configurable options for the presentation of data. Export of publication quality output into PNG, GIF, and EPS formats.

• Animation of spectra - convenient for showing line evolution or non-radial pulsations.

• Identification of spectral lines using simple supplied ASCII line lists and built-in sets of common atomic and molecular lines (includes molecules in sub-millimetre region). Fig. 2 shows the identification of telluric lines on a combination of spectra of  Oph obtained with two different spectrographs of the Ondřejov 2m telescope.

• Simple operations on spectra such as addition, subtraction, division and continuum fitting.

## 5 SPLAT-VO SSAP interface

The SSAP interface in SPLAT-VO is clearly the most important tool for working with the VO and remains under active development. The task of the interface is to help the user construct a valid SSAP query by filling out a simple form of parameters, and then arrange for that query to be sent to a list of selected SSAP servers and finally make the query response available so that any spectra can be selected for download.

Queries can involve supplying the coordinates (POS) and size (SIZE) defining a ’circular’ region on the sky (a so called ‘cone search’), or just the name of an object and size, the name being resolved into a position by the CDS name resolver Sesame. Other form elements provide refinement of the query to include things like spectral ranges (BAND), the date and time of observation (TIME), status of the wavelength calibration (WAVECALIB), flux calibration (FLUXCALIB) and data format (FORMAT). In fact recent additions to SPLAT-VO now offer control of all the optional parameters supported by a selected SSAP server.

Once spectra have been selected they are downloaded from the SSAP server (using the URL accref returned in the SSAP response) they can be worked on in the same fashion as any locally available spectra and saved to local disk etc.

The list of SSAP servers may be updated using one of several VO registries. Local or development services not yet registered may be added manually. The server list may be edited so that the query is only sent to collections of servers with say similar data or can be restricted to only one service that may be queried for detailed specific operations.

The following example shows the absolutely calibrated spectra of the emission star  Per. We have selected the Hubble Space Telescope with the Goddard High Resolution Spectrograph and the IUE low resolution spectra. The composite plot of selected UV spectra is in Fig. 3.

### 5.1 Theoretical spectra access

In a similar way to observational spectra, synthetic spectra can also be obtained from libraries available in the VO (e.g., Kurucz models, Rauch’s non-LTE model spectra, TLUSTY hot stars, Salpeter, Dusty). They are selected by a radio button, which changes the role of parameters used in the query. The extended protocol called Theory-SSAP (hereafter TSAP; Tody et al., 2012) uses various physical parameters like , , metallicity etc. for queries instead of position, wavelength, region and date/time range. Unfortunately obligatory metadata do not exist for all required physical parameters, so it is necessary to just try out what is available on a given server. It is then necessary to individually select suitable spectra from a multidimensional table combining all the parameter ranges required. Fig. 4 and Fig. 5 show the query and result of selecting several Kurucz models for Vega.

### 6.1 Motivation

As the VO evolves, adding new protocols and data models, SPLAT-VO needs to evolve accordingly. SSAP, as the name says, is a simple protocol, and has some limitations. Some features like cut-outs or flux calibration, which are often needed, have to be performed in a second work step after downloading the spectra. It is much more efficient to have it done on-the-fly at the server and to download the spectra exactly as needed. To overcome the limitations of SSAP, the new DataLink protocol (Dowler et al., 2014) was used. SPLAT-VO is one of the first client implementations of DataLink, in this way also contributing to its testing and development from a client point of view.

Besides SSAP, spectra can also be retrieved using the ObsCore data model through Table Access Protocol (known as ObsTap; Louys et al., 2011). Its implementation in SPLAT-VO allows spectra to be retrieved also from ObsCore services, and the ObsTap ADQL (Ortiz et al., 2008) search offers a more powerful search mechanism as well. The implementation of new VO protocols like ObsTap and DataLink have been done side-by-side with their server-side implementation in DaCHS (Data Center Helper Suite; Demleitner, 2014).

SPLAT-VO’s user interface has been improved. An improved server selection interface and SSAP search by metadata parameters are some of the new features added, which are listed in the next subsections.

### 6.2 New features in VO access

#### 6.2.1 SSAP service selection

In the earlier versions of SPLAT-VO a list of services was presented, and the user could select the services to be queried, as well as remove uninteresting services from the list. Information about the services of interest had to be retrieved from somewhere else, as the service metadata was not used. This simple server selection interface has been improved by a more detailed selection, users can choose a set of services that may contain data of interest, based on the service’s metadata taken from the registry (data source, wave-band).

There are two ways of selecting services. The first way is to choose according to the data source (such as a survey, pointed observation, or simulation) or wave-band. For example, the user wants to select services containing pointed observation sources in optical wavelength, so this can be selected in the interface and only the services which contain this information in the metadata will be selected. The other way is useful in the case when users know exactly the services they want to query, so they may create an own tag containing the chosen services, and give it a name, such as “My Favourite Services”, which will be saved and loaded the next time SPLAT-VO starts.

This implementation relies on the metadata information from the registry services, which should be correct and complete. Unfortunately many services information from the registries are not complete, or not correct, what we hope will be fixed in the future.

#### 6.2.2 Manual addition of SSAP services

SPLAT-VO gets its list of SSAP services by querying a registry service. A new function has been added to allow inclusion of a new service that is not (yet) registered. This is useful to access a local, not public service, or to test a service before it’s included in the registry.

In early versions, SPLAT-VO contained just a simple cone search using the SSAP obligatory parameters (RA, DEC, band, time, data format) and later added wavelength and flux calibration state, although much other metadata is available on servers. Now SPLAT-VO also retrieves the metadata parameters for each server, and a new user interface allows users to chose metadata parameters and their values to perform more detailed queries. This is especially interesting when querying theoretical spectra by TSAP, which contain many additional query parameters. Figure 4 shows the use of additional metadata parameters.

#### 6.2.4 Simple HTTP authentication

Simple HTTP authentication can be used to restrict access to data when it is published to the VO before it should be publicly available, so the owner and a limited group of users can access it before disclosure. The authentication can be done on a service basis, where the whole service needs authentication to be queried, or on a spectrum basis, where only some of the spectra from a certain service require authentication to be downloaded. In any case, an username/password window will appear when needed.

To overcome SSAP limitations and allow server-side processing of spectra like cut-outs, or format conversions, a protocol called getData (Demleitner and Škoda, 2012) has been developed. After successful implementation and testing on SPLAT-VO, the work on getData has been stopped. It has been decided to implement these features using the newer DataLink protocol, which will probably be made available on several services in the near future, and can also be used in different cases. DataLink resources can provide links with several different ways to access the data, covering getData functionality and more. When parsing the service response from an SSAP query, which is in form of a VOTable, SPLAT-VO looks for a RESOURCE element of type service. An example is shown below:



The publisher DID of the dataset of interest

Recalibrate the spectrum.  Right now, the only
recalibration supported is max(flux)=1  (’RELATIVE’).

Spectral cutout interval, lower limit

Spectral cutout interval, upper limit

http://dc.zah.uni-heidelberg.de/flashheros/q/sdl/dlget"/>



The GROUP element with name input contains the input parameters that will be returned to the server. It must contain an ID parameter, which refers to the metadata that identifying the required spectra (normally the pubDID parameter). The other parameters in this group are the ones for which the users can set values that will be sent to the service as a request. The accessURL parameter defines the service URL to which this request has to be sent.

In the SSAP response to a query, the services supporting DataLink will be marked with the “✂” icon. When one of these services is selected, the user can activate the DataLink feature by clicking on the button with same name. When activated, a window with a form to enter values to the DataLink parameters will appear. While this window is activated, every spectrum selected and downloaded from this service will be processed according to the chosen parameters. When de-selected, the spectra will be downloaded as they are in the SSAP service, without processing.

In the case described above, the DataLink resource is in the query response from the SSAP service. In another case, after a query, some services return a list of spectra pointing not to the spectral data to be retrieved, but to a VOTable containing only DataLink information with the links to the URLs of the data. This DataLink resource has then to be parsed by SPLAT-VO in order to retrieve the selected spectrum.

#### 6.2.6 ObsTAP

In addition to SSAP, spectra can be retrieved using ObsTap. This service uses the Table Access Protocol (TAP) to query metadata from the Observation Data Model Core Components (ObsCore). Currently there are few services implementing it, and the SPLAT-VO implementation is ongoing. ObsCore provide standard metadata attributes that can be used, through the ADQL query language, to perform more extensive and detailed queries than in the case of SSAP data discovery.

In the current SPLAT-VO implementation, users can select ObsCore in the main SPLAT-VO window. The ObsCore browser window will appear, which is in part similar to the SSAP browser window. The user can chose either a similar cone search interface like the one in SSAP, or a simple ADQL interface where some parameters can be set. For more advanced queries, the user can directly edit the ADQL expression. After sending the query the results tables will be displayed, which are in functionality similar to the SSAP browser window.

#### 6.2.7 Visualizing light curves using SSAP

As a proper standard for displaying photometric light curves or time series of other variables is not available from the IVOA, there have been several attempts to exploit the visual similarity of spectra and light curves pretending the spectral axis is the temporal one. So the SSAP was successfully used as a transport protocol for delivering light curves in binary table format. In principle the table may contain many columns displayed as dependent variable against the various time axes with interactive menu. The current limitation only requires the time axis expressed as floating point variables, which limits the possibility of using strings e.g., dates, time stamps or even the names of CCD images used to extract given photometric point on light curve. An example in Fig. 6 shows the light curves obtained from the Ondřejov Southern Photometry Survey (Škoda et al., 2014) ongoing at the Danish 1.5m telescope DK154.

### 6.3 New features in spectral analysis

To improve the analytic capabilities and general usability the following features were added to the non-VO capabilities of SPLAT-VO (Andrešič, 2013):

#### 6.3.1 Saving spectra stack in multi-extension FITS format

Previous versions of SPLAT-VO were able to save the global list of spectra to a binary format, which was in fact a dump of the native serialization of spectra objects. Sometimes, there may be a need to save that list to a more universal, standardized format. For example, SPLAT-VO has many operations on spectra, which result in a new spectrum that is added to a global list of spectra (e.g., cutting a part of spectrum). Saving the list of such spectra to a standardized format would allow their use in other tools offering capabilities that SPLAT-VO does not support. This may be helpful for the preparation of large lists of normalized line profiles for Fourier disentangling or asteroseismology studies.

SPLAT-VO now allows the user to save the global list of spectra to a much more universal FITS format, where every spectrum is represented by its own (IMAGE) extension. The only disadvantage compared to the native dump format is that settings related to the way that the spectra are rendered are no longer available as there is no standard for metadata of presentation styles and graphics attributes.

#### 6.3.2 Visual spectrum selection and highlighting

In earlier versions of SPLAT-VO, when working with multiple spectra displayed in one common plot, it was difficult to work out which spectrum corresponded to one in the global list, so that it could be worked on independently. Also the selection of, for example, a noisy spectrum and its removal from the plot window could be done only by a trial-and-error procedure and therefore was quite problematic and time-wasting.

This has been improved and now when a spectrum is selected in the global list, SPLAT-VO will highlight it in all the plot windows that it is displayed in. The highlighting has the form of a few-seconds blinking in an inverted colour and is performed sequentially (highlighting in one plot window comes after the previous one is finished), which gives to the user a perfect sequential overview of the spectrum’s plots.

#### 6.3.3 Cut window: saving the ranges

In the cut regions tool, it is possible to read the ranges of regions from a local text file. But what if a visual selection of ranges from a currently plotted spectrum is to be saved? SPLAT-VO can now save the currently defined ranges to a local file in the same format as used for reading.

#### 6.3.4 Cut window: working with multiple spectra

Previously any regions defined by the cut regions tool only operated on one spectrum (known as the current spectrum). This tool now has a table of all currently plotted spectra which can now be selected so that any region operations are applied to them all.

#### 6.3.5 Display of spectra received by SAMP in one window

In previous versions of SPLAT-VO, all spectra received via SAMP messages were opened in their own plot windows. Since it would be useful to also display spectra in one plot to make comparisons, a new control to toggle this behaviour on and off has been added.

## 7 Lessons learned

During the development of SPLAT-VO a number of lessons have been learned that may affect future developments of similar tools. In this section we summarize these issues.

### 7.1 Using JNI versus “pure” Java

The question should probably be asked if using a JNI wrapper to the AST library was a good choice or not. As with most things, we believe this was a good idea and also bad. The judgement of how bad depends on how the ultimate cost benefit analysis works in the longer term, but either way it is difficult to deny that a pure Java solution would have been preferable.

The positives of this choice are that it made the development of SPLAT-VO possible on useful time-scales as we were able to immediately benefit from all the work that had gone into the AST library, as AST is very much more than just a system for handling coordinates and units. It also insulates against the often messy need to parse FITS headers and offers the ability to transform easily between all compatible coordinates and units. Even today some 15 years later, AST is still believed to be a class leader in these areas.

Avoiding this work was also pragmatic as a re-write into Java would have been a lot of work that the effort just wasn’t available for and still isn’t. In the intervening years there have also been new features added to AST, such as the dual-sideband support, which was vital for sub-millimetre work, and the adoption of SPLAT by the Joint Astronomy Centre (JAC). The development of SPLAT has also been a useful testing ground for the development of AST itself (like the introduction of thread safety, so not just the handling of spectral coordinates), closing a virtuous circle.

The downsides are only the obvious ones, not having a pure Java solution compromises the portability, so we need to make an additional effort for all the supported platforms. There is also the non-trivial time writing the JNI layer itself takes. Writing JNI interface code is more challenging than those more commonly found for scripting languages.

### 7.2 Open sourcing from the beginning

The decision was made very early on for the SPLAT source code to be made publicly available, first via CVS on a Starlink server, then via Subversion on a Joint Astronomy Centre server and finally using Git on Github. We feel that this openness contributed directly to the software being picked up by the GAVO project, saving the application from stagnation once the direct funding for it was dropped.

### 7.3 Local spectral line catalogues are not sufficient

Currently SPLAT-VO uses a local text file containing molecular transitions that are thought to be of interest and allows the user to provide external lines via a text file of a similar format. The internal list is dominated by sub-millimetre lines required by the JCMT. Even so, the list of lines was never sufficient and astronomers continue to ask for more obscure transitions to be included. A local line catalogue is an excellent back up but it is also necessary to look up catalogues from remote services. The ALMA-OT (Williams and Bridger, 2013) works in exactly this way with much success. This feature will be added in the future using the Simple Line Access Protocol (SLAP) that will allow for retrieval of line lists from big world-wide atomic and molecular database such as NIST (Kramida et al., 2013, 2012; Lovas, 2004), Splatalogue (Remijan, 2010), and all the databases from the VAMDC consortium (Kupka et al., 2011).

### 7.4 Calling user interfaces from pipelines requires forethought

Interactive user interfaces are very powerful but a number of issues become apparent when reduction and analysis facilities are directly integrated into an application where automation is a secondary concern. At the James Clerk Maxwell Telescope SPLAT replaced the SPECX package (Padman, 1993, ascl:1310.008) which had been developed for interactive command-line use whilst supporting a scripting language to allow for bulk processing of spectra. With SPLAT the promise of BeanShell support was never able to overcome some key difficulties associated with automation. There are two scenarios for automation. The first is for an astronomer to record the steps taken manually in reducing or analyzing a spectrum and then replay that analysis on many other spectrum. The second scenario is to allow key algorithms to be made usable in a pipeline environment with the GUI disabled. For the JCMT heterodyne pipeline (Jenness et al., 2008, 2014b, ascl:1310.001) all efforts at algorithmic enhancement were focused on individual Starlink applications such as KAPPA (Currie and Berry, 2013, ascl:1403.022), because it was unclear how feasible it would be to add complex algorithms to SPLAT and make them available through the pipeline. One of the interesting approaches taken by GAIA (Draper et al., 2009) was that all analysis algorithms were called through a messaging interface such that they could be used by the interactive GUI, from the command-line or from the pipeline. This proved to be a very powerful approach but was not available in the SPLAT design. Taking care to separate core algorithms from interactive interfaces is an important design decision that has long term ramifications for an application.

### 7.5 Sub-millimetre units are complicated

VOUnits (Demleitner et al., 2014a) standardization is very useful but is not sufficient for the majority of spectral line data that is encountered by sub-millimetre astronomers. Sub-millimetre spectra are generally calibrated in temperature rather than janskys and there are two competing standards for handling the different calibration factors that are involved in converting from such definitions as corrected antenna temperature, main-beam temperature and antenna temperature (Kutner and Ulich, 1981; Downes, 1989; Wilson et al., 2009). The units alone do not tell you which temperature scale is in use and many efficiency values are required when comparing spectra from different telescopes. The situation is in dire need of standardization efforts and we simply had to ignore the issue in SPLAT.

### 7.6 Service selection interface depends on Registry

The new SSAP service selection interface, using more metadata information from the services, is meant to help the user to choose the specific services needed and to avoid making unnecessary queries and downloading data which is not needed. Sometimes too much detail may lead to confusion, especially if the service information from the registries is often incomplete. If the data is not there as it should be a detailed interface won’t do much. The current interface will be redesigned in the future, to be probably simpler but more accurate. It has also been planned to use RegTap (Demleitner et al., 2014b) to look for spectral services, which may provide easier handling.

### 7.7 Tracking VO standards is hard

SPLAT transitioned from a local analysis tool to a VO client during the birth of the VO and witnessed an explosive growth of standards during that time. One interesting outcome of this was that funding for SPLAT became scarce as the VO grew and funds were diverted from classical astronomy software development efforts. VO standards became increasingly important and it was clear that support should be added for SSAP and related standards although it was a struggle to prioritize this effort as VO adoption was initially slow and astronomers were not driving the initial support for these facilities.

SPLAT-VO is being updated to add support for standards such as DataLink (Dowler et al., 2014), ObsCore (Louys et al., 2011) and RegTap (Demleitner et al., 2014b) as well as expanded units support with VOUnits (Demleitner et al., 2014a) required to understand the metadata from these services, but the VO standards will continue to evolve as new versions are announced and new standards developed and it will be a continuing struggle to remain compliant. There is a worry that all the development effort available to SPLAT-VO will be spent simply on maintaining standards support and this will be at the expense of supporting new analysis algorithms. This is a very difficult balancing act and we can not expect the IVOA standards process to stagnate purely to make life easier for applications developers.

### 7.8 The client is not omnipotent

During the discussions about VO standards we often hear that the protocol should be very simple, focusing just on allowing users to query the particular data set and express the location of original files, with all the additional post-processing of data left as a task for the client.

Unfortunately, when we started using SPLAT-VO and a simple SSAP server of stellar spectra from Ondřejov HEROS observations, we immediately faced the limitations of purely client-based processing. Every spectrum of HEROS (Šlechta and Škoda, 2002) is more than forty five thousand points long covering about 4500  (in two channels). Upcoming instruments from sub-millimetre telescopes such as CCAT (Jenness et al., 2014c) may have a hundred thousand channels per spectrum and echelle spectra (like those from UVES (Dekker et al., 2000) or HARPS (Pepe et al., 2000)) may have as many as three hundred thousand points. Just downloading thousands of spectra takes a long time, but zooming on every spectral line to see it in detail and unzooming takes even longer, while consuming lot of memory.

This practical experience demonstrated the analysis of a stack of hundreds of complete spectra in SPLAT-VO on a common computer, was a very inconvenient and time consuming task (if possible at all), while usually only a short spectral range of tens of Angstroms was needed to display each time. If the server itself (usually a very powerful computer with a lot of memory) would trim to the required range, the client need download only a very small data chunk, which could be quickly displayed. Instead of spending time zooming to another line we can in principle perform another query in different spectral range requesting again only a short piece of another line range.

The need for server-side post-processing, as articulated by our experience with analysis of thousands of spectra lead to the first implementation of a VO-based post-processing server, based on the PLEINPOT suite (Chilingarian et al., 2005), with simple on-the-fly cutouts and relative rescaling of spectra, later on ported to DaCHS and supplemented by automatic continuum normalization. As SSAP does not contain support for post-processing, it was decided pragmatically to “overload” the SSAP query parameters representing query and processing parameters at the same time.

This required to set up another (post-processing) SSAP server, where the BAND limits are used for cutting of the given spectral range (previously selected) and FLUXCALIB was understood as a command to divide by the maximum value (FLUXCALIB=relative) or call automatic continuum normalization (FLUXCALIB=normalized). This allowed us to display detailed profiles of hundreds of spectra, including the very long echelle spectra, study line profiles evolution in long time-series or identify emission episodes in a long series of Be stars observations just by overplotting hundreds of on-the-fly normalized cuts of the H line. Although this solution is not consistent with original VO standard motivation, it served its purpose and resulted in the getData proposal, finally replaced by DataLink, even though the original DataLink was not conceived as post-processing mechanism (rather it should just point to alternative version of images or previews etc.). In any case it is clear that the client is generally not able to handle large amounts of spectra, due to lack of memory and processing power. The properly balanced design separation of tasks between client and server allows for comfortable processing of really Big Data. A very nice and clean protocol, which cannot handle real scientific needs, must finally be made more complex by extensions. Even if it is nice idea, we cannot put all the processing burden on the client. This is always the difficult trade-off between design simplicity and scientific requirements.

## 8 Obtaining SPLAT-VO

SPLAT-VO is released in a variety of ways, you can build it using the source code, obtain it as part of a Starlink JAC release. Alternatively you can install into your desktop using a standalone IzPack bundled version or run it up using Java webstart.

The bundled standalone and webstart releases of SPLAT-VO are currently available for the following desktops, Linux (32 and 64 bit), Mac OS X (32 and 64 bit Lion) and Windows Vista and later (32 and 64 bit). Previous versions also worked on Solaris, Sparc and Intel, and OS X PPC.

The Starlink releases (e.g., Currie et al., 2014; Berry et al., 2013) are available for Linux (32 and 64 bit) and OS X (Lion and Snow Leopard).

See ascl:1402.007 for the main support site where links to these releases can be found. Releases of recent GAVO developments are also available and these developments will be merged into the main SPLAT-VO releases.

The source code for SPLAT-VO and its associated libraries is open-source and available on Github at https://github.com/Starlink/starjava

## 9 Conclusions

SPLAT-VO is a very powerful tool for the analysis of spectra allowing the immediate browsing of world-wide distributed archives as well as detailed studies of individual objects across the whole electromagnetic spectrum by the building of SEDs from spectra taken in many different energy bands. Its capabilities make it an ideal tool for the analysis of astronomical spectra on the local desktop, facilities that are promoted to full productivity when combined with resources from the VO environment. It is currently under active development, promising soon handling of light curves and data cubes. We also intend to add support for automatic matching of line identifiers to spectra, simultaneous processing of multiple spectra, automated continuum normalization, and enhanced support of FITS extensions and metadata.

As a result of combining the effort of GAVO DaCHS server suite developers and SPLAT-VO developers, SPLAT-VO is an ideal reference implementation for testing new IVOA proposed standards, as required by IVOA rules, for pushing standards in the recommendation phase.

## Acknowledgements

The initial work on SPLAT-VO was supported by the now closed Starlink Project funded by the Particle Physics and Astronomy Research Council and more recently by the Joint Astronomy Centre, Hawaii, also funded by the Particle Physics and Astronomy Research Council and more recently by its successor organization the Science and Technology Facilities Council.

The current work on SPLAT-VO by GAVO is supported by German Federal Ministry of Education and Research, BMBF grant 05A11VH3 and the Czech development is supported by grant 13-08195S of Granting Agency of the Czech Republic and by the Czech project RVO:67985815.

We thank Mark Taylor, who added the SAMP support to SPLAT-VO and created the VO Registry and TAP query libraries used (these are part of StarJava). We also thank Markus Demleitner who actively supports the new features in SPLAT-VO SSAP and DataLink handling by the development of GAVO DaCHS server publishing suite. Finally we thank Jan Wouterloot for his work testing the sub-millimetre features of SPLAT-VO.

Many new features of SPLAT-VO are based on everyday experience with analysis of hot emission line stars spectra observed at Perek 2m Telescope of the Ondřejov observatory of the Astronomical Institute of the Academy of Sciences, Czech Republic. We greatly acknowledge the help of M. Šlechta, responsible for reduction of most of the spectra and students T. Peterka and J. Nádvorník for the set up and maintenance of the SSAP services of the AI stellar department, with which SPLAT-VO was heavily tested in recent years.

## References

• Akima (1970) Akima, H., 1970. A new method of interpolation and smooth curve fitting based on local procedures. J. ACM 17, 589–602.
• Andrešič (2013) Andrešič, D., 2013. Programme for Interactive Spectra Analysis in Virtual Observatory Environment. Bachelor thesis. VŠB - Technical University of Ostrava. Faculty of Electrical Engineering and Computer Science VŠB-TUO, Ostrava, Czech Republic.
• Astropy Collaboration (2013) Astropy Collaboration, 2013. Astropy: A community Python package for astronomy. A&A 558, A33.
• Balm (2012) Balm, P., 2012. Herschel Interactive Processing Environment (HIPE): Open to the World and the Future, in: Ballester, P., Egret, D., Lorente, N.P.F. (Eds.), Astronomical Data Analysis Software and Systems XXI, volume 461 of ASP Conf. Ser.. p. 733.
• Benson et al. (2009) Benson, K. et al., 2009. IVOA Registry Interfaces Version 1.0 IVOA Recommendation.
• Berry et al. (2013) Berry, D., Currie, M., Jenness, T., Draper, P., Bell, G., Tilanus, R., 2013. Starlink 2012: The Kapuahi Release, in: Friedel, D.N. (Ed.), Astronomical Data Analysis Software and Systems XXII, volume 475 of ASP Conf. Ser.. p. 247.
• Berry and Jenness (2012) Berry, D.S., Jenness, T., 2012. New Features in AST: A WCS Management and Manipulation Library, in: Ballester, P., Egret, D., Lorente, N.P.F. (Eds.), Astronomical Data Analysis Software and Systems XXI, volume 461 of ASP Conf. Ser.. p. 825.
• Bly et al. (2002) Bly, M. J. et al., 2002. Starlink Software Developments, in: Bohlender, D.A., Durand, D., Handley, T.H. (Eds.), Astronomical Data Analysis Software and Systems XI, volume 281 of ASP Conf. Ser.. p. 513.
• Busko (2002) Busko, I., 2002. Specview: a Java tool for spectral visualization and model fitting of multi-instrument data, in: Starck, J.L., Murtagh, F.D. (Eds.), Astronomical Data Analysis II, volume 4847 of Proc. SPIE. pp. 410–418. doi:10.1117/12.460371.
• Caux et al. (2011) Caux, E., Bottinelli, S., Vastel, C., Glorian, J.M., 2011. CASSIS, a software package to analyse high spectral resolution observations, in: Cernicharo, J., Bachiller, R. (Eds.), The Molecular Universe, volume 280 of IAU Symposium. p. 120P.
• Chilingarian et al. (2005) Chilingarian, I. et al., 2005. MIGALE: Milestones and Roadmap, in: Shopbell, P., Britton, M., Ebert, R. (Eds.), Astronomical Data Analysis Software and Systems XIV, volume 347 of ASP Conf. Ser.. p. 385.
• Currie and Berry (2013) Currie, M.J., Berry, D.S., 2013. KAPPA – Kernel Application Package. Starlink User Note 95. Joint Astronomy Centre.
• Currie et al. (2014) Currie, M.J., Berry, D.S., Jenness, T., Gibb, A.G., Bell, G.S., Draper, P.W., 2014. Starlink in 2013, in: Manset, N., Forshay, P. (Eds.), Astronomical Data Analysis Software and Systems XXIII, volume 485 of ASP Conf. Ser.. p. 391.
• Dekker et al. (2000) Dekker, H., D’Odorico, S., Kaufer, A., Delabre, B., Kotzlowski, H., 2000. Design, construction, and performance of UVES, the echelle spectrograph for the UT2 Kueyen Telescope at the ESO Paranal Observatory, in: Iye, M., Moorwood, A.F. (Eds.), Optical and IR Telescope Instrumentation and Detectors, volume 4008 of Proc. SPIE. pp. 534–545.
• Demleitner (2014) Demleitner, M., 2014. The DaCHS multi-protocol VO server, in: Manset, N., Forshay, P. (Eds.), Astronomical Data Analysis Software and Systems XXIII, volume 485 of ASP Conf. Ser.. p. 309.
• Demleitner et al. (2014a) Demleitner, M., Derriere, S., Gray, N., Louys, M., Ochsenbein, F., 2014a. Units in the VO Version 1.0 IVOA Proposed Recommendation.
• Demleitner et al. (2014b) Demleitner, M., Harrison, P., Molinaro, M., Greene, G., Dower, T., Perdikeas, M., 2014b. IVOA Registry Relational Schema Version 1.0 IVOA Proposed Recommendation.
• Demleitner and Škoda (2012) Demleitner, M., Škoda, P., 2012. SSAP evolution 2012, IVOA Note.
• Disney and Wallace (1982) Disney, M.J., Wallace, P.T., 1982. STARLINK. QJRAS 23, 485.
• Dowler et al. (2014) Dowler, P., Bonnarel, F., Michel, L., Donaldson, T., Languignon, D., Demleitner, M., 2014. DataLink Version 1.0 IVOA Working Draft.
• Downes (1989) Downes, D., 1989. Radio Astronomy Techniques, in: Appenzeller, I., Habing, H.J., Lena, P. (Eds.), Evolution of Galaxies: Astronomical Observations, volume 333 of Lecture Notes in Physics. p. 351.
• Draper (2000) Draper, P.W., 2000. GAIA: Recent Developments, in: Manset, N., Veillet, C., Crabtree, D. (Eds.), Astronomical Data Analysis Software and Systems IX, volume 216 of ASP Conf. Ser.. p. 615.
• Draper et al. (2005) Draper, P.W., Allan, A., Berry, D.S., Currie, M.J., Giaretta, D., Rankin, S., Gray, N., Taylor, M.B., 2005. Starlink Software Developments, in: Shopbell, P., Britton, M., Ebert, R. (Eds.), Astronomical Data Analysis Software and Systems XIV, volume 347 of ASP Conf. Ser.. p. 22.
• Draper et al. (2009) Draper, P.W., Berry, D.S., Jenness, T., Economou, F., 2009. GAIA – Version 4, in: Bohlender, D.A., Durand, D., Dowler, P. (Eds.), Astronomical Data Analysis Software and Systems XVIII, volume 411 of ASP Conf. Ser.. p. 575.
• Draper et al. (2013) Draper, P.W., Taylor, M.B., Neves, M.C., 2013. SPLAT-VO – A VO-enabled Spectral Analysis Tool. Starlink User Note 243.
• Fitzpatrick (2012) Fitzpatrick, M., 2012. IRAF: Lessons for Project Longevity, in: Ballester, P., Egret, D., Lorente, N.P.F. (Eds.), Astronomical Data Analysis Software and Systems XXI, volume 461 of ASP Conf. Ser.. p. 595.
• Giaretta et al. (2003) Giaretta, D., Taylor, M., Draper, P., Gray, N., McIlwrath, B., 2003. HDX Data Model: FITS, NDF and XML Implementation, in: Payne, H.E., Jedrzejewski, R.I., Hook, R.N. (Eds.), Astronomical Data Analysis Software and Systems XII, volume 295 of ASP Conf. Ser.. p. 221.
• Greisen et al. (2006) Greisen, E.W., Calabretta, M.R., Valdes, F.G., Allen, S.L., 2006. Representations of spectral coordinates in FITS. A&A 446, 747–771.
• Hill (1982) Hill, G., 1982. Intep - an Effective Interpolation Subroutine. Publications of the Dominion Astrophysical Observatory Victoria 16, 67.
• Jenness et al. (2014a) Jenness, T. et al., 2014a. Learning from 25 years of the extensible N-Dimensional Data Format. Astronomy & Computing submitted.
• Jenness et al. (2008) Jenness, T., Cavanagh, B., Economou, F., Berry, D.S., 2008. JCMT Science Archive: Advanced Heterodyne Data Products Pipeline, in: Argyle, R.W., Bunclark, P.S., Lewis, J.R. (Eds.), Astronomical Data Analysis Software and Systems XVII, volume 394 of ASP Conf. Ser.. p. 565.
• Jenness et al. (2014b) Jenness, T., Currie, M.J., Cavanagh, B., Berry, D.S., Leech, J., Rizzi, L., 2014b. Automated reduction of single-dish heterodyne data from the James Clerk Maxwell Telescope using ORAC-DR. Astronomy & Computing in preparation.
• Jenness et al. (2014c) Jenness, T. et al., 2014c. An overview of the planned CCAT software system, in: Chiozzi, G., Radziwill, N.M. (Eds.), Software and Cyberinfrastructure for Astronomy III, volume 9152 of Proc. SPIE. p. 9152109.
• Kramida et al. (2012) Kramida, A., Ralchenko, Y., Reader, J., 2012. Current Status of Atomic Spectroscopy Databases at NIST, in: APS Division of Atomic, Molecular and Optical Physics Meeting Abstracts, p. D1004.
• Kramida et al. (2013) Kramida, A., Yu. Ralchenko, Reader, J., and NIST ASD Team, 2013. NIST Atomic Spectra Database (ver. 5.1), National Institute of Standards and Technology, Gaithersburg, MD.
• Kupka et al. (2011) Kupka, F., Dubernet, M.L., VAMDC Collaboration, 2011. Vamdc as a Resource for Atomic and Molecular Data and the New Release of Vald. Baltic Astronomy 20, 503–510.
• Kutner and Ulich (1981) Kutner, M.L., Ulich, B.L., 1981. Recommendations for calibration of millimeter-wavelength spectral line data. ApJ 250, 341–348. doi:10.1086/159380.
• Landsman (1993) Landsman, W.B., 1993. The IDL Astronomy User’s Library, in: Hanisch, R.J., Brissenden, R.J.V., Barnes, J. (Eds.), Astronomical Data Analysis Software and Systems II, volume 52 of ASP Conf. Ser.. p. 246.
• Laurino et al. (2014) Laurino, O., Budynkiewicz, J., Busko, I., Cresitello-Dittmar, M., D’Abrusco, R., Doe, S., Evans, J., Pevunova, O., 2014. Iris: Constructing and Analyzing Spectral Energy Distributions with the Virtual Observatory, in: Manset, N., Forshay, P. (Eds.), Astronomical Data Analysis Software and Systems XXIII, volume 485 of ASP Conf. Ser.. p. 19.
• Louys et al. (2011) Louys, M. et al., 2011. Observation Data Model Core Components and its Implementation in the Table Access Protocol Version 1.0 IVOA Recommendation.
• Lovas (2004) Lovas, F.J., 2004. NIST Recommended Rest Frequencies for Observed Interstellar Molecular Microwave Transitions-2002 Revision. Journal of Physical and Chemical Reference Data 33, 177–355. doi:10.1063/1.1633275.
• Niemeyer and Leuck (2013) Niemeyer, P., Leuck, D., 2013. Learning Java. O’Reilly Media. URL: http://chimera.labs.oreilly.com/books/1234000001805. ISBN 978-1-4493-7249-1.
• Ochsenbein et al. (2005) Ochsenbein, F., Fernique, P., Bonnarel, F., Allen, M., Boch, T., Genova, F., Schaaff, A., 2005. Interoperability in Action: the Aladin Experience, in: Shopbell, P., Britton, M., Ebert, R. (Eds.), Astronomical Data Analysis Software and Systems XIV, volume 347 of ASP Conf. Ser.. p. 193.
• Ochsenbein et al. (2004) Ochsenbein, F. et al., 2004. VOTable: Tabular Data for the Virtual Observatory, in: Quinn, P.J., Górski, K.M. (Eds.), Toward an International Virtual Observatory, p. 118. doi:10.1007/10857598_18.
• Ortiz et al. (2008) Ortiz, I. et al., 2008. IVOA Astronomical Data Query Language Version 2.0 IVOA Recommendation.
• Osuna et al. (2005) Osuna, P., Barbarisi, I., Salgado, J., Arviset, C., 2005. VOSpec: A Tool for Handling Virtual Observatory Compliant Spectra, in: Shopbell, P., Britton, M., Ebert, R. (Eds.), Astronomical Data Analysis Software and Systems XIV, volume 347 of ASP Conf. Ser.. p. 198.
• Padman (1993) Padman, R., 1993. SPECX V6.3 Users’ Manual. University of Cambridge.
• Parimucha and Škoda (2007) Parimucha, v., Škoda, P., 2007. Comparison of Selected Methods for Radial Velocity Measurements, in: Hartkopf, W.I., Harmanec, P., Guinan, E.F. (Eds.), Binary Stars as Critical Tools & Tests in Contemporary Astrophysics, volume 240 of IAU Symposium. pp. 486–489.
• Pence et al. (2010) Pence, W.D., Chiappetti, L., Page, C.G., Shaw, R.A., Stobie, E., 2010. Definition of the Flexible Image Transport System (FITS), version 3.0. A&A 524, A42.
• Pepe et al. (2000) Pepe, F. et al., 2000. HARPS: a new high-resolution spectrograph for the search of extrasolar planets, in: Iye, M., Moorwood, A.F. (Eds.), Optical and IR Telescope Instrumentation and Detectors, volume 4008 of Proc. SPIE. pp. 582–592.
• Remijan (2010) Remijan, A.J., 2010. Splatalogue - Motivation, Current Status, Future Plans, in: American Astronomical Society Meeting Abstracts #215, volume 42 of Bulletin of the American Astronomical Society. p. 568.
• Škoda (1996) Škoda, P., 1996. SPEFO—A Simple, Yet Powerful Program for One-Dimensional Spectra Processing, in: Jacoby, G.H., Barnes, J. (Eds.), Astronomical Data Analysis Software and Systems V, volume 101 of ASP Conf. Ser.. p. 187.
• Škoda (2008) Škoda, P., 2008. Common Methods of Stellar Spectra Analysis and their Support in VO, in: Guainazzi, M., Osuna, P. (Eds.), Astronomical Spectroscopy and Virtual Observatory, p. 97.
• Škoda et al. (2014) Škoda, P., Hroch, F., Nádvorník, J., Mikhailova, D., 2014. Employing the Technology of Virtual Observatory as the Fundamental Framework for the CCD Photometry Survey, in: Manset, N., Forshay, P. (Eds.), Astronomical Data Analysis Software and Systems XXIII, volume 485 of ASP Conf. Ser.. p. 305.
• Šlechta and Škoda (2002) Šlechta, M., Škoda, P., 2002. 2-meter telescope devices: coudé slit spectrograph and HEROS. Publications of the Astronomical Institute of the Czechoslovak Academy of Sciences 90, 1–4.
• Taylor et al. (2007) Taylor, J.D., Boch, T., Comparato, M., Taylor, M., Winstanley, N., Mann, R.G., 2007. Binding Applications Together with PLASTIC, in: Shaw, R.A., Hill, F., Bell, D.J. (Eds.), Astronomical Data Analysis Software and Systems XVI, volume 376 of ASP Conf. Ser.. p. 511.
• Taylor (2005) Taylor, M.B., 2005. TOPCAT & STIL: Starlink Table/VOTable Processing Software, in: Shopbell, P., Britton, M., Ebert, R. (Eds.), Astronomical Data Analysis Software and Systems XIV, volume 347 of ASP Conf. Ser.. p. 29.
• Taylor (2006) Taylor, M.B., 2006. STILTS - A Package for Command-Line Processing of Tabular Data, in: Gabriel, C., Arviset, C., Ponz, D., Enrique, S. (Eds.), Astronomical Data Analysis Software and Systems XV, volume 351 of ASP Conf. Ser.. p. 666.
• Taylor et al. (2012) Taylor, M.B., Boch, T., Fay, J., Fitzpatrick, M., Paioro, L., 2012. SAMP: Application Messaging for Desktop and Web Applications, in: Ballester, P., Egret, D., Lorente, N.P.F. (Eds.), Astronomical Data Analysis Software and Systems XXI, volume 461 of ASP Conf. Ser.. p. 279.
• Tody et al. (2012) Tody, D. et al., 2012. Simple Spectral Access Protocol Version 1.1 IVOA Recommendation.
• Walton and AstroGrid Consortium (2008) Walton, N.A., AstroGrid Consortium, 2008. The AstroGrid Virtual Observatory Service, in: Argyle, R.W., Bunclark, P.S., Lewis, J.R. (Eds.), Astronomical Data Analysis Software and Systems XVII, volume 394 of ASP Conf. Ser.. p. 251.
• Warmels (1992) Warmels, R.H., 1992. The ESO–MIDAS System, in: Worrall, D.M., Biemesderfer, C., Barnes, J. (Eds.), Astronomical Data Analysis Software and Systems I, volume 25 of ASP Conf. Ser.. p. 115.
• Warren-Smith and Berry (1998) Warren-Smith, R.F., Berry, D.S., 1998. World Coordinate Systems as Objects, in: Albrecht, R., Hook, R.N., Bushouse, H.A. (Eds.), Astronomical Data Analysis Software and Systems VII, volume 145 of ASP Conf. Ser.. p. 41.
• Williams and Bridger (2013) Williams, S., Bridger, A., 2013. Spectral Line Selection in the ALMA Observing Tool, in: Friedel, D.N. (Ed.), Astronomical Data Analysis Software and Systems XXII, volume 475 of ASP Conf. Ser.. p. 373.
• Wilson et al. (2009) Wilson, T.L., Rohlfs, K., Hüttemeister, S., 2009. Tools of Radio Astronomy. Springer-Verlag.
You are adding the first comment!
How to quickly get a good reply:
• Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
• Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
• Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters