IVOA DM Work Package : Units description and usage

OLD PAGE - see UnitsDesc for NEW PAGE (June 2008)

• lead Anita Richards with help from MireilleLouys

---

Goal

This workpage is meant to record the general practice in manipulating units for astronomical data and define a simple way to homogeneise their representation within VO services
The main discussion will be initiated at the Interop meeting 2007 27 Sep (Cambridge) and recorded in the DM forum and on this page, but if necessary we will use email between a small group to thrash out details (as for Characterisation).

Recommendations

From IVOA Trieste 2008 May 19.

• Produce list of IVOA-supported units
  • Preferred (e.g. CDS and HEASARC)
    • Is HEASARC the same as STC? If not, STC also
  • Acceptable (where other strings exist)
    • AMSR comment a few alternatives would be acceptable e.g. au or AU for Astronomical Unit, where these are unambigous; we have to be able to cater for existing data.
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
  • Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
• Educate next generation of data providers to use some standard for units
• Outstanding issues
  • FITS units and other systems - can these all be handled by assuming that the IVOA provides access to such data via a metadata database? in which case the software which populates the DB (e.g. MEXX) does the translating from FITS standards or even known non-standards?
  • Need to record date and reference to values of fundamental quantities where available.
• Identified key players (please add yourself as appropriate)
  • ESAC - dimensional analysis
  • AstroGrid - STILTS and Starlink libraries
  • STC team - someone working on units

---

Previous discussion/links to existing libraries of units

Approach

How do we find out what are VO priorities?

• What units do major data providers use?
  • Existing codings and definitions
• What units do users want? (literature search?)
  • Need to strike a balance between being user-friendly and excessively complex models
• Establish use cases to define the minimum requirements for use of units in VO data models and applications.
• Produce preliminary requirements document
• Use test implimentations
• Check for consistency between IAU and CDS and other widely used current standards
• Develop

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
    • note This looks very useful for SI and a few other units. It is not clear if it covers astronomical units but it states that it is designed to be used alongside other namespaces. This could be the starting point for technical developers? AnitaRichards
  • Type `units' in many types of Linux
  • FITS FITS references page, development
• Discussion/implementation
  • Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
    • note This does not look too bad, as regards being possible to provide schemata for synonyms of the commonest SI and astronomical units - apart from a few degeneracies. AnitaRichards
  • Section 4 in Greisen and Calabretta 2002, A&A 395, 1061 - see Specification of Physical Units within OGIP FITS files (not only relevant to FITS)
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • check SpecView...
  • Unit strings allowed in STC from ArnoldRots

Action: There are few instances of multiple legitimate names for the same unit (benign). There may be a very few instances of the same name for different units e.g. k could be kilo- or Boltzmann's constant, but this could be solved by adopting a syntax for separating prefixes v. different components of multiple units. IVOA units must be machine readable which makes parts of the IAU system unsuitable since they use Greek letters, diacritical marks etc. However it seems to me that a schema could be written which combined CDS and HEASARC and STC as unambigious alternatives and this would be much quicker than trying to modify existing data.

We should make sure that tools for extracting metadata from FITS is consistent with this (is there a need for transation from FITS keywords). This is the point where custom exensions to software could correctly interpret errors like the infamous ISO Watts.

• NB need to specify (where possible) the date and reference for values used when data were published e.g. value of second, metre.

Existing or new tools and Libraries

Where are units needed?

Construction of Spectral Energy Distributions

The use of units and interconversions has been well-developed e.g. in VOSpec and YAFIT, but consistency is due to the cooperation of the individuals involved. A model for units would recognise this effort and allow it to be applied more widely.

TAP - source catalogue DM - need to compare quantities

SPECFIND : A tool to extract cross-identifications and radio continuum spectra from radio catalogues contained in the VIZIER database of the CDS.
Reference: SPECFIND Catalog of radio continuum spectra
Authors: Vollmer, B.; Davoust, E.; Dubois, P.; Genova, F.; Ochsenbein, F.; van Driel, W.
Publication: VizieR On-line Data Catalog: VIII/74.

Cone, S?AP, registry searches

The current IVOA standards mandate units, but in some cases this repeatedly leads to problems e.g..

• Cone search/SIAP radius - decimal degrees
  • Anomalous results are often obtained due to a service returning a region in other units (e.g. 0.1 arcmin instead of degree) (see DB queries below).
• Spectral region - wavelength in metres
  • Conversion from frequency and energy units is non-linear. Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe the spectral resolution with a single number, if it is e.g. 1 MHz in regions between 1 and 30 GHz.

Conversion tools

Need precise unit definitions

Examples include:

• Flux unit conversions e.g. VOSpec, tools using the STILTS library
• Coordinate conversions (B1950 RA-Dec to J2000 glat-glon etc.) e.g. tools using the STILTS library, SIMBAD services etc.

Database queries

We have no control over the units used by data providers (?). We do need to be able to recognise them.

• Cone searches have mandated units (see below)
• ADQL users have to know what units to use for the query parameters. How can they check this?

Actually we can have influence - e.g. through Euro-VO DCA - at least to remind people to adhere to appropriate 'local' standard e.g.

• no plurals W or Watt but never Watts (ambiguity with Watt second)
• capitalisation matters m(illi) v. M(ega)

Enabling convenient image display

Use case: Need a library to support displaying images with coordinates in sensible units (i.e. using SI multiple etc.) and to allow easy conversions e.g. Jy arcsec-2 to Jy sr-1 (JP Leahy).

Lessons so far

Dimensional approach (see VOSpec)

Automated dimensional analysis could be an easy way to check for consistency. Request for dimensional analysis tools/library to be available.

Services with mandated units

Many data publishers install VO services on top of existing archives in arbitrary units. We can't expect the astronomical users to know what that is so e.g. SIAP search areas are always supposed to be in decimal degrees, but this often comes unstuck if data are in other units. What is best:

• Make it easy/persuade data providers forcibly to supply information in the correct units. This would probably be feasible for data bases but near-impossible for FITS and other observed data (unless it was accessed via a database). Not all data providers would comply and either just ignor the requirement or not provide their data.
• Find a way to insert a unit conversion tool in the query path (complicates the S?APs)

Conversions

It is important to define the limits of accuracy e.g.

• Magnitude-flux - even if all observational quantities e.g. the zero-points are supplied, accuracy is limited to a few percent unless corrections like the colour of individual objects are included.
• Positional coordinates - .epoch as well as equinox; leap seconds etc. needed for milli-arcsec accuracy.

We eventually need to be able to convert any units as accuracy as possible but often the full information is not available, so tools need to be flexible and settle for lower accuracy where unavoidable.

Models for units could include

• Simple formulae (but where is maths done? Limitations inside DBs)
• Look-up tables (where?)
• More sophisticated references to services, links with references in data etc.

Results and Feedback

• Comment from discussion: scope is to enable non-linear conversions (like freq-wavelength), not to include the mechanism in the Units model. That is, we should look at the requirements of the existing tools, not duplicate them.

Interactions with other WG efforts

• IVOA VO Query Language

---