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

[David Berry]

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
>