[fitswcs] [Fwd: Re: WCS Paper III comments]

Thu Nov 4 04:44:22 EST 2004

Dear Dave,

you can access my presentation at the ADASS at:

http://adass.ipac.caltech.edu/Presentations/Tuesday/Osuna_O5_3.pdf

where you can find in slide number 10 an example for this type of
transformations.

Anyway, the reasoning goes in the following lines:

Lets call the units Phi1 and Phi2. Their respective dimensions are given
by (no scaling factors here; see slide 10 for that):
(square brackets mean dimensions)

[Phi1] == [w/m^2Hz] = M T^-2

[Phi2] == [w/m^2Ang] = M L^-1 T^-3

to go from one to the other:

[Phi1]     M T^-2
------ = ------------ = L T
[Phi2]    M L^-1 T^-3

The dimensional basis for spectra is formed by the quantities {c,LAMBDA}
(other physical problems might have different bases, as I say in my
mail)(for units with mass, the planck constant might be added, but it
can also be treated in units of {c,LAMBDA}).

 Therefore, the former division of units has to be of the form:

[Phi1]     
------ = [c]^n [LAMBDA]^m
[Phi2]   

as:

[c] = L T^-1
[LAMBDA] = L

then:

[Phi1]     
------ = [L T^-1]^n [L]^m = L^(n+m) T^-n
[Phi2]   

therefore:

      [Phi1]     
L T = ------ =  L^(n+m) T^-n
      [Phi2]   

which implies:

n=-1
m=-2

i.e., to go from Phi2 to Phi1 we have to multiply by:

 --------------
|c^-1 LAMBDA^2 |
 --------------

which coincides with the algebraic relationship between the LAMBDA and
the NU (Frequency), as (see e.g. table 3 on WCS Paper III):

dNU/dLAMBDA = -c/LAMBDA^2

I hope this helps to clarify our approach.

Cheers,
Pedro.

