SSAP clients for theoretical spectra

[Doug Tody]

Hi Petr -

POS should not be a problem with SSA (or other future DAL interfaces
as currently planned); POS queries are no longer required.  While the
service *is* required to support POS, TIME, BAND, the client is *not*
required to use these parameters in a query, and can query on other
parameters if the service supports it.

TARGETNAME can be useful for queries, but for theory data such as
you describe the problem will be lack of standardization.  Little has
been done as yet to standardize queries for theory data.  Specifying
the parameters of the model, and dynamically generating or selecting
pregenerated data is a pretty good start though.

> (The only problem is last sentence of 4.1.2.8 : "if both TARGETNAME and POS
> are specified, both must satisfy the query for a candidate object to be
> matched" - what positions should be given in my spectra of Sirius to satisfy
> the resolver in Simbad ?

You, the user, control the query.  If you specify both TARGETNAME and
POS, both have to be satisfied by the service, which is just doing
what you tell it to do.  If this is not what you want, specify only
one or the other, or increase the SIZE, and refine the query on the
client side with more sophisticated analysis.

	- Doug


On Mon, 15 Oct 2007, Petr Skoda wrote:

> 
> Hi all,
> 
> I think that the problem is not only with the theoretical spectra but the
> real spectra as well.
> 
> The problem I see is the POS - SSAP standard says that the POS is mandatory
> and should select something if asked (that means nothing for theoretical data)
> or the service returns everything if not POS given in query and other
> parameters should be used to constrain the query (SSAP chapter 4.1 last
> paragraph and 4.1.1)
> 
> The interesting parameter is the TARGETNAME (4.1.2.8) :
> the original intention is for asteroids and similar objects:
> it is said that for service providing spectra of moving objects the TARGETNAME
> is required.
> 
> As far as I have seen the results of synthetic spectra codes, people usually
> name the output spectrum as a joined string of used parameters
> Temperature, logg, rotational broadening , or electron density, radiation
> dillution ... , radiation temperature ... for planetary nebulae ...
> plus some chemical composition if not solar .
> 
> of course the metadata is required to tell everything about given model,
> but I think the 90% of queries in any research  go to Kurucz models
> named just 10xlogg+Teff   and some additional letter for different metalicity.
> 
> So I can imagine the situation where different models will be named by unique
> name expressing that parameters and the SSA query could use the TARGETNAME to
> query them directly without metadata. This will aloow already working SSA
> clients to overplot the theoretical spectra over observed immediately.
> 
> the question is what POS value should be returned for such a services that are
> "positionless".  In ancient times were the unusable values marked by series of
> 9   (e.g. 99999)  -
> so we could have some unphysical position  like -1,-1 or 999,999 to return.
> 
> of course, it does not solve the problem of TSAP - I have to known how the
> service name his "hypothetical stars" - but it can given e.g. in provenance.
> But its a way how to start publishing of calculated spectra JUST NOW to allow
> some analysis already done with VO tools than to wait for new TSAP compatible
> clients ...
> 
> The problem I see for regular spectra - even for stars is that POS vs.
> TARGETNAME - We already have met several times the situation where the query
> by position is misleading and the identification of the star must be done by
> its name.
> 
> E.g. the cordinates returned by telescope to the data FITS header are not
> precise enough (flexures of tube, errors in encoders, axis flexures ... -all
> the stuff thta TPOINT tries to correct) to be able to distinquish components
> of close binary on slit (only the spectrum will tell which is which), or the
> Simbad resolver makes troubles as the data in simbad are wrong (we have met
> e.g mess in description of HR1847 in literature and SIMBAD, as the component A
> and B according to description of spectra seem to be swapped with respect to
> position, but its difficult to tell that for sure, as both spectra are
> changing.....)
> 
> I just wanted point out that the position is not justifying unique
> identificator even for distant objects. Another example is the Sirius
> (there is a spectrum of Sirius B and A - how do you use position in searching
> the archives ?  (in Simbad is Sirius B: ICRS: 101.287 -16.718
> while Sirius A ICRS is: 101.2871554 -16.7161158 - notice the precission
> difference !)
> 
> So to summarize: the TARGETNAME is a good way of querying not only theoretical
> spectra and asteroids but normal stars as well and should be supported if
> needed by the services .
> 
> (The only problem is last sentence of 4.1.2.8 : "if both TARGETNAME and POS
> are specified, both must satisfy the query for a candidate object to be
> matched" - what positions should be given in my spectra of Sirius to satisfy
> the resolver in Simbad ?
> )
> 
> 
> 
> > The problem is I think that clients are in general not yet able to use this
> > information.
> 
> > I talked with Mark Allen about this somewhat over a week ago
> > and he suggested we post this question to the mailing lists to alert client
> > builders about this problem.
> 
> Yes - the query by TARGETNAME and METADATA should be implemented definetely in
> new client versions.
> 
> 
> 
> > examples where a particular, identified star is being simulated and could be
> > given positions !).
> 
> I agree - but is the computed spectrum of Vega the real star to bear the
> coordinates ? I would preffer to named this spectrum Vega_synth1 and query by
> its name .
> 
> 
> > In the end every SSA service should respond to format=metadata with the
> > parameters they support and clients should (eventually) make use of this
> > information to at least not send positional queries to services that do not
> > support them,
> or if it gets strange POS from service (e.g. 999,999) stop using POS and use
> information returned in different way.
> 
> 
> and once all metadata is there (getCapabilities will hopefully
> > use the requirements form this discussion)
> 
> > GUIs can be generated that
> > capture also more generic queries.
> 
> perfect - on the fly generation of menus with prelisted values of parameters
> is better than blindly hit the right parameters ranges
> (instead of asking the Teff and try 3000, no hit, 5550 - no hit...
> I will see in the (on-the-fly generated) menu that the Teff is only for 25000,
> 30000 and 40000 .....) on this service for hot stars ;-)
> 
> 
> Anyway the full metadata (getcapability) issue should be solved ASAP.
> 
> 
> 
> *************************************************************************
> *  Petr Skoda                         Phone : +420-323-649201, ext. 361 * *
> Stellar Department                         +420-323-620361           *
> *  Astronomical Institute AS CR       Fax   : +420-323-620250           *
> *  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
> *  Czech Republic                                                       *
> *************************************************************************
>