Spectra DM for theoretical spectra?

[Carlos Rodrigo Blanco]

Ok

I think it's perfectly explained (thank you).

So we are talking about provenance. All right.

Thus, I will study the work that is being doing about the provenance data 
model. So far, knowing that "this is a question about provenance" doesn't 
help me to tackle the problem of how knowing if what is called Teff for 
one model is the same "thing" than what is called "T" fo other model.
(and for me this problem is almost exactly the same one as knowing if two 
observed spectra correspond to the same "point" in sky)

The summary would be:

- This is not part of the spectrumDM. 
- The provenance DM (where it seems to belong conceptually) does not 
consider these kind of information right now and it is difficult because, 
in real life, each model will use different parameters.
- It is not either the purpose of SimDB going to such detail level 
(although it could be extended, but should be discussed if it's worth to 
do so)

But, at the same time, we are told that the case of theoretical spectra is 
already considered in SSAP (+SpectrumDM + ObsDM) and that we shouldn't 
discuss much about it...

I think that there is still quite a deal to discuss if we want to be able 
to use theoretical spectra in the VO properly.

Carlos

On Wed, 3 Jun 2009, Alberto Micol wrote:

> Carlos Rodrigo Blanco wrote:
>> 
>> All right, I see that I'm getting lost about some concepts and vocabulary 
>> in the vosphere... I'll try to catch up.
>> 
>> then I understand that the characterization DM aims to describe all the 
>> "characteristics" of an observation (WHAT is in the observation) and the 
>> provenance aims to describe the origin of the observation (HOW it was 
>> acquired, why, who, whatever)
> Sorry, again: CharDM is not about WHAT is observed/simulated, it only about 
> some properties on the data axes
> (position, coverage, resolution, sampling on the spatial, spectral, time, and 
> any other axis the data is subtending).
>> 
>> Then I agree that for a theoretical spectrum a (Teff,logg,metallicity) set 
>> is closer to be provenance that to the be characterization.
>> 
>> But I still don't see it IS either.
>> 
>> My question would be:
>> 
>> In SSAP an spectrum is identified by the position in sky of the 
>> corresponding object, that is, RA and DEC. Are they included in provenance? 
> It depends:
> - where the PI wanted to point the telescope is part of Provenance,
> - which part of the sky is actually subtended by the resulting data is in 
> CharDM.
> Subtle difference, but an important one.
> Ideally the two will coincide, but in real world there is a difference;
> the telescope points at a given (ra,dec) then the astrometric pipeline 
> corrects
> that information using some reference sources/catalogs. If there is no 
> astrometric correction
> then the two set of (ra,dec) values will coincide.
>
> Provenance describes the "a priori" knowledge (or will) of the PI,
> CharDM describes more the "a posteriori" knowledge of what happened
> during the observing process (including calibration pipeline).
>
> The archive/vo user who wants to analyse the data will generally care more
> about the "a posteriori" info (CharDM), though it is always good to know what 
> is that
> the PI actually wanted to do "a priori" (Provenance).
>
>> I undertand that what is included in provenance is more "the region of the 
>> sky that was observed by the astronomer was a rectangle with these four 
>> corners and it was observed this day with this instrument, etc". 
> No, that is in CharDM.
>> But the actual RA,DEC used by SSAP (POS parameter) are some coordinates 
>> associated to that spectrum and not really included in provenance. Am I 
>> right? (please, correct me if I'm wrong)
> That is up to CharDM, not provenance.
>> The point that I want to stress is that, for theoretical spectra (and, of 
>> course, from my point of view), the point (Teff,logg,metallicity) is the 
>> equivalent to (RA,DEC). They are the coordinates in some "parameter space" 
>> of the spectra, not (or not only) some description about how the spectrum 
>> was obtained.
>> 
> I see: you claim that the parameter space you want to "observe" is divided 
> into
> a grid of points in the (Teff, logg, Z) space, and your simulator will obtain 
> spectra
> for a number of those grid points. 
> This very much resembles what a Principal Investigator describes during Phase 
> 2
> of the proposal preparation at any observatory: all the things the 
> observatory must know
> to carry out the observation.  In this case the grid of points are in the 
> (ra,dec,wavelength,time, etc) space,
> and the observatory will obtain spectra/images for a number of those grid 
> points
> (e.g. a raster map observation to cover with various images a given part of 
> the sky).
>
> This to me qualifies as Provenance: it is about where to point the (virtual) 
> telescope, and with which camera settings.
> It is not about what was actually observed/simulated. It is "a priori" 
> knowledge, not "a posteriori".
>
>> What I see equivalent to my idea of provenance is "these theoretical 
>> spectra were calculated using kurucz code, calculating a grid with this 
>> edges and this step for each axe, considering rotation or not, considering 
>> the presence of a disk or not, etc".
>> 
> I agree, that is _also_ part of Provenance.
>> I don't really see clearly yet if this makes a difference or not and maybe 
>> the provenance data model is the perfect place to consider these things.
>> 
>> But, in Alberto's words, I don't see (teff,logg...) as the equivalent to 
>> instrument/telescope, but more the equivalent to data_axes (position,time) 
>> for observed spectra.
> I already answered to this above, but about data axes:
> Data axes are the axes of the resulting dataset.
> Given that the data is a spectrum, the axes are spatial, spectral, temporal, 
> and the observable (flux),
> and not Teff, logg, Z.
>
> Teff, logg, Z are the axes of the parameter space input (provenance) to your 
> simulator, not output (chardm).
>
> Alberto
>
>> 
>> Of course the problem with theoretical spectra is that the parameter space 
>> (the one used to identify an spectrum, the one used to search for spectra) 
>> is not allways the same because different developers. And that's a problem 
>> on its own (the one that started this conversation), either if we call it 
>> provenance or something else.
>> 
>> Carlos
>