On Wed, 2004-11-03 at 19:02, David Berry wrote:
> Pedro,
>        Are there further details of your approach available anywhere? I
> was not able to be at ADASS so I missed your talk. I am interested in how
> a dimensional analysis will determine the transformation between two
> spectral units such as W/m**2/Hz ( = M.T**(-2) ) and W/m**2/Ang
> ( = M.L**(-1).T**(-3) ).
> 
> David
> 
> 
> On Wed, 3 Nov 2004, William Pence wrote:
> 
> > At the recent ADASS conference, Pedro Osuna gave a talk titled "VOSpec: A
> > tool for handling Virtual Observatory Compliant Spectra" in which he made
> > some comments related to the WCS papers.  I contacted him for more details,
> > and he sent the following reply.  Since this appears to be of general
> > interest, I'm forwarding it here to the fitswcs mail list.
> >
> > Bill Pence
> >
> > -------- Original Message --------
> 
> > Subject: Re: WCS Paper III comments
> > Date: Wed, 03 Nov 2004 15:35:02 +0100
> > From: Pedro Osuna <Pedro.Osuna at sciops.esa.int>
> > To: William Pence <William.D.Pence at nasa.gov>
> > CC: Pedro.Osuna at esa.int, Jesus Salgado <Jesus.Juan.Salgado at esa.int>
> > References: <4187FD47.10205 at nasa.gov>
> >
> > Dear Bill,
> >
> > I send you some very preliminary comments to the paper you mention.
> >
> > I feel a little bit embarrassed to make comments to such an article
> > without having devoted time enough to it, as this article has been
> > checked during years and I have only had some days to look at it.
> >
> > However, we do believe that something related to what I described in my
> > talk might be a good candidate to add to the specification.
> >
> > In my talk, we describe a Dimensional Analysis way to handle units
> > automatically. By a simple description of the parameters SCALEQ and
> > DIMEQ in both axes, spectra can be compared easily without having to
> > care about unit names and string parsing, an always cumbersome  issue in
> > unit conversion algorithms.
> >
> > In Paper III, the main items are the "algebraic" relations between the
> > different possibilities of transformation among the three main possible
> > spectrum axes, wavelength, frequency and apparent velocity.
> > I wrote "algebraic" on purpose, in the sense that they describe real
> > algebraic relationship between quantities, despite their obvious
> > physical meaning.
> >
> > In this respect, the dimensional analysis is not very useful. The only
> > conclusion one can draw from it is the final dimensions of the algebraic
> > solution for the transformation; what the transformation is doing in
> > between is not possible to quantify with dimensional analysis.
> >
> > In the case where the transformations can be expressed as products of
> > quantities, the dimensional analysis will be able to determine the
> > conditions to compare the different quantities. In the cases where
> > algebraic operations appear (e.g.,addition, difference, square root) the
> > dimensional analysis will only be able to determine the dimensions of
> > the final transformation.
> >
> > This means that those conversions appearing in tables 3, 4 and 5 will
> > still be of importance for algorithms to apply to the different axes
> > transformations.
> >
> > However, we still believe that at the end of the day, a Spectrum will
> > contain some sort of data with some final units, regardless of the
> > transformations done to get to that spectrum. It is at this point where
> > the dimensional analysis could be very useful for the comparison of
> > different spectra.
> >
> > In looking at the part of the Paper III regarding the units, I got
> > pointed to Paper I, where there is a description of the recommended
> > names for units following the IAU Style Manual. Our dimensional analysis
> > treatement could find a natural place here, in the definition of the
> > units, where there would be no need to parse strings, as given  proper
> > SCALEQ and DIMEQ for the units in both axes, the name of the unit would
> > be irrelevant for the conversions.
> >
> >
> > We have shown (see our VOSpec tool, e.g.) that this works well with the
> > most common units in the case of spectral fluxes versus wavelength or
> > frequency. We have not contemplated yet the velocity in the x-axes, but
> > will work on it.
> >   For other general unit transformations, the physical problem might
> > dictate a different dimensional basis to be chosen, but we still believe
> > that having the SCALEQ and DIMEQ parameters would be of great use.
> > Clients for specific and different physical problems will know how to
> > automatically handle the units once the dimensional basis is known.
> >
> > Therefore, our comment -in relation with the dimensional analysis I
> > presented at ADASS- to those two papers would be in the line of
> > proposing to the FITS community to add one single parameter to the unit
> > description which would be called:
> >
> > DIMEQ (for example; in the FITS jargon it might look something like
> > CDIMEQn)
> >
> > and that would include for each unit, both the SCALEQ of my presentation
> > and the DIMEQ in the same line (just to simplify).
> >
> > Thus, a unit like Jy would be accompanied by a new keyword like:
> >
> > DIMEQ	'10^-26 MT^-2'
> >
> > that would combine in a single line the SCALEQ of my presentation (in
> > this case 10^-26) and the DIMEQ (MT^-2).
> >
> > This would allow clients to compare units automatically without having
> > to include logic on a per-case basis, and still human beings will be
> > able to read the unit name if they wish (useful sometimes when looking
> > at headers) with the standard CUNIT keyword.
> >
> >
> > As a summary, we believe that the DIMEQ parameter (including the SCALEQ
> > factor) is the best way to represent a unit in any case. There will be
> > cases where the automatic unit handling will be more difficult than in
> > others, but clients will develop with time and will be able to handle
> > those units using the dimensional equation. We have been able to
> > demonstrate the usefulness of this approach in spectra with the VOSpec.
> > On the other hand, only naming units with a string, even if appearing on
> > the IAU Style Manual, will be prone to confusions, as people might not
> > strictly follow the manual (cases like "um", "mu", "micron" or "micra"
> > are very common when naming the microns).
> >
> >
> > It would be nice if you could send me your comments to this mail.
> >
> > Please feel free to send it to whomever this might be of interest.
> >
> > Thank you very much.
> >
> > Cheers,
> > Pedro.
> > --
> > Pedro Osuna Alcalaya
> >
> >
> > Software Engineer
> > European Space Astronomy Center
> > (ESAC/ESA)
> > e-mail: Pedro.Osuna at esa.int
> > Tel + 34 91 8131314
> >
> >
> > European Space Astronomy Center
> > European Space Agency
> > P.O. Box 50727
> > E-28080 Villafranca del Castillo
> > MADRID - SPAIN
> >
> > _______________________________________________
> > fitswcs mailing list
> > fitswcs at listmgr.cv.nrao.edu
> > http://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs
> >
-- 
Pedro Osuna Alcalaya

Software Engineer
European Space Astronomy Center
(ESAC/ESA)
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 8131314

European Space Astronomy Center
European Space Agency
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN