Spectra DM for theoretical spectra?

[Rick Wagner]

Good Morning,

Thank you for this Francois! While the use of multiple utypes in the  
utype attribute raises some concern, at least we our data model  
showing up. And multiple VOTable PARAMETER groups could be used to  
link the names and description of simulation input parameters with  
the parameter settings used.

However, I'm a little concerned with the focus of the discussion on  
how to model synthetic observations. I think it is important to  
clearly make the point that the SimDB model is intended to be able to  
describe simulations that never produce an image or spectra. And even  
simulations which do produce simulated observational data, often come  
at the end of a long chain of other simulations.

Let me give you an example, for data which already exists, that could  
be published using an SIA service. One of our recent projects focused  
on the effect of confusion in measurements of the Sunyaev-Zel'dovich  
Effect. The final data used for analysis were simple projections of  
the Compton parameter. These images could easily be characterized  
using the CharDM, since they have a minimum and maximum values,  
angular resolution, etc. And, if they ever do find their way into a  
service, I will describe them using an SIA data model (if it exists).

But what about the field of galaxy clusters in the image? The  
simulation data from which the images were made had a physical size  
of 512 Mpc comoving, and contained many thousand galaxy clusters. A  
simple description of the mass range (min, max, mean, average, etc.)  
of these clusters would be very useful.

With the current Provenance and Characterization models, how can I  
state that the images came from a simulation that contained galaxy  
clusters, and that the clusters had a minimum mass resolution of 1E9  
solar masses? And, can users easily search for simulations with  
galaxy cluster with a given mass resolution?  A key difference (I  
believe) between this characterization, and that of observation, is  
that we are applying it to simulated objects in the data, rather than  
the values of the data. I agree with an earlier comment by Francois  
that an axis, such as M_vir, could be defined, but how do I relate it  
to the galaxy clusters we intended to produce?

According to Albert, our desire to simulate galaxy clusters falls  
into Provenance, and the measured properties of the clusters falls  
under Characterization. This seems reasonable, but I don't know if  
this requires an explicit dependence of the SimDB data model on the  
Observational Provenance and Characterization models. Nor do I think  
an observationally motivated provenance model would be sufficient for  
describing the goals of a simulation both generally, and in detail.

Those are my thoughts (for now). Hopefully, I will wake up tomorrow  
to an amicable resolution, and no further grammatical errors on my part.

--Rick

On Jun 3, 2009, at 9:33 AM, bonnarel wrote:

>
> Hi all
>    Here the same information "a la SSA with simple extension"
>
> Directly inspired from Gerard s example.
> Consistent with SSA structure and current status of Prov
> The only trick is to use the ucd attribute to give the parameter  
> element
> value in parameterSettingsm while the value element value is given  
> in the
> <TD>.
>
> Cheers
> Francois
>
> <TABLE>
> <FIELD ID="AcRef" name="AcRef" datatype="char" ucd="meta.ref.url"
> utype="ssa:Access.Reference" arraysize="*">
> <DESCRIPTION>URL used to access dataset</DESCRIPTION>
> </FIELD>
> <FIELD ID="Format" name="Format" datatype="char"  
> utype="ssa:Access.Format"
> arraysize="*">
> <DESCRIPTION>Content or MIME type of dataset</DESCRIPTION>
> </FIELD>
> <FIELD ID="DatasetSize" name="DatasetSize" datatype="long"
> utype="ssa:Access.Size" unit="bytes">
> <DESCRIPTION>Estimated dataset size</DESCRIPTION>
> </FIELD>
> <FIELD ID="DataLength" name="DataLength" datatype="long"
> utype="ssa:Dataset.Length">
> <DESCRIPTION>Number of points</DESCRIPTION>
> </FIELD>
>
> <FIELD ID="SpectralAxisUcd" name="SpectralAxisUcd" datatype="char"
> utype="ssa:Char.SpectralAxis.Ucd" arraysize="*">
> <DESCRIPTION>UCD for spectral coord</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralLocation" name="SpectralLocation" datatype="double"
> ucd="instr.bandpass"  
> utype="ssa:Char.SpectralAxis.Coverage.Location.Value"
> unit="m">
> <DESCRIPTION>Spectral coord value</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralExtent" name="SpectralExtent" datatype="double"
> ucd="instr.bandwidth"  
> utype="ssa:Char.SpectralAxis.Coverage.Bounds.Extent"
> unit="m">
> <DESCRIPTION>Width of spectrum</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralStart" name="SpectralStart" datatype="double"
> ucd="em;stat.min" utype="ssa:Char.SpectralAxis.Coverage.Bounds.Start"
> unit="m">
> <DESCRIPTION>Start in spectral coordinate</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralStop" name="SpectralStop" datatype="double"
> ucd="em;stat.max" utype="ssa:Char.SpectralAxis.Coverage.Bounds.Stop"
> unit="m">
> <DESCRIPTION>Stop in spectral coordinate</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralFill" name="SpectralFill" datatype="float"
> ucd="stat.fill;em"  
> utype="ssa:Char.SpectralAxis.Coverage.Support.Fill">
> <DESCRIPTION>Spectral sampling filling factor</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralBinSize" name="SpectralBinSize" datatype="double"
> ucd="em;spec.binSize" utype="ssa:Char.SpectralAxis.Accuracy.BinSize"
> unit="m">
> <DESCRIPTION>Spectral coord bin size</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralStatError" name="SpectralStatError"  
> datatype="double"
> ucd="em;stat.error" utype="ssa:Char.SpectralAxis.Accuracy.StatError"
> unit="m">
> <DESCRIPTION>Spectral coord statistical error</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralSysError" name="SpectralSysError" datatype="double"
> ucd="em;stat.error" utype="ssa:Char.SpectralAxis.Accuracy.SysError"
> unit="m">
> <DESCRIPTION>Spectral coord systematic error</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralCalibration" name="SpectralCalibration"  
> datatype="char"
> ucd="meta.code.qual"  
> utype="ssa:Char.SpectralAxis.Accuracy.Calibration"
> arraysize="*" unit="m">
> <DESCRIPTION>Type of spectral coord calibration</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralResolution" name="SpectralResolution"  
> datatype="double"
> ucd="spect.resolution" utype="ssa:Char.SpectralAxis.Resolution"  
> unit="m">
> <DESCRIPTION>Spectral resolution FWHM</DESCRIPTION>
> </FIELD>
> <FIELD ID="SpectralResPower" name="SpectralResPower" datatype="float"
> ucd="spect.resolution" utype="ssa:Char.SpectralAxis.ResPower">
> <DESCRIPTION>Spectral resolving power</DESCRIPTION>
> </FIELD>
>
> <FIELD ID="FluxAxisUcd" name="FluxAxisUcd" datatype="char"
> utype="ssa:Char.FluxAxis.Ucd" arraysize="*">
> <DESCRIPTION>UCD for flux</DESCRIPTION>
> </FIELD>
> <FIELD ID="FluxStatError" name="FluxStatError" datatype="double"
> ucd="phot.flux;stat.error"  
> utype="ssa:Char.FluxAxis.Accuracy.StatError">
> <DESCRIPTION>Flux statistical error</DESCRIPTION>
> </FIELD>
> <FIELD ID="FluxSysError" name="FluxSysError" datatype="double"
> ucd="phot.flux;stat.error.sys"  
> utype="ssa:Char.FluxAxis.Accuracy.SysError">
> <DESCRIPTION>Flux systematic error</DESCRIPTION>
> </FIELD>
> <FIELD ID="FluxCalibration" name="FluxCalibration" datatype="char"
> utype="ssa:Char.FluxAxis.Accuracy.Calibration" arraysize="*">
> <DESCRIPTION>Type of flux calibration</DESCRIPTION>
> </FIELD>
>
> <FIELD ID="ProcessTyp" name="Processing Type" datatype="char"
> utype="ssa2:prov.processing.type" >
> <DESCRIPTION> Processing Type ---> value will be simulation</ 
> DESCRIPTION>
> </FIELD>
> <FIELD ID="SimulName" name="Code Name" datatype="char"
> utype="ssa2:prov.processing.simulation/simdb:simulator.name" >
> <DESCRIPTION> Input Parameters ---> value will be Kurucz </ 
> DESCRIPTION>
> </FIELD
> <FIELD ID="SimulInParam" name="Input Parameters" datatype="char"
> utype="ssa2:prov.processing.simulation/simdb:simulator.inputParams" >
> <DESCRIPTION> Input Parameters ---> value will be Teff, Logg, etc
> ...</DESCRIPTION>
> </FIELD>
> <FIELD ID="SimulSettings1" name="Input Parameters" datatype="float"
> ucd="ucd for Teff" utype="ssa2:prov.processing.simulation/
> simdb:simulator.parametterSetting.parameter" >
> <DESCRIPTION> Teff ---> value will be 1234 etc ...</DESCRIPTION>
> </FIELD>
> <FIELD ID="SimulSettings2" name="Input Parameters" datatype="float"
> ucd="ucd for Logg" utype="ssa2:prov.processing.simulation/
> simdb:simulator.parametterSetting.parameter" >
> <DESCRIPTION> Logg ---> value will be 1.3 etc ...</DESCRIPTION>
> </FIELD>
>
> <GROUP ID="Access" name="Access" utype="ssa:Access">
> <DESCRIPTION>Access Metadata</DESCRIPTION>
> <FIELDref ref="AcRef"/>
> <FIELDref ref="Format"/>
> <FIELDref ref="DatasetSize"/>
> </GROUP>
> < <GROUP ID="Char.SpectralAxis" name="Char.SpectralAxis"
> utype="ssa:Char.SpectralAxis">
> <DESCRIPTION>Spectral Axis Characterization</DESCRIPTION>
> <FIELDref ref="SpectralAxisUcd"/>
> <FIELDref ref="SpectralLocation"/>
> <FIELDref ref="SpectralExtent"/>
> <FIELDref ref="SpectralStart"/>
> <FIELDref ref="SpectralStop"/>
> <FIELDref ref="SpectralFill"/>
> <FIELDref ref="SpectralBinSize"/>
> <FIELDref ref="SpectralStatError"/>
> <FIELDref ref="SpectralSysError"/>
> <FIELDref ref="SpectralCalibration"/>
> <FIELDref ref="SpectralResolution"/>
> <FIELDref ref="SpectralResPower"/>
> </GROUP>
> <GROUP ID="Char.FluxAxis" name="Char.FluxAxis"  
> utype="ssa:Char.FluxAxis">
> <DESCRIPTION>Flux Axis Characterization</DESCRIPTION>
> <FIELDref ref="FluxAxisUcd"/>
> <FIELDref ref="FluxStatError"/>
> <FIELDref ref="FluxSysError"/>
> <FIELDref ref="FluxCalibration"/>
> </GROUP>
>
> <GROUP ID="Provenance" name="Char.Provenance" utype="ssa2:prov">
> <FIELDref ref="ProcessType"/>
> <FIELDref ref="SimulName"/>
> <FIELDref ref="SimulInParam"/>
> <FIELDref ref="SimulationSetting1"/>
> <FIELDref ref="SimulationSetting2"/>
> </GROUP>
>
> -----Message d'origine-----
> De : Carlos Rodrigo Blanco [mailto:crb at laeff.inta.es]
> Envoyé : mercredi 3 juin 2009 16:54
> À : Gerard
> Cc : 'bonnarel'; 'Alberto Micol'; theory at ivoa.net; dm at ivoa.net
> Objet : RE: Spectra DM for theoretical spectra?
>
> So nice that you give an example! thanks for it :-)
>
> And no, it doesn't seem difficult.
>
> The problem here is that there is not a way to know, a priori, if the
> first parameter of simulator1 has the same meaning or a completely
> different one than the first parameter of simulator2.
>
> (That's not a problem of SimDB, I have it too in S3, for instance)
>
> You can do that mach using the same <label>s pointing to some
> existing vocabulary using it as a reference. Actually that vocabulary
> seems to be what is needed wether or not it is used from inside  
> SimDB or
> some other way.
>
> (and I'm sorry if I'm using the word "vocabulary" in a loosy way ;)
>
>
> On Wed, 3 Jun 2009, Gerard wrote:
>
>> Hi Carlos
>>
>>>
>>> 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)
>>>
>>
>> All of this can be modelled in SimDB, using the  
>> SimDB:InputParameter and
>> SimDB:ParameterSetting classes.
>>
>> In XML you could describe this somewhat like the following (and  
>> let's not
>> argue about the term <simulator>
>> which you might prefer to be <model> or who knows what)
>>
>> First you describe your simulation code (model code):
>>
>> <simulator>
>> <name>My favorite stellar model</name>
>> ...
>> <inputParameter>
>> <name>Teff</name>
>> <description>effective temperature of the star</description>
>> <label>Some term from a semantic vocabulary that allows one to  
>> indicate
>> physical concepts and observables.</label>
>> </inputParameter>
>>
>> <inputParameter>
>> <name>Logg</name>
>> <description>logarithm of the gravity</description>
>> <label>Some other term from a semantic vocabulary that allows one to
>> indicate physical concepts and observables.</label>
>> </inputParameter>
>>
>> <inputParameter>
>> <name>Metallicity</name>
>> <description>fraction of elements heavier than Hidrogen </ 
>> description>
>> <label>Some other term from a semantic vocabulary that allows one to
>> indicate physical concepts and observables.</label>
>> </inputParameter>
>>
>> </simulator>
>>
>> This has to be defined only once, and now all runs (models?) can  
>> refer to
>> this code and list parameter settings:
>>
>> <simulation>
>>  <simulator>My favorite stellar model</simulator>
>>  <parameterSetting>
>>    <parameter>Teff</parameter>
>>    <value>1234</value>
>>  </parameterSetting>
>> ...
>> </simulation>
>>
>>
>> Now one may argue that this is not as explicit as for example
>>
>> <MyFavoriteModel>
>> <Teff>1234</Teff>
>> <Logg>1</Logg>
>> </MyFavoriteModel>
>>
>>
>> But that model ONLY works for MyFavoriteModel, whereas the SimDB  
>> version
>> works for all models that have input parameters.
>> Moreover, the simulation code itself is explicitly described in  
>> the model
>> itself.
>> I don't think this is very difficult?
>>
>> It may be possible for a selected sub discipline to define an  
>> explicit set
>> of parameters for which "nothing
>> can be done without them". Possbily stellar atmospheres,  
>> evolution. These
>> were actually singled out in last year's EuroVO DCA theory  
>> workshop and it
>> was suggested that they get together and try to define this kind of
> explicit
>> models.
>> There was interest amongst participating scientists to contribute  
>> to such
> an
>> effort. I can give names and email addresses if this is of interest.
>>
>> But note that this group is not defined because they produce  
>> synthetic
>> spectra.
>> But because they use similar types of models (or SimDB:Protocols in
>> SimDB-speak).
>>
>> For example people producing galaxy spectra will have a different  
>> opinion
>> about what input parametesr they can not do without.
>>
>>
>>
>>
>> Gerard
>>
>>
>>
>>
>
>