IVOA - Spectrum Data Model change request

[Vandana Desai]

Hello Petr and Mark and everyone!

Apologies for the delay in my reply.

Petr raised some very good points about two kinds of orders, and I am no
expert, so I reached out to a few people to get more detail on how we could
implement this in the specific case of Spitzer, in case it would be
illuminating for the more general case. Well, turns out it's complicated!
Petr, I am hoping you can comment on what follows:

For Spitzer Short High and Long High, the orders should be labeled
"absorder".

For Spitzer Long Low (LL) and Short Low (SL), the 1st and second orders for
each of SL and LL had physically distinct entrance apertures. I think that
means that what we have a habit of calling Spitzer Long Low order 2
could more accurately be called Spitzer Long Low aperture 2 order 1. I'm
not sure, then, if the LL and SL orders should be labeled "absorder" or
"difforder".

An additional complication is that order 3 for each of LL and SL is a
"bonus" order located above order 2 on the arrays, and is actually a
portion of order 1, imaged on a different piece of sky, not a third order.
So in this case, neither "absorder" nor "difforder" seem quite right. It's
kind of a mix of the two?

Petr also raised the question of which of the two order types a tool should
choose to plot if both are specified. In asking this question, the local
consensus is that the absolute order was far and away the preferred
default, because it has physical meaning. That leads me to wonder if the
two types of orders should be called "order" and "difforder".

I will send a separate reply about the upper and lower limits.

Thanks,
Vandana


On Fri, Oct 15, 2021 at 11:28 AM Petr Skoda <skoda at sunstel.asu.cas.cz>
wrote:

>
>
> Hi Mark, Vandana and all DM group,
>
> I would just like to remember once again (see the
>
> https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/IVOA_DAL_RM11_etherpad.txt
> search PS or
>
> https://wiki.ivoa.net/internal/IVOA/InterOpMay2021DAL/IVOA_May21_DALDM_etherpad.txt
> search  "Petr Skoda:")
>
> that we need add two 'order's (we are talking about echelle spectrograph
> as is also shown on Vandana's SPitzer IRS spectra in so called long-high
> (LH) Mode see e.g.
>
> https://irsa.ipac.caltech.edu/data/SPITZER/docs/irs/irsinstrumenthandbook/IRS_Instrument_Handbook.pdf
> page 9  (2.6)
>
>
>
>
>   One is relative - in fact depends how the pipeline on echelle reduction
> names the first extracted order - usually 1 an increasing as you go either
> towards red or blue ...(depends on orientation of the chip and
> cross-disperser .... all combinations are commonly use)
>
> and then the so called absolute order which is defined by construction and
> is stable for given instrument.
>
> It is an order (marked m in https://en.wikipedia.org/wiki/Blazed_grating)
> of difraction - given by the number of wavelengths of monochromatic light
> where the diffaction occurs in given geometrical (angles of rays
> incidence, reflection) and construction (spacing of grating grooves)
> conditions.
>
> I would suggest the name "absorder" or "difforder" or something similar in
> updated SDM.
>
> This order is used in reduction (can be used for checking the correct
> wavelength calibration etc) but usually is not transfered in the final
> product.
>
> In fact we still do not have proper standard for expressing echelle
> spectra and many final product attempt to merge many orders in one long
> spectrum (which is in principal bad idea bringing a LOT of problems) in
> order to pretend the echelle spectrum is a simple 1D  vector ....
> (e.g. all ESO archives of HARPS, FEROS etc ...)
> But as shown on SPITZER and many other properly curated echelle archives,
> there is a need for keeping the so called oder-by-order formats of echelle
> as well. It is important namely for precise RV of exoplanets ....
>
> So IMHO the Vandana's proposal (introducing order - or precisely 2 order
> types) is a hack that would allow at least to properly refer to given part
> of spectra (which allows for quick preview of given line profile on
> multiple spectra or study the proper data at the edges of the order. As
> most orders in properly designed echelle spectrographs overlap, the
> merging into one long  1D enforces some ad-hoc hacks like
> cutting part of each order and average / median the rest of overlapping
> part
>
> etc ...
>
> The question is how to recognize what order in visualizer to use if both
> are stated. IMHO the viewer should allow to switch this labeling or at
> least
> display somewhere that the order 1 is in fact 72 ..
> But of course the reference to the given collumn of a flux table will use
> relative orders (1 to ....)
>
>
>
>
>
> >
> > As I understand it, there are 2 main changes:
> >  1) add 'order' to the SpectralAxis data content
> >      The current model supports a single 1-D spectrum, and has no concept
> > of spectral order.
> >      So, even if the data were separated into separate Spectrum
> instances,
> > the 'order' information would be lost.
> >      This request would add a hook which would allow data containing
> > multiple spectral orders to be separated in application.
>
> or aggregated in application to display whole spectral range - if there
> are many single order 1D spectra in multiple files..
>
> (this is e.g. case of Be star database BeSS many files represent separate
> orders of the same echelle exposure)
>
>
> *************************************************************************
> *  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
> *  Stellar Department                         +420-323-620361           *
> *  Astronomical Institute CAS         Fax   : +420-323-620250           *
> *  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
> *  Czech Republic                             skoda at asu.cas.cz          *
> *************************************************************************
>


-- 
*Dr**. **Vandana* *Desai* | Caltech/IPAC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20211027/3b847590/attachment.html>