Access Protocol

[Carlos Rodrigo]

Hi Frank

Sorry for the delay. I should be on holidays in fact, although that's not exactly the case
because I'm too busy with several things and I cannot leave yet...

Going to the point:

> I sent you an email last week concerning one of your use cases that we
> would like to take into account in the development of the simulation
> access protocol.

First, just in case, I would like to comment briefly that there is already a proposed
protocol (S3, proposed and implemented years ago) that is quite useful to handle our "use
cases". Why not taking it into account, adding what you need to add, instead of considering
it just a "use case" and developing a new protocol almost from scratch?

Understand me. It's ok for me if you want to develop another protocol, because you think
that you need it and you prefer to do it your own way. I don't actually see the need for
having only one protocol and I don't feel any need to say that our ideas are better and
should be used by everyone.

And I appreciate that you want to consider as much use cases as possible.

It's just that it feels odd reading that you are preparing a new protocol so that we can
implement our use cases without any comment about the protocol that we are already using for
it and we proposed to the group years ago.

Now, let's go to the questions

>>
>> In your Victoria 2010 presentation :
>> http://www.ivoa.net/internal/IVOA/InterOpMay2010Applications/svo-vota-victoria10.pdf
>> we can find the "Granada Stellar Seismic Models" (page 5).
>>
>> If I understand well, the user
>> 1) select a code
>> 2) select some parameters for this code (that corresponds to input
>> parameters in a database or files)
>> (The "Structure search parameters")
>> 3) then select other parameters in the "Sismology search parameters"

In the implementation of the application accessing the models, it works mostly that way.
Only, the structure and seismology parameters are chosen together, not seismology after
structure. And other things can be done later.

You could maybe want to take a look also to my presentation about S3 int the Garching 2009
Interoperability meeting where I introduced some additions to S3 (summary, cutout) that are
used by the asteroseismology application:

http://www.ivoa.net/internal/IVOA/InterOpNov2009Theory/s3-garching09.pdf

>> My questions are :
>> * Does every steps correspond to pre-computed models or is there some
>> parts that corresponds to online code ?

Depends.

For some codes, most of the information is precomputed. But some of the most important query
parameters are not stored anywhere, they are calculated on the fly. For instance, one of the
important queries that must be done is of the type "I want models so that the great
separation in this range of frequencies is between 10 and 20", and that is not, and cannot
be, precomputed.

For some other codes it even happens that the authors prefer not storing anything (the
precomputed models are huge). Let's summarize it saying that for them the computing time is
cheaper that the storage price, so they prefer to compute the models on request and only
give a range of available parameters for which the model can be computed .

In any case it is important to separate what is the web application using the models and
what are the actual services providing the models. The services give the information. The
application uses the information to show it to the user, making graphs or whatever.

>> * Does the search always begin by a selection of code ?

In this implementation it is that way (maybe I found it easier in the moment to do it that
way for the prototype). But it shouldn't. The idea is being able to compare models and there
is no reason for having to choose a model first. The plan is reimplementing this so that the
user can work with several (or all) models at the same time.

>> * If both searches (Structure and sismology) corresponds to
>> pre-computed models, can we consider the sismology part as a
>> post-processing ?

I am not sure of understanding what post-processing means or implies.
In what respects to computing the models, I think that the seismology part takes the
structure as an input. Is that what you mean?

In terms of the use of the models, what happens is that a star has been observed and the
astronomer knows some properties of that star, both "structural" (lets say, mass,
temperature...) and seismic (oscillation frequencies in some range, great separation or
whatever) and he/she wants to study models that correspond to both things together. That
is: theoretical stars with those structural properties and oscillating that way.

>> Could you also precise the outputs provided by the service ?

do you want me to send you real votables?

>> * Are they all of the same kind and could be provided to the client in
>> a VO-Table ?
>> * Are they of different kind and require an interaction of the user to
>> determine what he wishes to get ?

there are several types of results and all of them can be given as votables by the
corresponding service:

- available structure models (codes)
- available seismic codes for a given structure model.
- available query parameters and available range of values for them (or some of them)
- summary of models, and their properties, available for a chosen range of parameters.
- list of models, and their properties, available for a chosen range of parameters.
- star structure for one model (shell variables)
- oscillation frequencies for one model
- give me only some properties of the star in some range of values.

In what respects to the user interaction... we again have to distinguish between the
application and the services. The application needs user interaction. The services provide
whatever they are queried for (so they need to be queried by someone, in this case: the
application). In some cases the application queries the services without previous user
interaction and in other ones it needs user inputs to know what to query about. In some
cases, for instance, the application has to do several queries to the service to fullfil a
given task required by the user...

For instance, to get a list (or summary) of models, the user fills the form saying what he
wants and the application queries the service accordingly. For doing the HR diagrams, the
application uses that information without querying the service again. But if the user wants
to make additional plots for some structure shell properties, the application queries the
service for what is needed.

I don't know if I have explained myself well. Do you need further details?

Carlos