Spectra DM for theoretical spectra?

[Carlos Rodrigo Blanco]

Hi

I think that there is a minimum set given by:

Teff: effective temperature of the star
Logg: logarithm of the gravity
Metallicity (for some authors this is the fraction of elements heavier 
than Hidrogen and for other it is something different, I can ask for a 
better definition to some real astronomer :-)

Some models need more parameters, but this would be a nice start (those 
are the ones that I use for most of the services that I'm using).

In any case, I'm going to do a better list and I send it to you

Maybe other people need other parameters... for instance, recently some 
people from a group in France emailed me asking for a data 
model to describe their theoretical spectra in the VO and they sent me 
some quite complicated examples of what they were doing, I'll ask them 
too

(by the way, I would wish to keep this list simple, containing only those 
parameters so important that "nothing can be done without them", and then 
having the usual discussion on how that list can be extended or not and if 
something sofisticated is needed for the general case)

Thanks

Carlos

On Wed, 3 Jun 2009, bonnarel wrote:

>
> Let's try something Carlos...
>  Give me the exact list of attributes you want to describe a theoretical
> spectrum and we try to build an extension to SSA with appropriate "utypes
> proposal" to describe them ...
> Cheers
> François
> -----Message d'origine-----
> De : Carlos Rodrigo Blanco [mailto:crb at laeff.inta.es]
> Envoyé : mercredi 3 juin 2009 11:34
> À : Alberto Micol
> Cc : theory at ivoa.net; dm at ivoa.net
> Objet : Re: Spectra DM for theoretical spectra?
>
>
> 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)
>
> 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? 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". 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)
>
> 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.
>
> 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 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.
>
> 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
>
>  On Wed, 3 Jun 2009, Alberto Micol wrote:
>
>>
>> Rick Wagner wrote:
>>> 1) What we are calling Characterization in the simulation data model, is
>>> restricted to only provenance information. For example, the star
> formation
>>> rate or RMS Mach number may be represented, and these are physical
>>> properties measure from the data (in my cases).
>>
>> I'd like to stress what already mentioned by Francois: the importance of
>> using the correct vocabulary.
>> I take the example here above to illustrate the problem (sorry Rick,
> nothing
>> against you,
>> yours just happens to be the last email about this, see also Carlos'
> post):
>> in one sentence three different
>> concepts are used somewhat intermingled: Characterisation, Provenance, and
>
>> measured properties.
>>
>> Given that in the IVOA world (or 'vosphere' to take Sebastien's nice
>> expression) both Characterisation and  Provenance DMs
>> already exist (one already recommended, the other being worked out), I
> would
>> ask Theory to try to avoid any confusion
>> and not to use Characterisation what we are already used to call
> Provenance,
>> etc.
>>
>> I'm trying to depict the problem here, and later I'll make some
> suggestions
>> on the vocabulary
>> and on a possible way to solve the issue, that is, enabling a full
>> description of a theoretical spectrum.
>> Please bear with me... I need to clarify my terminology to get
> understood...
>>
>> Observation flow:
>> Real Universe --> Observation --> Telescope --> Data/Metadata -->
>> Measurements
>>
>> e.g.
>> input: a spectrum of star is observed by a camera and from it
>> output: the metallicity, log g, eff. temperature are obtained/measured;
>>
>>
>> Simulation flow:
>> in the Theoretical World, it is conceptually reversed, the "Measurements"
>> actually
>> become the Input parameters in a flow that looks very much reversed:
>>
>> Input parameters --> Virtual Telescope --> Simulation --> Modelled
> Universe
>>
>> e.g.
>> Input parameters are metallicity, log g, eff temperature
>> output: a modelled spectrum is obtained.
>>
>>
>> It is a reversed flow, it is like mathematically inverting a function:
>>  function(domain)  ->  image
>>  inverse function(image) -> domain
>>
>> the "image" of the function called "observing"
>> becomes the "domain" of the function called "simulating", and viceversa.
>>
>>
>> So far, CharDM, ProvenanceDM and SpectrumDM have focused their attention
> onto
>> the HOW,
>> and have intentionally avoided to describe the WHAT is observed.
>> It would be too difficult to describe anything that could be observed [a
>> star,
>> a galaxy, a cluster, a cloud, a bird, a girl (try to model it! ;-) ),
> etc.]
>>
>>
>> Maybe some confusion raises from the fact that the WHAT
>> of the real world becomes the Input parameters in the Simulated World
>> (e.g. the eff temp, the log g, the metallicity of a star).
>>
>> The distinction though is that in the Real World the WHAT is in the end a
>> measurement, an
>> estimate of the Truth, and hence has got an associated error, while in the
>
>> Theoretical World
>> the Input parameters _are_ the Truth (and error is virtually zero).
>> If TheoryWG comes up with a good set of models for the Input Parameters,
>> please bear in mind
>> the above, because the same model, with some care, could be re-used to
> model
>> the real world's WHAT!
>>
>>
>> Coming back to terminology/vocabulary:
>>
>> Carlos Rodrigo Blanco wrote:
>>> I'm not so sure that we are talking about provenance and not
>>> characterization.
>>>
>>> I feel that the sentence "description of a dataset or an observation in
> the
>>> Physical parameter space of the data" describes precisely what we are
>>> talking about.
>>>
>>> The physical n-dimensional space where a theoretical spectra is located
> is
>>> a space parametrized by some parameters as Teff, Logg, metallicity, etc.
>>>
>>> when I go to the characterization data model I read:
>>>
>>> ---
>>> This document defines the high level metadata necessary to describe the
>>> physical parameter space of observed or simulated astronomical data sets,
>
>>> such as 2D-images, data cubes, X-ray event lists, IFU data, etc..
>>
>> Characterisation DM: Care was taken *not* to describe "what" was
>> observed/simulated,
>> CharDM describes the N-dimensional space subtended by an
>> observation/simulation product
>> specifying which part of the N-dimensional space [whose axes are the
> _data_
>> axes: space, time,
>> wavelength...] was covered, with which sampling, and which resolution, all
> at
>> various levels of
>> detail (from an indicative number (location) down to finer details like
>> detector sensitivy,
>> transmission curve, etc).
>>
>>
>> The ProvenanceDM describes the process that resulted in an
>> observation/simulation
>> (e.g., among other things, the telescope/instrument configuration, but
> also
>> the PI program, etc.)
>>
>>
>> Rick Wagner wrote:
>>> However, there are some properties, such as resolution (spatial, or
>>> frequency) which are known beforehand. For this reason, there is a
> boolean
>>> "a priori" attribute on the Characterization class. This distinction may
>>> need to be made more clear, in order to align our model with the
>>> Characterization Data Model.
>>
>> The SpectrumDM combines a number of "How"DMs (CharDM, ProvenanceDM,
> Curation,
>> etc.)
>> though it allows some little digression into the realm of "Derived
>> Quantities", that is
>> quantities that are measured out of the described spectrum, and into the
>> realm of what
>> the PI already knows about the target ("a priori"). For example, for
>> REDSHIFT,
>> two different utypes and FITS keywords exist at this effect, one for the
> "a
>> priori" knowledge
>> one for the "a posteriori" measured quantity).
>>
>>
>> As many have already stated I also think that the Input parameters are the
>
>> equivalent
>> to the telescope/instrument settings, they are the Virtual Telescope
>> settings, and
>> as such the word Characterisation should strongly be avoided, in favour of
>
>> Provenance.
>>
>>
>> A possible recipe to solve the problem:
>>
>> Given the multitude of simulators that create spectra (stellar
> atmospheres,
>> galaxy clusters,
>> bl lacs, etc.) it is not possible to have one ProvenanceDM that covers
> them
>> all; I think
>> that each of those sets of Input Parameters should be modelled separately;
>> then it would be nice to enable ProvenanceDM to reference anyone of them;
>> similary SSAP (or its subset TSAP) could easily make use of all that.
>>
>> Sorry for the long email, but I think it is useful to clarify things
>> (and, viceversa, please clarify things that I might have gotten wrong)
>>
>> Alberto
>>
>