This workpage is meant to record the general practice in manipulating
units for astronomical data and define a means of consistent
representation within VO services.
This is a Working Draft. The first release of this document was 2008 October.
Working Draft
This is an IVOA Working Draft for review by IVOA members and other interested parties.
It is a draft document and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "work in progress.
A list of
current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.
We thank Paddy Leahy, Arnold Rots, ... for contributing use cases and examples of usage.
The VO and its users employ units:
- in IVOA XML documents, Votable, xml
- in applications
- in queries
This diagram is intended to exemplify processes which use units.
Assuming that the VO itself is internally consistent, the arrows are
all stages where translation or interpretation of units might be
needed. We have to decide where and how and what tools to use.
The need for a Units model has arisen from several needs:
- To understand m, meter, metre ... as the same thing
- To differentiate mm (milli-metre) and mm (m2)
- To distinguish between the use of m as a wavelength (= c/frequency) and m as a distance (=1/1.499 1011 AU) etc.
- To create combinations of units intelligently e.g. J / s = W
- To translate between SI prefixes (G, M, k etc.) intelligently
It is not the role of this workpackage to provide a means of converting instrument-related units such as magnitudes, nor to perform coordinate conversions. The former is the domain of the PhotometryDataModel (NEED CORRECT LINK); excellent libraries e.g. AST already exist for the latter. It is our role to meet the needs of these workpackages and provide consistency.
The examples below are reasonably consistent. At this stage we will not consider further representations which are only suitable for use in human-readable literature, e.g. many IAU symbols using Greek letters etc. The other systems are (mostly) machine readable.
-
Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units (Derriere)
- Standards for Astronomical Catalogues, Version 2.0
- Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
- Unit strings allowed in STC (Rots)
- NIST (National Institute of Standards & Technology) project UnitsXML
- FITS standards: Reference, Development, Specification of Physical Units within OGIP FITS files (Greisen and Calabretta 2002, A&A 395, 1061)
- Java JSR-275 specifies one or more Java packages for the programmatic handling of physical quantities and their expression as numbers of units.
This is an attempt to clarify the relationshipe between quantities and units:
A quantity, e.g. a measurement of a physical value like the speed of light, has a value (2.998 10+5), a ucd (phys.veloc), units (km s-1) and a type (real).
Some quantities are also units.
Many units are expressed, or converted, in terms of physical constants such as the speed of light, c = 2.998 10+8 m s-1 ; Boltzman's constant, 1.38065×10-23kg·m+2·s-2·K-1 ; the AU (1.499 10+11 m). Many of these are used as units in their own right, e.g. velocities may be expressed as a fraction or multiple of c, but c is also used to convert between wavelength and frequency, etc.
These are combinations of units with scaling factors applied, and so can be treated in the same way as any other compound unit e.g. Jy (10-26 W m-2 Hz-1)
Some of the links in Vocabularies e.g. for Java, contain libraries. One of the most widely-used specialised astronomical libraries is AST which includes a units conversion facility.
These are standards to be used internally. We need to provide translation to/from other usages as far as is required/practical. These are examples of the decisions we need, not necessarily the exact form to be adopted, experts please comment.
- We use SI (not cgs etc.)
- We allow European or US spelling (metre or meter) - if this is ever needed
- SI prefixes directly preceed a unit, no space e.g. mT = milli-Tesla, Tm = Tera-metre
- Compound units are indicated by a dot, no space e.g. N.m = Newton metre
- Powers are indicated by + or - e.g. m+2 = metre x metre, m s-1 = m/s
This will allow fractional powers e.g. T+2/7. However, there might be some ambiguity with operations e.g. m + 2, metres plus 2 - any ideas?
This now shows the levels at which conversions might be done.
Thick red arrows: At the point where an astronomer or data provider submits input to the VO, we should provide tools to ensure that units are labelled consistently (e.g. mm for millimeter; m+2 or m.m for m2 ; SI prefixes, or whatever is adopted).
Dashed brown arrows: More complex conversions e.g. AU s-1 to m s-1 are done where and when they are required.
How do we implement the first stage when dealing with input, i.e. converting to a standard vocabulary (prior to any interpretation of units), e.g. meter = metre = m, mm = milli-metre, m*m = m.m = m+2 .
Backus Naur format (as used e.g. for ADQL) provides cross-references to define terms, e.g.
Jy = 10-26 W m-2 Hz-1
W = J s-1
...
Jy = 10-26 kg m+2 s-2 s-1 m-2 s
Dimensional analysis provides a means of converting between units with appropriate scaling factors, for relationships between quantities in different units; e.g. between (flux density in Jy v. wavelength) and flux density in erg s-1 cm-2 A-1 v. wavelength).
An equivalent(?) method using ucds (**UML diagram or reference). e.g. convert m (wavelength) to Hz (frequency) and convert m (distance) to Mpc (distance).
Test case: can both methods cope with
cosmological_distance = cz H0-1
where
z = (lambda_obs - lambda_rest)/lambda_rest i.e. dimensionless (but might itself be calculated as part of a VO workflow - note that this is only one possible definition, see STC...)
Hubble constant H0 = 65 km s-1 Mpc-1 (or nearest offer)
If you have an appendix, put content here
[1] Author(s), Title
http://
