Delayed discussion on SimDM ...

[Miguel Cerviño]

Dear all,

I noticed that there was some discussion in the 1st theory session about the use of
empirical-based data as a theoretical result, which is a common practice in some 
theoretical works. I just want to explain the point more clear (see below)

Also, I just hear that there had been also some comments about the difficult of use the SimDM in a  VOTable.
I want also explain why I think a VOTable serialization is needed.

Finally I also want to comment some aspects related with population synthesis 
implementation in the VO, since I think that there was some discussion in the meeting.

[Note 1: I had tested the wiki pages and the mailing list but there is no info
about how the Interop is going on... Following Laurent request in the theory list, please, 
would you upload your ppt files in the wiki o send a e-mail summary to the theory list?

Note 2: Since I do not know the current status of the discussion I send the mail
to both theory and DM mailing lists]

cheers 

miguel



Comments:

1) Empirical based data:

Let me explain the point of use observational data as theoretical one in the following logic way:

1.a: A theoretical product can be understood as any kind of abstraction with a
theoretical background.

1.b: In a several cases,  theoretical research is the definition of classes of 
theoretical objects in a theoretical parameter space useful to address a 
specific problem. As an example, the definition of stellar classes as a 
function of Teff and log g (note that Teff  and log g are not observables). 

1.c A similar theoretical result is the definition of the representative elements
of the classes. Actually it is independent on how the "representative element of the class" is obtained.

[Points 1.a, 1.b and 1.c are just the typical theoretical abstraction about
modeling a cow like an "spherical cow", quite common and useful for
theoretical developments: use real word to make an abstract simple entities 
and work with them to solve specific problems]

In the case of atmosphere libraries, atmosphere codes can be run
to build up theoretical stars which model such stellar classes, or,
"promote"  observed stars as the definition of  given classes.

As and example, in the "theoretical space of classes"  an star HD 12345 
with log g=XX and Teff=XX is not longer HD 12345 but the 
REPRESENTATION (the model) of stars with log g=XX and
Teff=XX. A particular observed star has been promoted to the definition of a
given stellar class. Note that in this case there is no associated "code" to
make the promotion. It is just a theoretical (useful and most times valid) 
abstraction. (Several examples can be found in the literature, like
Pickles, MILES, StebLib, ELODI, Indo-US libraries etc which just aims
to cover "observationally" the theoretical parameter space of
log g, Teff and metallicity, or Kuzucz or Lejeune models that
do the same from theoretical codes).


In the data model should not be distinction between these two cases
(the aims is simillar, also the target, source etc) just differ in how they
have been assigned (a "technical" issue). 

Since both kinds of libraries are used in synthesis codes, Color-Magnitude Diagrams
etc, and, actually, represent "theoretical stars" (they are elements of a theoretical
defined class) both should be registered in a similar way isn't it? 


Similar use cases are related with theoretical codes that make use of any
template library as far a a "template" is a theoretical abstraction that represent
a class independently of how the association of the template and its class
has been assigned


2) VOTable - not VOTable

I am a bit afraid about the discussion about how difficult the data model can be serialized in a VOTable

2.a VOTable is just the VO standard to transfer data. I just understand the need of a datamodel
as a description of the data and it is the only way to assure interop: Applications read and produce VOTables
If SimDM cannot be serialized in VOTables, how an application can use the datamodel advantage?

2.b In a more subtle way, VOTables are not just produce in the VO environment. I can obtain a VOTable
from vizier with theoretical data (e.j. Padova isochrones), store them as VOTable in my computer
and use them later in an application like TopCat, Aladin etc...
The datamodel + VOTable scheme assures that all the relevant information to understand the data is 
stored with the data, so I can use it and no information is lost. As far as I understood it is one of the major 
goals of the VO...

2.c Most of service providers can be asked to make a VOTable implementation of their theoretical models, that means
to specify in a particular way (xml tags following a VOTable and a SimDM) the relevant information needed
to use their results, but I not sure if the services will make an SimDB (i.e. a DataBase) implementation if it not able
to describe the final data they provide.

I think that the VOTable serialization is fundamental for the SimDM to be used (and to test if there is any
relevant information lost)


3.- The synthesis model case.

I had not been in the discussion. I just give my experience in several meeting I had attended with developers and users
of synthesis models.

3.a) From the developer case, they are more interested in provide a characterization of their models (some of the items
provided by the SimDM like code, authors, products etc...) I had been able to convince some of them that, with a DM they just need to "include" a header in their files that can be obtained easily if they know the fields the must fulfil. In fact most of the relevant information is yet in ascii files, as comments in their files, or code in the file names.
In addition, for the case of theoretical spectra, I convince them that this DM can be used together with the spectra DM for a full description of their product.

3.b) From the user point of view, users are more worried to use synthesis models results as templates for some physical conditions, so they just test the "headers" to combine compatible models according their needs (i.e. VOTable tags related with the DM) and, for particular user cases related with spectra, they use the spectra DM to obtain the characterization of the spectra.


From the comments I had hear from the discussion in Nara, it looks that it is not the idea? Or that it is not
compatible with this Data Model. Now I am not completely sure that the strategy I had followed
to convince them to make a VO implementation of their models  is the correct one or if I must change my approach
to talk with developers and users...


I strongly acknowledge some feedback about this IN THE theory LIST, please (I am not in Nara!!! and I 
assume that there is more people in the list interested about this ;)


cheers and nice sushi :)