Spectra DM for theoretical spectra?
bonnarel
bonnarel at alinda.u-strasbg.fr
Thu Jun 4 10:37:12 PDT 2009
Rick, all
I answer to this
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?
I think I can try to use simDB Characterization inside our Provenance
In the SSA response just create inside the Prov GROUP (see my example of
Yesterday another GROUP with utype
"ssa2:prov.simulation/simdb:experiment/Characterization" and containing such
Fields
<FIELD ID="CharacAxis" name="Characterization Axis" utype="
ssa2:prov.simulation/simdb:experiment/Characterization.axis;Property.ucd"
datatype="char" arraysize="*" /> ---> here the value will be "Ucd for Mass
Resolution"
<FIELD ID="CharacMin" name="Characterization Min" utype="
ssa2:prov.simulation/simdb:experiment/Characterization.type;CharacType.min"
datatype="float" /> ---> with your preferred value in solar Mass
<FIELD ID="CharacMax" name="Characterization Max" utype="
ssa2:prov.simulation/simdb:experiment/Characterization.type;CharacType.max"
datatype="float" /> ----> maximum mass resolution if this make sense
With IVOA Char replacing SimDB charac utypes it will be more something like
this (in the same GROUP)
<FIELD ID="CharacAxis" name="Characterization Axis" utype="
ssa2:prov.simulation/simdb:experiment/cha:CharacterizationAxis.ucd"
datatype="char" arraysize="*" /> ---> here the value will be "Ucd for Mass"
<FIELD ID="CharacAxisUnit" name="Characterization Axis" utype="
ssa2:prov.simulation/simdb:experiment/cha:CharacterizationAxis.unit"
datatype="char" arraysize="*" /> ---> here the value will be "Unit for solar
Mass"
<FIELD ID="CharacMin" name="Characterization Min" utype="
ssa2:prov.simulation/simdb:experiment/cha:Characterization.resolution.Resolu
tionBounds.resolutionLimits.LowLim" datatype="float" /> ---> with your
preferred value in solar Mass
<FIELD ID="CharacMax" name="Characterization Max" utype="
ssa2:prov.simulation/simdb:experiment/cha:Characterization.resolution.Resolu
tionBounds.resolutionLimits.HiLim" datatype="float" /> ----> maximum mass
resolution if this make sense
What do you think ?
François
-----Message d'origine-----
De : Rick Wagner [mailto:rwagner at physics.ucsd.edu]
Envoyé : jeudi 4 juin 2009 07:39
À : bonnarel
Cc : 'Carlos Rodrigo Blanco'; 'Gerard'; 'Alberto Micol'; theory at ivoa.net;
dm at ivoa.net
Objet : Re: Spectra DM for theoretical spectra?
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
>>
>>
>>
>>
>
>
More information about the theory
mailing list