Hi,
On Fri, 15 Jul 2005, Andrea Preite Martinez wrote:
>
> > 1. we propose to remove all the words containing an explicit
> > specification of the wavelength or frequency range...
> > 2. we propose to substitute "instr.${band}" for all words of the type
> > "em.${band}". Rationale: the sensitive bandpass is a property of the
> > detector
>
> This has been a problem since the very beginning of the ucd's history. The
> pros and cons of different possible solutions were carefully considered,
> and at the end it was decided to consider that <em> words were only a way
> to describe the wl/freq axis, NOT the properties of an instrument, and that
> the spelling was only mnemonic.
> The job of assigning the right em-word to a point or interval on that axis
> is done by a script, who takes care of units, band codes, intervals,
> difference of intervals (i.e.: colours in astronomy), so that, for example:
>
> 2.456mm is translated into em.mm.100-200GHz
> L em.IR.3-4um
> 0.1eV em.IR.8-15um
> 0.001nm em.gamma.hard
> V-N em.opt.V;em.IR.8-15um , and even
> F439W em.opt.B
>
> (Warning: the on-line script needs a quantity to assign an ucd. em-words are
> not, so add mag/flux... to your wl/freq/energy to get an answer)
>
Fine!
How are you planing to deal with E230M, F28x50LP, F25CN2700 "filters" or
GRISM? (these are standard optical elements in HST/STIS or ACS)
> > 3. we propose to add the words "em.wl.start" and "em.wl.stop".
> > Rationale: they may be useful and flexible characterizations of the
> > bandpass
>
> In many cases I found a data/column description saying: beginning/minimum
> wl, ending/maximum wl, that I translated using stat.min, stat.max. On the
> other hand, beginning/ending of observation/exposure deserved wholly new
> ucd-words! So I'm in favour of introducing these concepts, but as generic
> qualifiers that can be applied to any axis (time, wl, freq, ..)
>
Fine!
> > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing".
> > Rationale: this is a property of an observation rather than of an instrument
>
> I whould say seeing is a property of a <site>.
> I also agree with Rick's suggestion, it's a property of the <weather> at a
> given site.
Fine. Should there also be some UCD for transparency?
>
> > 5. we propose to unify "instr.beam" and "instr.det.psf" into
> > "instr.psf"...
> > 6. we propose to remove "instr.precision". Rationale: too generic,
> > probably useless
>
> A good occasion to repeat that the list of words was initially built
> entirely bottom-up, i.e. from data description. If "instr.precision"
> exists, it means that the description "precision", although too generic,
> has been used by some author.
>
Could you ask the author what did he mean?
> > 7. we propose to add the following radio-related words:
> > "instr.interferometry", and "instr.resolution". Rationale: the former is
> > self-explaining; the latter indicates the spatial resolution
>
> The former can be one of the many <non-quantities> with syntax-flag S.
> As for the latter, at present:
> instrument resolution => pos.resolution
> image resolution => pos.resolution;obs.image
> spatial resolution => pos.resolution
>
> > 8. we propose to change the word code of "instr.filter.transm" and
> > "instr.spect.resolution" to "V". Rationale: the filter transmission is
> > an intrinsically vectorial quantity; the spectral resolution as well
> > (dependence on energy and/or order)
>
> The V-flag indicates a vector in <ordinary> space
>
At the very first AVO meeting organized by Piero in Garching there was a long discussion about this issue. To fully understand the meaning of an image obtained with a given filter you need the Transmittance function of the filter ( T(lambda) ). Unless you force all the observatories to use exactly the same filters and qualify them, specifying the transmittance function is the easiest way to qualify them and allow proper comparisons between observations obtained with different instruments. Are "functions" allowed as UCDs
> > 9. we propose to add a further atom to the "Multiplicity of binarity
> > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale:
> > self-explaining
>
> I think that <meta.code.multip> is tolerable because it's sufficiently
> generic, and because it is used.
In the coming years, planets are going to be searched for in basically all stars around. There will be searched for not only on "single" star systems but on multiple systems. How are you planing to classify them?
>
> > 10. we propose to add a further "meta" atom: "meta.subexp"...
> > 11. we propose to add a further "meta" atom: "meta.rank"...
>
HST is divides the exposure time into subexposures. For each sub-exposure an "image" is produced and archived within a single "archive record" that corresponds to the "exposure". In rapidly variable objects, it is relevant to make use of the "sub-exposures". If you wish to see a direct application where this relevance is oustanding take a glance to Gomez de Castro, 2002 (MNRAS). The target is AB Dor and the spectra where obtained with HST/HRS.
> I need a use-case to make-up my mind
>
> > 12. we propose to move "xxx" to "src.xxx"
> > 13. as above
> > 14. as above
> > 20. as above
> > 24. as above
I think that they are self-explanatory
>
> In doing this, I think we would narrow the meaning of those words.
>
Why?
> > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis
> > angle may be a useful quantity is some catalogs
> I agree.
>
> > 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under
> > the "obs" category. Rationale: these quantity belongs logically to an
> > observation, not to (the position of) a source
>
> I can assure you that pos.earth means position ON the earth, not source
> position on some earth-based coordinate frame!!
Then, why are them within the "pos" category? I thought that "pos" is related with "source" and "obs" with the observation/observatory. Doesn't it look more natural, obs.pos.earth.lat?
>
> > 18. "pos.earth.nutation" should be removed. Rationale: it is no longer
> > consistent with the IAU specification
> Changed.
>
> > 21. we propose to add "src.stellarityIndex". Rationale: it may be useful
> > to easily discriminate point-like from extended sources
>
> A word with the description ?stellarity index? already exists.
>
> > 22. we propose to add the following words in the "stat" category...
> > 23.
>
> Yes, I think a revision of the "stat" category is probably necessary.
>
> > 25. we propose to add the following word: "time.deadtime". Rationale:
> > useful for photon-counting devices based catalogues
> I agree.
>
> > An additional point that we have discussed concerns the units in which
> > interferometric data shall be provided...
Matteo and I were dicussing about how interferometric data were going to be provided to VO's from the observatories. Interferometric data are basically images in the "Fourier space" and not in the "physical space". During the AVO experience, Joddrell Bank provided directly "physical images" since they carried out the Inverse Fourier Tranform before given access to the data through the web. So, our question is a generic issue.
Interferometric data are going to become more and more common in Astronomy. The "measuring space" of interferometric data is the "Fourier- I mean , space frequencies - space". Are the interferometric data providers going to release their products in the "physical" or in the "Fourier" space? Has this issue be discussed?, has been discussed how does it affect UCD's?
Finally, I've kept thinking about UCD's for "simulations" and this is very tricky. As important as the method, resolution, time-scales etcc. is to describe the boundary and the initial conditions. I still wonder how!!!
Cheers,
Ana
Prof. Ana I. Gomez de Castro
Instituto de Astronomia y Geodesia (CSIC-UCM)
Fac. de CC Matematicas
Universidad Complutense de Madrid
28040 Madrid, Spain
Ph. 34-913944578 (office) 34-659783338 (mobile) Email: aig-at-mat.ucm.es Received on 2005-07-15Z17:16:19