From mcs at iaa.es  Thu May  4 05:42:34 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 4 May 2006 14:42:34 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>

Dear all,

I just send this comments that may be discussed in the next meeting.
It is just a comparison about how different VO applications manage
a SED building following the SED data model requirements.
The applications compared are VOSpec, specview, topcat, and VOplot.
(Note that topcat and VOplot are general propose tools and VOSpec and
specview are specific for SEDs).

I had find that more or less the current SED data model is fine for  
theory,
and may be, model parameters should be specified in  <GROUP> ...</GROUP>
fields for characterization or provenance (it is an issue to be  
defined in
the theory group). Note that in the theoretical domain, the  
parameters that
define the model are equally relevant than the model results themselves.

However, for the case of applications, (visualization tools mainly) I  
had found some
inconsistence/problems with a VOTable designed in such a way, and  
also internal inconsistency
between different tools. I summarize them here:

a) problem with units nomenclature: There is no recommendation about  
the use of units in the VOTable
fields. In particular, VOSpec and specview use different ways to  
define the units for the flux
e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be  
possible to define any
recommendation about that? Otherwise the same VOTable would not be
used for both applications!

b) Metadata and saved files: As pointed before, metadata in  
theoretical models are fundamental to
understand and perform any posterior analysis or comparison with real  
data (or "pipeline" process
for datamining as example). Again, metadata are sometimes equal in  
importance than the simulation result. However:

   - the VOTable metadata are not visualized by VOSpec, sepcview and  
VOPlot
   - metadata otuside <GROUP> are visualized by Topcat, but not  
metadata in <GROUP>...</GROUP>
         (so may be the use of a <GROUP> for characterization of the  
model is not a good idea after all...)

About the VOTables that can be saved by VOSpec, specview and Topcat  
(VOPlot do not save VOTables)
it is found that metadata is systematically lost!! (it means, such  
type of applications are not completely suitable
to retrieve theoretical models thought the VO registry for their  
posterior use!). In particular:

   - specview: do not include niether the original VOTable  <GROUP>  
of <PARAM> but include their own
         <GROUP> and <PARAM>'s
  -  VOSpec  do not include the original metadata
  - and  VOTables saved by topcat include table metadata but
       all <GROUP> parameters are lost.


c) Columns to be plotted:

      c.1) specview needs 3 requirements to plot a VOTable:

        i.- the Table must have a name (only VOTables with <TABLE  
name="whatever"> looks to work
        ii.- utype in x and y coordinates in FIELD must be specified

       c.2) VOSpec needs two (non-standard) <PARAM...> lines to  
specify the columns and only
               two columns can be plotted (i.e. do not include for  
example a column with errors that would be
               useful for both observations and theoretical data.

   Finally, for theoretical SEDs, they are some times stored in a  
multicolumn format, I have not tested
with spectview, but it is not supported by VOSpec.

d) A final comment, it looks that only VOSpec is able to manage a  
Theoretical spectral acces protocol:
It means, perform the query to a server that gives back a table with  
the parameter space covered by the
models that the server provides, and perform a "second" query over a  
subsample of the parameter space covered.



I hope that this comments would help to improve the applications and  
for the theory group

best regards

	Miguel Cervi?o



From mcs at iaa.es  Thu May  4 05:42:34 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 4 May 2006 14:42:34 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>

Dear all,

I just send this comments that may be discussed in the next meeting.
It is just a comparison about how different VO applications manage
a SED building following the SED data model requirements.
The applications compared are VOSpec, specview, topcat, and VOplot.
(Note that topcat and VOplot are general propose tools and VOSpec and
specview are specific for SEDs).

I had find that more or less the current SED data model is fine for  
theory,
and may be, model parameters should be specified in  <GROUP> ...</GROUP>
fields for characterization or provenance (it is an issue to be  
defined in
the theory group). Note that in the theoretical domain, the  
parameters that
define the model are equally relevant than the model results themselves.

However, for the case of applications, (visualization tools mainly) I  
had found some
inconsistence/problems with a VOTable designed in such a way, and  
also internal inconsistency
between different tools. I summarize them here:

a) problem with units nomenclature: There is no recommendation about  
the use of units in the VOTable
fields. In particular, VOSpec and specview use different ways to  
define the units for the flux
e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be  
possible to define any
recommendation about that? Otherwise the same VOTable would not be
used for both applications!

b) Metadata and saved files: As pointed before, metadata in  
theoretical models are fundamental to
understand and perform any posterior analysis or comparison with real  
data (or "pipeline" process
for datamining as example). Again, metadata are sometimes equal in  
importance than the simulation result. However:

   - the VOTable metadata are not visualized by VOSpec, sepcview and  
VOPlot
   - metadata otuside <GROUP> are visualized by Topcat, but not  
metadata in <GROUP>...</GROUP>
         (so may be the use of a <GROUP> for characterization of the  
model is not a good idea after all...)

About the VOTables that can be saved by VOSpec, specview and Topcat  
(VOPlot do not save VOTables)
it is found that metadata is systematically lost!! (it means, such  
type of applications are not completely suitable
to retrieve theoretical models thought the VO registry for their  
posterior use!). In particular:

   - specview: do not include niether the original VOTable  <GROUP>  
of <PARAM> but include their own
         <GROUP> and <PARAM>'s
  -  VOSpec  do not include the original metadata
  - and  VOTables saved by topcat include table metadata but
       all <GROUP> parameters are lost.


c) Columns to be plotted:

      c.1) specview needs 3 requirements to plot a VOTable:

        i.- the Table must have a name (only VOTables with <TABLE  
name="whatever"> looks to work
        ii.- utype in x and y coordinates in FIELD must be specified

       c.2) VOSpec needs two (non-standard) <PARAM...> lines to  
specify the columns and only
               two columns can be plotted (i.e. do not include for  
example a column with errors that would be
               useful for both observations and theoretical data.

   Finally, for theoretical SEDs, they are some times stored in a  
multicolumn format, I have not tested
with spectview, but it is not supported by VOSpec.

d) A final comment, it looks that only VOSpec is able to manage a  
Theoretical spectral acces protocol:
It means, perform the query to a server that gives back a table with  
the parameter space covered by the
models that the server provides, and perform a "second" query over a  
subsample of the parameter space covered.



I hope that this comments would help to improve the applications and  
for the theory group

best regards

	Miguel Cervi?o



From boch at newb6.u-strasbg.fr  Thu May  4 06:18:38 2006
From: boch at newb6.u-strasbg.fr (Thomas Boch)
Date: Thu, 04 May 2006 15:18:38 +0200
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <4459FF2E.A38836FB@newb6.u-strasbg.fr>

Dear Miguel,

I'd like to comment your first point.

> 
> a) problem with units nomenclature: There is no recommendation about
> the use of units in the VOTable
> fields. In particular, VOSpec and specview use different ways to
> define the units for the flux
> e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be
> possible to define any
> recommendation about that? Otherwise the same VOTable would not be
> used for both applications!

Section 4.3 of the VOTable document (
http://www.ivoa.net/Documents/latest/VOT.html ) gives a reference (
http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) about how units should
be expressed.
According to this section, $cm^2$ should be defined in a VOTable field
as unit="cm2"

Cheers,

Thomas


From boch at newb6.u-strasbg.fr  Thu May  4 06:18:38 2006
From: boch at newb6.u-strasbg.fr (Thomas Boch)
Date: Thu, 04 May 2006 15:18:38 +0200
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <4459FF2E.A38836FB@newb6.u-strasbg.fr>

Dear Miguel,

I'd like to comment your first point.

> 
> a) problem with units nomenclature: There is no recommendation about
> the use of units in the VOTable
> fields. In particular, VOSpec and specview use different ways to
> define the units for the flux
> e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be
> possible to define any
> recommendation about that? Otherwise the same VOTable would not be
> used for both applications!

Section 4.3 of the VOTable document (
http://www.ivoa.net/Documents/latest/VOT.html ) gives a reference (
http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) about how units should
be expressed.
According to this section, $cm^2$ should be defined in a VOTable field
as unit="cm2"

Cheers,

Thomas


From rplante at ncsa.uiuc.edu  Thu May  4 08:57:04 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 10:57:04 -0500 (CDT)
Subject: How to Publish to the NVO
Message-ID: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>

Gentle Theorists,

During a recent chat, Sebastien Derriere reported on a meeting of 
VOTheorists in which there was some discussion of how one should publish 
simulation data and/or services to the VO.  I thought that I would mention 
a document I wrote for the NVO called "How to Publish to the NVO".  It's 
meant to be a brief introduction to VO publishing with pointers to how to 
get started.  It's a little out of date at the moment (an update is in the 
works), but it is not inaccurate.  I would be interested to get some 
feedback from your group about how applicable you feel it is to 
theory-related resources.  In particular, if you have suggestions for 
addressing the theory community, this would get a great time to get those.  

In the VO, we talk a lot about registering standard services like SIA and 
SkyNodes.  However you may not be aware that it is currently possible to 
register general data collections and non-standard services, including 
those that have a web-page interface.  While I'm sure that you will 
benefit from some standards that are specifically targetted to the theory 
community in the future, you may find the generic resource descriptions 
useful today.  In fact, I would encourage you to visit the registry at 
NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try registering 
somethings.  This site provides a sandbox version that allows you to try 
out the interface without actually publishing anything.  

Finally, to the Registry WG, it's been suggested that we take a look at 
this document and see if there is an IVOA version we might publish as a 
note.  Your feedback is welcome as well.  

cheers,
Ray



From rplante at ncsa.uiuc.edu  Thu May  4 08:57:04 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 10:57:04 -0500 (CDT)
Subject: How to Publish to the NVO
Message-ID: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>

Gentle Theorists,

During a recent chat, Sebastien Derriere reported on a meeting of 
VOTheorists in which there was some discussion of how one should publish 
simulation data and/or services to the VO.  I thought that I would mention 
a document I wrote for the NVO called "How to Publish to the NVO".  It's 
meant to be a brief introduction to VO publishing with pointers to how to 
get started.  It's a little out of date at the moment (an update is in the 
works), but it is not inaccurate.  I would be interested to get some 
feedback from your group about how applicable you feel it is to 
theory-related resources.  In particular, if you have suggestions for 
addressing the theory community, this would get a great time to get those.  

In the VO, we talk a lot about registering standard services like SIA and 
SkyNodes.  However you may not be aware that it is currently possible to 
register general data collections and non-standard services, including 
those that have a web-page interface.  While I'm sure that you will 
benefit from some standards that are specifically targetted to the theory 
community in the future, you may find the generic resource descriptions 
useful today.  In fact, I would encourage you to visit the registry at 
NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try registering 
somethings.  This site provides a sandbox version that allows you to try 
out the interface without actually publishing anything.  

Finally, to the Registry WG, it's been suggested that we take a look at 
this document and see if there is an IVOA version we might publish as a 
note.  Your feedback is welcome as well.  

cheers,
Ray



From rplante at ncsa.uiuc.edu  Thu May  4 09:16:32 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 11:16:32 -0500 (CDT)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0605041115420.5042-100000@poplar.ncsa.uiuc.edu>

On Thu, 4 May 2006, Ray Plante wrote:
> Gentle Theorists,
> 
> I thought that I would mention 
> a document I wrote for the NVO called "How to Publish to the NVO".  

I guess I should provide you with an actual pointer to the document, 
right?   http://us-vo.org/pubs/files/PublishHowTo.html

cheers,
Ray


From rplante at ncsa.uiuc.edu  Thu May  4 09:16:32 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 11:16:32 -0500 (CDT)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0605041115420.5042-100000@poplar.ncsa.uiuc.edu>

On Thu, 4 May 2006, Ray Plante wrote:
> Gentle Theorists,
> 
> I thought that I would mention 
> a document I wrote for the NVO called "How to Publish to the NVO".  

I guess I should provide you with an actual pointer to the document, 
right?   http://us-vo.org/pubs/files/PublishHowTo.html

cheers,
Ray


From m.b.taylor at bristol.ac.uk  Thu May  4 11:02:16 2006
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 4 May 2006 19:02:16 +0100 (BST)
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <Pine.LNX.4.44.0605041841590.31496-100000@andromeda.star.bris.ac.uk>

On Thu, 4 May 2006, Miguel Cervi?o wrote:

> Dear all,
> 
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> The applications compared are VOSpec, specview, topcat, and VOplot.
> (Note that topcat and VOplot are general propose tools and VOSpec and
> specview are specific for SEDs).

Miguel,

thanks for this posting.  This kind of detailed feedback on what
does and doesn't work, and what you want to see, is useful for 
application developers (well, I speak for myself in any case).

As you say, TOPCAT doesn't pay much attention to GROUP elements at
present.  I believe what it does is to behave as if GROUP elements
(though not their contents) are not there, so the grouping will be 
lost, but columns and parameters within the group will not.  
It also ignores table structure (for instance RESOURCEs within 
RESOURCEs) in a similar way.  Trying to do improve this kind of 
table metadata retention for VOTables is on the to-do list, 
but not currently very near the top (there are some technical 
difficulties which I will forbear to explain).  However, if it's 
something which the theory community (and others?) see as important 
I can see about prioritising it.  Ranking on the to-do list is 
influenced by user requests; I have had a few requests for this 
in the past but not that many.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



From m.b.taylor at bristol.ac.uk  Thu May  4 11:02:16 2006
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 4 May 2006 19:02:16 +0100 (BST)
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <Pine.LNX.4.44.0605041841590.31496-100000@andromeda.star.bris.ac.uk>

On Thu, 4 May 2006, Miguel Cervi?o wrote:

> Dear all,
> 
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> The applications compared are VOSpec, specview, topcat, and VOplot.
> (Note that topcat and VOplot are general propose tools and VOSpec and
> specview are specific for SEDs).

Miguel,

thanks for this posting.  This kind of detailed feedback on what
does and doesn't work, and what you want to see, is useful for 
application developers (well, I speak for myself in any case).

As you say, TOPCAT doesn't pay much attention to GROUP elements at
present.  I believe what it does is to behave as if GROUP elements
(though not their contents) are not there, so the grouping will be 
lost, but columns and parameters within the group will not.  
It also ignores table structure (for instance RESOURCEs within 
RESOURCEs) in a similar way.  Trying to do improve this kind of 
table metadata retention for VOTables is on the to-do list, 
but not currently very near the top (there are some technical 
difficulties which I will forbear to explain).  However, if it's 
something which the theory community (and others?) see as important 
I can see about prioritising it.  Ranking on the to-do list is 
influenced by user requests; I have had a few requests for this 
in the past but not that many.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



From glemson at xray.mpe.mpg.de  Thu May  4 11:14:28 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Thu, 4 May 2006 20:14:28 +0200 (METDST)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>
Message-ID: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>

Hi Ray

We did indeed came to the conclusion that it should be possible to
register resources without there being a fitting standard
specification/protocol. I would actually like to try to register some
such theory specific services and datasets during the interop, as there we
could benefit from interaction with registry connaiseurs such as you.
Would you be willing and to make a contribution to one of the theory
sessions on Monday to explain this in some more detail ?

Cheers
Gerard

On Thu, 4 May 2006, Ray Plante wrote:

> Gentle Theorists,
> 
> During a recent chat, Sebastien Derriere reported on a meeting of 
> VOTheorists in which there was some discussion of how one should publish 
> simulation data and/or services to the VO.  I thought that I would mention 
> a document I wrote for the NVO called "How to Publish to the NVO".  It's 
> meant to be a brief introduction to VO publishing with pointers to how to 
> get started.  It's a little out of date at the moment (an update is in the 
> works), but it is not inaccurate.  I would be interested to get some 
> feedback from your group about how applicable you feel it is to 
> theory-related resources.  In particular, if you have suggestions for 
> addressing the theory community, this would get a great time to get those.  
> 
> In the VO, we talk a lot about registering standard services like SIA and 
> SkyNodes.  However you may not be aware that it is currently possible to 
> register general data collections and non-standard services, including 
> those that have a web-page interface.  While I'm sure that you will 
> benefit from some standards that are specifically targetted to the theory 
> community in the future, you may find the generic resource descriptions 
> useful today.  In fact, I would encourage you to visit the registry at 
> NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try registering 
> somethings.  This site provides a sandbox version that allows you to try 
> out the interface without actually publishing anything.  
> 
> Finally, to the Registry WG, it's been suggested that we take a look at 
> this document and see if there is an IVOA version we might publish as a 
> note.  Your feedback is welcome as well.  
> 
> cheers,
> Ray
> 
> 


From rplante at ncsa.uiuc.edu  Thu May  4 11:20:06 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 13:20:06 -0500 (CDT)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.LNX.4.44.0605041319130.5042-100000@poplar.ncsa.uiuc.edu>

On Thu, 4 May 2006, Gerard Lemson wrote:
> Would you be willing and to make a contribution to one of the theory
> sessions on Monday to explain this in some more detail ?

Sure.  There's the usual juggling of parallel sessions.  I'm slated to 
give a talk at one of the GWS sessions but I'm not sure which, yet.

cheers,
Ray



From Franck.LePetit at obspm.fr  Thu May  4 14:01:36 2006
From: Franck.LePetit at obspm.fr (Franck Le Petit)
Date: Thu, 4 May 2006 23:01:36 +0200
Subject: How to Publish to the NVO
In-Reply-To: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>
References: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <68D040F3-2B11-46FA-93C1-12A1AF6236B2@obspm.fr>


	Dear Gerard, dear Ray and dear members of VO-Theory

	I followed Ray informations to register my PDR simulation code in  
the NVO registry.
	I did some mistakes (as the creation of an organization and an  
authority which do not want to disappear from the registry.  I hope  
this will be solved soon) but succeeded very easily to register it as  
a service (marked as a skyservice - another little problem)
	It is extremely simple to do.

	Once registered, I tried several searches in the NVO as somebody  
looking for a simulation code of interstellar clouds would do.
	Each time, the NVO search system has been able to find it.

	So, even if there are some points to improve, as Ray said, the way  
the inscription in registries is done can be used for simulations  
with a web interface (webservices as well I guess).

	Best regards and see you in Victoria.
	Franck

PS : For those who wonder, PDR codes are the codes which model the  
physics and the chemistry of interstellar clouds.
PPS: If you try to access the code, you will be blocked by a login  
and password. This is because it gives access to computing facilities  
of the Observatory of Paris. We need a bit more computing power  
before opening completely the access to the codes.

    ------------------------------------
    Franck Le Petit
    LUTH
    Observatoire de Meudon
    5 Place Jules Janssen
    92190 Meudon
    France
    Tel: (33) 1 45 07 75 66
    ------------------------------------


Le 4 mai 06 ? 20:14, Gerard Lemson a ?crit :

> Hi Ray
>
> We did indeed came to the conclusion that it should be possible to
> register resources without there being a fitting standard
> specification/protocol. I would actually like to try to register some
> such theory specific services and datasets during the interop, as  
> there we
> could benefit from interaction with registry connaiseurs such as you.
> Would you be willing and to make a contribution to one of the theory
> sessions on Monday to explain this in some more detail ?
>
> Cheers
> Gerard
>
> On Thu, 4 May 2006, Ray Plante wrote:
>
>> Gentle Theorists,
>>
>> During a recent chat, Sebastien Derriere reported on a meeting of
>> VOTheorists in which there was some discussion of how one should  
>> publish
>> simulation data and/or services to the VO.  I thought that I would  
>> mention
>> a document I wrote for the NVO called "How to Publish to the  
>> NVO".  It's
>> meant to be a brief introduction to VO publishing with pointers to  
>> how to
>> get started.  It's a little out of date at the moment (an update  
>> is in the
>> works), but it is not inaccurate.  I would be interested to get some
>> feedback from your group about how applicable you feel it is to
>> theory-related resources.  In particular, if you have suggestions for
>> addressing the theory community, this would get a great time to  
>> get those.
>>
>> In the VO, we talk a lot about registering standard services like  
>> SIA and
>> SkyNodes.  However you may not be aware that it is currently  
>> possible to
>> register general data collections and non-standard services,  
>> including
>> those that have a web-page interface.  While I'm sure that you will
>> benefit from some standards that are specifically targetted to the  
>> theory
>> community in the future, you may find the generic resource  
>> descriptions
>> useful today.  In fact, I would encourage you to visit the  
>> registry at
>> NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try  
>> registering
>> somethings.  This site provides a sandbox version that allows you  
>> to try
>> out the interface without actually publishing anything.
>>
>> Finally, to the Registry WG, it's been suggested that we take a  
>> look at
>> this document and see if there is an IVOA version we might publish  
>> as a
>> note.  Your feedback is welcome as well.
>>
>> cheers,
>> Ray
>>
>>
>



From Jesus.Salgado at sciops.esa.int  Fri May  5 03:48:11 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 12:48:11 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <1146826091.4221.24.camel@isol11.vilspa.esa.int>

Dear Miguel,

Just some comments about your applications benchmark.

Units:
------

> 1. problem with units nomenclature: There is no recommendation about
the use of units in the VOTable fields. In particular, 
> VOSpec and specview use different ways to define the units for the
flux e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). 
> Would it be possible to define any recommendation about that?
Otherwise the same VOTable would not be used for both 
>  applications! 

As you probably know, VOSpec is not using the units string definition
for the units handling but the scaleq and dimeq fields. 
We made the proposal to include this dimensional analysis data to
prevent the problems of multiple unit string convections (among other
things)
You have read it in the SED document, (point 3.2 Units) 
http://hea-www.harvard.edu/~jcm/vo/docs/spec0.93.html
The definition of the scaleq and dimeq syntax is (hopefully) uniform for
all the services, following our recommendation.  In any case, same
VOTables are currently used for both applications, so it looks that the
problem has been solved at application level (for us, using the
dimensional analysis information instead of the unit strings, for others
using aliases and string conversions)

Metadata in VOTable
-------------------

About the VOTable metadata issue, in our view, the information inside
the VOTable response is to be used automatically by the client
application (except for the VOTable editors). 

In case there is no implementation to use specific information in the
VOTable response, there is a risk to lose it. VOSpec is taking the
information for the row where the spectrum is described and it is shown
to the user if the user double-click on one spectrum in the result tree.
This should not be enough in the future, as any essential information
included in the VOTable response should be protocolized in some way to
be properly treated in the client (not only shown). If there is some
information only to be shown to the user linked to one result, probably
the best way to do it for the time being could be to include a link to a
dynamically generated page  (in a format readable by humans).

About the columns for errors, this will be included in VOSpec quite soon
for all the services that can provide them. The only constraint would be
the order of the columns in the ?columns? field.

TSAP:
-----

> d) A final comment, it looks that only VOSpec is able to manage a
Theoretical spectral acces protocol: 
> It means, perform the query to a server that gives back a table with
the parameter space covered by the 
> models that the server provides, and perform a "second" query over a
subsample of the parameter space covered.

This is not quite surprising as we were the ones to propose the
theoretical spectral access protocol in the IVOA. 
As you probably know, we proposed the creation of this kind of server to
the SVO coordinator (Enrique Solano) for the Kurucz models and we
implemented the client part in VOSpec. Some other services were created
later related to SVO and Mexican VO, and we have contacted some others
to create similar services (as the ones from the French VO), so all the
services have been created more or less under our coordination. We think
it is a good first step to include theoretical SEDs in the VO, and easy
to be implemented for SED VO applications.

Best Regards,
Jesus Salgado

ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From Jesus.Salgado at sciops.esa.int  Fri May  5 03:48:11 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 12:48:11 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <1146826091.4221.24.camel@isol11.vilspa.esa.int>

Dear Miguel,

Just some comments about your applications benchmark.

Units:
------

> 1. problem with units nomenclature: There is no recommendation about
the use of units in the VOTable fields. In particular, 
> VOSpec and specview use different ways to define the units for the
flux e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). 
> Would it be possible to define any recommendation about that?
Otherwise the same VOTable would not be used for both 
>  applications! 

As you probably know, VOSpec is not using the units string definition
for the units handling but the scaleq and dimeq fields. 
We made the proposal to include this dimensional analysis data to
prevent the problems of multiple unit string convections (among other
things)
You have read it in the SED document, (point 3.2 Units) 
http://hea-www.harvard.edu/~jcm/vo/docs/spec0.93.html
The definition of the scaleq and dimeq syntax is (hopefully) uniform for
all the services, following our recommendation.  In any case, same
VOTables are currently used for both applications, so it looks that the
problem has been solved at application level (for us, using the
dimensional analysis information instead of the unit strings, for others
using aliases and string conversions)

Metadata in VOTable
-------------------

About the VOTable metadata issue, in our view, the information inside
the VOTable response is to be used automatically by the client
application (except for the VOTable editors). 

In case there is no implementation to use specific information in the
VOTable response, there is a risk to lose it. VOSpec is taking the
information for the row where the spectrum is described and it is shown
to the user if the user double-click on one spectrum in the result tree.
This should not be enough in the future, as any essential information
included in the VOTable response should be protocolized in some way to
be properly treated in the client (not only shown). If there is some
information only to be shown to the user linked to one result, probably
the best way to do it for the time being could be to include a link to a
dynamically generated page  (in a format readable by humans).

About the columns for errors, this will be included in VOSpec quite soon
for all the services that can provide them. The only constraint would be
the order of the columns in the ?columns? field.

TSAP:
-----

> d) A final comment, it looks that only VOSpec is able to manage a
Theoretical spectral acces protocol: 
> It means, perform the query to a server that gives back a table with
the parameter space covered by the 
> models that the server provides, and perform a "second" query over a
subsample of the parameter space covered.

This is not quite surprising as we were the ones to propose the
theoretical spectral access protocol in the IVOA. 
As you probably know, we proposed the creation of this kind of server to
the SVO coordinator (Enrique Solano) for the Kurucz models and we
implemented the client part in VOSpec. Some other services were created
later related to SVO and Mexican VO, and we have contacted some others
to create similar services (as the ones from the French VO), so all the
services have been created more or less under our coordination. We think
it is a good first step to include theoretical SEDs in the VO, and easy
to be implemented for SED VO applications.

Best Regards,
Jesus Salgado

ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From mcs at iaa.es  Fri May  5 06:37:42 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 5 May 2006 15:37:42 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
Message-ID: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>

Thanks a lot Jesus,

I completely agree with you points, but
only for "increasing" the discussion:

About metadata in the VO table, there is two particular issues
specifically related with theory, and any analysis tool:
Suppouse that you overplot real data and several theoretical models.
And you obtain a good fit of a particular model. If the application  
is not able to show the
model parameters (that should be included somewhere in the VOTable  
metadata), how
can you recover them for, for example, a publication? I would agree  
that an
link to a generated page would be fine, but it would only works for  
catalogs,
and it would not work if the teoretical data is generated by the use  
of diferent
aplications (example a virtual telescope machine). Since model  
parameters should
be included in the VOtable, I think is more easy, and safer, that the  
applications
would be able to show the information that is yet included in the  
VOTable
they manage instead to refer to an external link. Additionally, an  
external link
will make not possible to work with downloaded data without internet  
conexion....

(An specific comment about that is that the providers of synthesis  
models
would not be very happy and may be will not join actively the VO  
iniciative if
they do not obtain credits for the use of their models, and metadata  
is the
only place where such a credit can be written explicitelly, including  
references to
the models papers etc...)

And about TSAP, yes, I know (I had been also working) it ;)
However, most of VOtools applications are not designed to
support a TSAP-like protocol: Obtain a parameter VOTable and
process it before access the data.... Maybe is time that other
applications also will think about this kind of implementation, isn't  
it?

cheers

	miguel



From mcs at iaa.es  Fri May  5 06:37:42 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 5 May 2006 15:37:42 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
Message-ID: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>

Thanks a lot Jesus,

I completely agree with you points, but
only for "increasing" the discussion:

About metadata in the VO table, there is two particular issues
specifically related with theory, and any analysis tool:
Suppouse that you overplot real data and several theoretical models.
And you obtain a good fit of a particular model. If the application  
is not able to show the
model parameters (that should be included somewhere in the VOTable  
metadata), how
can you recover them for, for example, a publication? I would agree  
that an
link to a generated page would be fine, but it would only works for  
catalogs,
and it would not work if the teoretical data is generated by the use  
of diferent
aplications (example a virtual telescope machine). Since model  
parameters should
be included in the VOtable, I think is more easy, and safer, that the  
applications
would be able to show the information that is yet included in the  
VOTable
they manage instead to refer to an external link. Additionally, an  
external link
will make not possible to work with downloaded data without internet  
conexion....

(An specific comment about that is that the providers of synthesis  
models
would not be very happy and may be will not join actively the VO  
iniciative if
they do not obtain credits for the use of their models, and metadata  
is the
only place where such a credit can be written explicitelly, including  
references to
the models papers etc...)

And about TSAP, yes, I know (I had been also working) it ;)
However, most of VOtools applications are not designed to
support a TSAP-like protocol: Obtain a parameter VOTable and
process it before access the data.... Maybe is time that other
applications also will think about this kind of implementation, isn't  
it?

cheers

	miguel



From Jesus.Salgado at sciops.esa.int  Fri May  5 07:35:04 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 16:35:04 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
 <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
Message-ID: <1146839704.4221.66.camel@isol11.vilspa.esa.int>

Hi Miguel,

On Fri, 2006-05-05 at 15:37 +0200, Miguel Cervi?o wrote:
> Thanks a lot Jesus,
> 
> I completely agree with you points, but
> only for "increasing" the discussion:
> 
> About metadata in the VO table, there is two particular issues
> specifically related with theory, and any analysis tool:
> Suppouse that you overplot real data and several theoretical models.
> And you obtain a good fit of a particular model. If the application  
> is not able to show the
> model parameters (that should be included somewhere in the VOTable  
> metadata), how
> can you recover them for, for example, a publication? I would agree  
> that an
> link to a generated page would be fine, but it would only works for  
> catalogs,
> and it would not work if the teoretical data is generated by the use  
> of diferent
> aplications (example a virtual telescope machine). Since model  
> parameters should
> be included in the VOtable, I think is more easy, and safer, that the  
> applications
> would be able to show the information that is yet included in the  
> VOTable
> they manage instead to refer to an external link. Additionally, an  
> external link
> will make not possible to work with downloaded data without internet  
> conexion....
> 

In this particular case, I would put the metadata to identify the
spectrum inside the spectrum itself, e.g., inside the header in case of
a fits or inside the votable spectrum in case of a votable spectrum. 
In this case, the file downloaded would be self-consistent and the model
provider will be sure that all the information to properly "understand"
the spectrum is there after saving the file. If I remember correctly,
all the applications have a save function for the file itself, so this
approach would work for all the VO applications. (in the case of VOSpec,
clicking twice on one spectrum, a window appears with a Save button)

Probably, there is room to more specific metadata in the VOTable
response (in particular publications links should be understood better
in the clients) but, except for the VOTable editors, many of the
metadata will be ignored by the VO clients. 
On the other hand, and probably because of the same reason, the VO
clients do not save the VOTable responses but only the data link files.

There is a problem added to save VOTable responses. For the client, the
result is a combination of several VOTables from different servers, so
the only two ways that I see to save the metadata is either saving every
single VOTable or to create a VOTable as a combination of several
heterogeneous VOTables (really a mess if we want to maintain this result
VOTable as something usable as input for future e.g. VOSpec sessions)

> (An specific comment about that is that the providers of synthesis  
> models
> would not be very happy and may be will not join actively the VO  
> iniciative if
> they do not obtain credits for the use of their models, and metadata  
> is the
> only place where such a credit can be written explicitelly, including  
> references to
> the models papers etc...)
> 
> And about TSAP, yes, I know (I had been also working) it ;)
> However, most of VOtools applications are not designed to
> support a TSAP-like protocol: Obtain a parameter VOTable and
> process it before access the data.... Maybe is time that other
> applications also will think about this kind of implementation, isn't  
> it?
> 
I agree with you as the implementation of TSAP for a VO SED client
application is quite easy and can be done for other applications.

During the presentation in Kyoto, it was agreed to include TSAP as a
particular case of SSAP. The only thing to be changed in the SSAP was to
demote the position compulsory input to optional, as "position" is
meaningless for most of the model servers. 
The call to the format=metadata was something standard to create
specific queries to servers and it should be already implemented in the
clients, but most of the VO applications create "blind" queries using
only the compulsory parameters (what it represents a problem for the
TSAP implementations)

In any case, the creation of on-the-fly query forms using the
format=metadata VOTables (or other more complex response in the future,
in case of evolution) should not be a major problem.


> cheers
> 
> 	miguel
> 
> 
Best Regards,
-- 
Jesus J. Salgado


ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From Jesus.Salgado at sciops.esa.int  Fri May  5 07:35:04 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 16:35:04 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
 <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
Message-ID: <1146839704.4221.66.camel@isol11.vilspa.esa.int>

Hi Miguel,

On Fri, 2006-05-05 at 15:37 +0200, Miguel Cervi?o wrote:
> Thanks a lot Jesus,
> 
> I completely agree with you points, but
> only for "increasing" the discussion:
> 
> About metadata in the VO table, there is two particular issues
> specifically related with theory, and any analysis tool:
> Suppouse that you overplot real data and several theoretical models.
> And you obtain a good fit of a particular model. If the application  
> is not able to show the
> model parameters (that should be included somewhere in the VOTable  
> metadata), how
> can you recover them for, for example, a publication? I would agree  
> that an
> link to a generated page would be fine, but it would only works for  
> catalogs,
> and it would not work if the teoretical data is generated by the use  
> of diferent
> aplications (example a virtual telescope machine). Since model  
> parameters should
> be included in the VOtable, I think is more easy, and safer, that the  
> applications
> would be able to show the information that is yet included in the  
> VOTable
> they manage instead to refer to an external link. Additionally, an  
> external link
> will make not possible to work with downloaded data without internet  
> conexion....
> 

In this particular case, I would put the metadata to identify the
spectrum inside the spectrum itself, e.g., inside the header in case of
a fits or inside the votable spectrum in case of a votable spectrum. 
In this case, the file downloaded would be self-consistent and the model
provider will be sure that all the information to properly "understand"
the spectrum is there after saving the file. If I remember correctly,
all the applications have a save function for the file itself, so this
approach would work for all the VO applications. (in the case of VOSpec,
clicking twice on one spectrum, a window appears with a Save button)

Probably, there is room to more specific metadata in the VOTable
response (in particular publications links should be understood better
in the clients) but, except for the VOTable editors, many of the
metadata will be ignored by the VO clients. 
On the other hand, and probably because of the same reason, the VO
clients do not save the VOTable responses but only the data link files.

There is a problem added to save VOTable responses. For the client, the
result is a combination of several VOTables from different servers, so
the only two ways that I see to save the metadata is either saving every
single VOTable or to create a VOTable as a combination of several
heterogeneous VOTables (really a mess if we want to maintain this result
VOTable as something usable as input for future e.g. VOSpec sessions)

> (An specific comment about that is that the providers of synthesis  
> models
> would not be very happy and may be will not join actively the VO  
> iniciative if
> they do not obtain credits for the use of their models, and metadata  
> is the
> only place where such a credit can be written explicitelly, including  
> references to
> the models papers etc...)
> 
> And about TSAP, yes, I know (I had been also working) it ;)
> However, most of VOtools applications are not designed to
> support a TSAP-like protocol: Obtain a parameter VOTable and
> process it before access the data.... Maybe is time that other
> applications also will think about this kind of implementation, isn't  
> it?
> 
I agree with you as the implementation of TSAP for a VO SED client
application is quite easy and can be done for other applications.

During the presentation in Kyoto, it was agreed to include TSAP as a
particular case of SSAP. The only thing to be changed in the SSAP was to
demote the position compulsory input to optional, as "position" is
meaningless for most of the model servers. 
The call to the format=metadata was something standard to create
specific queries to servers and it should be already implemented in the
clients, but most of the VO applications create "blind" queries using
only the compulsory parameters (what it represents a problem for the
TSAP implementations)

In any case, the creation of on-the-fly query forms using the
format=metadata VOTables (or other more complex response in the future,
in case of evolution) should not be a major problem.


> cheers
> 
> 	miguel
> 
> 
Best Regards,
-- 
Jesus J. Salgado


ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From glemson at xray.mpe.mpg.de  Tue May  9 20:23:55 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Wed, 10 May 2006 05:23:55 +0200 (METDST)
Subject: agenda
Message-ID: <Pine.HPX.4.21.0605100520350.15277-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
The current agenda for the theory sessions is posted on the meeting's
theory site, http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006Theory. 
It is not final as I am still waiting for some replies to requests.
But please let me know any questions you have already.
Note that I am currently already in Victoria, thus 9 hours out of synch
with Middle-European time.
Regards
Gerard


From andrea.preitemartinez at iasf-roma.inaf.it  Sun May 14 23:48:36 2006
From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez)
Date: Mon, 15 May 2006 08:48:36 +0200
Subject: UCD's for simulations
In-Reply-To: <Pine.GSO.4.58.0604142228280.6904@cass25>
References: <ODENKDLEINNEPJOIJLEFAELDCNAA.gerard.lemson@mpe.mpg.de>
	<Pine.GSO.4.58.0604142228280.6904@cass25>
Message-ID: <20060515084836.7xzmd39g4gk0c8ww@webmail.sic.rm.cnr.it>

Dear Laurie,

I've been collecting various proposal for upgrading the list of  
UCD-words, and I'll present these proposal for discussion (including  
yours) during the UCD/Semantic session (thu 18, 9.00-10.30).

The list of proposed modifications and the agenda can be found at
http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD

Regards,

Andrea
===================================================================================
Andrea Preite Martinez                 andrea.preitemartinez at iasf-roma.inaf.it
IASF                                   Tel.IASF:+39.06.4993.4651
Via del Fosso del Cavaliere 100        Tel.CDS :+33.3.90242473
I-00133 Roma                           Cell.1  :+39.320.43.15.383
                                        Cell.2  :+39.339.38.17.355
===================================================================================


Quoting Laurie Shaw <lds at ast.cam.ac.uk>:

>
> Dear All,
>
> I've recently been experimenting with assigning UCDs to the results of
> some cosmological simulations -- specifically to catalogues of dark
> matter halos and their associated subhalos. In general, i've found
> that the existing UCD tree is able to describe most of the properties of
> these objects that are typically analysed in the literature, albeit with a
> few exceptions.
>
> However, it is not currently possible to describe the properties and
> parameters of the simulations themselves. This includes some input
> physical parameters (i.e. cosmological parameters) that define the
> theoretical context of the simulation, and technical
> parameters that define its size,scope and resolution (e.g number of
> particles, length of simulation box side, gravitational
> softening length, time/redshift of a simulation output).
>
> Therefore, for the latter, I propose a new branch of the UCD tree to
> encompass computatational techniques in astronomy: 'comp'. This
> branch can be used to describe both astrophysical (and cosmological)
> simulations, and data reduction and post-processing algorithms for
> both simulation and observational data. It is roughly a computing
> analogue of the 'instr' branch. For the case of simulations I propose
> the following sub-branches
>
> comp.sim		(computational simulation)
> comp.sim.nbody		(Nbody simulation)
> comp.sim.sph		(Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside	(Simulation box)
> comp.sim.gravsoft	(gravitational softening)
> comp.sim.particles	(simulation particles (for Nbody and SPH
> simulations))
> comp.sim.snapshot	(output of a simulation box at a particular
> instant)
> comp.sim.grid		(simulation grid (for hydro simulations))
>
> The number of particles in the simulation box, number of grid points,
> particle mass, gravitational softening length and simulation box side
> length would therefore be:
>
> meta.num;comp.sim.particles
> meta.num;comp.sim.grid
> phys.mass;comp.sim.particles
> phys.size;comp.sim.gravsoft
> phys.size;comp.sim.boxside
>
> (For the last two, introduction of a phys.size.length UCD might provide a
> more accurate description.)
>
> The mass of an object in terms of the number of particles it contains:
>
> phys.mass;meta.num;comp.sim.particles
>
> Other possible sub-branches could be
>
> comp.resourse	         (computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory	 (total size of a data file)
>
> plus those that are more specific to data-reduction/post-processing of
> observational data.  Algorithms that might apply to both simulated and
> observed data (e.g. smoothing of images or particle densities) would
> be listed directly under the comp branch:
>
> phys.size;comp.smooth
> (or, with the introduction of a phys.size.length UCD:
> phys.size.length;comp.smooth)
>
> Physical Parameters
> ---------------------
> Currently, there exists no UCDs for the main cosmological
> parameters. In terms of simulations, it is very important to be able
> define the assumed cosmology, when interpreting the results. To
> describe these parameters I propose a 'cosmology' sub-branch of
> the phys branch. So,
>
> phys.cosmology		(cosmology)
> phys.cosmology.omega 	(matter/energy density of universe)
> phys.cosmology.hubble 	(hubble constant)
> phys.cosmology.sigma8 	(Normalisation of matter power-spectrum)
>
> and also:
>
> phys.matter.dark 	(dark matter tag)
> phys.matter.baryon 	(baryonic matter tag)
> phys.DarkEnergy 	(dark energy tag)
>
> So, Omega_Lambda, Omega_DM, Omega_baryon would be
>
> phys.cosmology.omega;phys.DarkEnery,
> phys.cosmology.omega;phys.matter.dark
> phys.comsology.omega;phys.matter.baryonic
>
> Now we can also describe the number of dark matter (gas particles) in
> an SPH simulation, or a simulated object (star/galaxy/halo) using:
>
> meta.num;comp.sim.particles;phys.matter.dark(/baryonic)
>
> Furthermore, the mass and radius of dark matter halos in cosmological
> simulations are frequently defined in terms of a virial
> overdensity. Hence a phys.virial UCD would be usefull in specifying
> what is meant by the mass and radius of a halo:
>
> phys.mass;phys.virial (virial mass)
> phys.size.radius;phys.virial (virial radius)
>
> Time in Simulations
> ------------------
> People frequently analyse the output of simulations, or snapshots, at
> a series of different timesteps. This is often quoted in terms of the
> redshift of
> the snapshot. At the moment, redshift exists under the 'src'
> branch. Maybe it might be better under the `phys' branch as it is a
> measure of both distance and time, and can therefore be used to label
> both the distance of observed objects and to label a time-stamp for
> simulation snapshots:
>
> phys.redshift;comp.sim.snapshot
>
> Astrophysical Objects
> --------------------
> Another problem is the listing of astronomical objects types under the
> 'src' branch. This introduces confusion when trying to describe a
> simulated astrophysical object. For example, the first word in
> src.class.galaxy;comp.sim (simulated galaxy) implies that this is an
> observed astrophysical source, the second that it is simulated.
>
> Additionally, objects such as halos and subhalos are not typically
> observed (though i guess people do make estimates of their mass/size
> through
> gravitational lensing). It seems strange to have halo and subhalo
> listed under the src.class sub-branch. I therefore suggest that an
> object branch be introduced in which astrophysical (and theoretical)
> objects can be listed (as also proposed by others on the UCD suggestion
> page):
>
> object.galaxy;comp.sim (a simulated galaxy)
> object.galaxy.spiral;comp.sim (a simulated spiral galaxy)
>
> One example that I encountered of an actual quantity where this was
> useful is describing the mass in substructure, or the number of
> subhalos, in a simulated halo:
>
> phys.mass;object.DMhalo.subhalo
> meta.num;onject.DMhalo.subhalo
>
> It would be great to hear everyones thoughts, or ideas for alternative
> approaches, for all these.
>
> Cheers,
>
> Laurie
>
>
> List of Proposed UCDs
> ---------------------
> comp (computational astronomy)
> comp.sim (simulations)
> comp.sim.nbody (Nbody simulation)
> comp.sim.sph (Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside (Simulation box)
> comp.sim.gravsoft (gravitational softening)
> comp.sim.particles (simulation particles (for Nbody and SPH simulations))
> comp.sim.snapshot (output of a simulation box at a particular instant)
> comp.sim.grid (simulation grid (for hydro simulations))
> comp.resourse (to describe computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory (total size on disk of data)
> (comp.dataReduct ?
> comp.algorithm (general algorithms applied to sim/obs data) )
>
> phys.cosmology
> phys.cosmology.omega (matter/energy density of universe)
> phys.cosmology.hubble (hubble constant)
> phys.cosmology.sigma8 (Normalisation of matter power-spectrum)
> phys.matter.dark (dark matter tag)
> phys.matter.baryon (baryonic matter tag)
> phys.DarkEnergy (dark energy tag)
> phys.virial
> phys.size.length
>
> object  (astophysical object)
> object.planet (planet)
> object.satellite
> object.star   (star)
> object.galaxy (galaxy)
> object.DMhalo (DM halo)
> Object.DMhalo.subhalo (DM subhalo)
> etc
>
>
>






From andrea.preitemartinez at iasf-roma.inaf.it  Sun May 14 23:48:36 2006
From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez)
Date: Mon, 15 May 2006 08:48:36 +0200
Subject: UCD's for simulations
In-Reply-To: <Pine.GSO.4.58.0604142228280.6904@cass25>
References: <ODENKDLEINNEPJOIJLEFAELDCNAA.gerard.lemson@mpe.mpg.de>
	<Pine.GSO.4.58.0604142228280.6904@cass25>
Message-ID: <20060515084836.7xzmd39g4gk0c8ww@webmail.sic.rm.cnr.it>

Dear Laurie,

I've been collecting various proposal for upgrading the list of  
UCD-words, and I'll present these proposal for discussion (including  
yours) during the UCD/Semantic session (thu 18, 9.00-10.30).

The list of proposed modifications and the agenda can be found at
http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD

Regards,

Andrea
===================================================================================
Andrea Preite Martinez                 andrea.preitemartinez at iasf-roma.inaf.it
IASF                                   Tel.IASF:+39.06.4993.4651
Via del Fosso del Cavaliere 100        Tel.CDS :+33.3.90242473
I-00133 Roma                           Cell.1  :+39.320.43.15.383
                                        Cell.2  :+39.339.38.17.355
===================================================================================


Quoting Laurie Shaw <lds at ast.cam.ac.uk>:

>
> Dear All,
>
> I've recently been experimenting with assigning UCDs to the results of
> some cosmological simulations -- specifically to catalogues of dark
> matter halos and their associated subhalos. In general, i've found
> that the existing UCD tree is able to describe most of the properties of
> these objects that are typically analysed in the literature, albeit with a
> few exceptions.
>
> However, it is not currently possible to describe the properties and
> parameters of the simulations themselves. This includes some input
> physical parameters (i.e. cosmological parameters) that define the
> theoretical context of the simulation, and technical
> parameters that define its size,scope and resolution (e.g number of
> particles, length of simulation box side, gravitational
> softening length, time/redshift of a simulation output).
>
> Therefore, for the latter, I propose a new branch of the UCD tree to
> encompass computatational techniques in astronomy: 'comp'. This
> branch can be used to describe both astrophysical (and cosmological)
> simulations, and data reduction and post-processing algorithms for
> both simulation and observational data. It is roughly a computing
> analogue of the 'instr' branch. For the case of simulations I propose
> the following sub-branches
>
> comp.sim		(computational simulation)
> comp.sim.nbody		(Nbody simulation)
> comp.sim.sph		(Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside	(Simulation box)
> comp.sim.gravsoft	(gravitational softening)
> comp.sim.particles	(simulation particles (for Nbody and SPH
> simulations))
> comp.sim.snapshot	(output of a simulation box at a particular
> instant)
> comp.sim.grid		(simulation grid (for hydro simulations))
>
> The number of particles in the simulation box, number of grid points,
> particle mass, gravitational softening length and simulation box side
> length would therefore be:
>
> meta.num;comp.sim.particles
> meta.num;comp.sim.grid
> phys.mass;comp.sim.particles
> phys.size;comp.sim.gravsoft
> phys.size;comp.sim.boxside
>
> (For the last two, introduction of a phys.size.length UCD might provide a
> more accurate description.)
>
> The mass of an object in terms of the number of particles it contains:
>
> phys.mass;meta.num;comp.sim.particles
>
> Other possible sub-branches could be
>
> comp.resourse	         (computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory	 (total size of a data file)
>
> plus those that are more specific to data-reduction/post-processing of
> observational data.  Algorithms that might apply to both simulated and
> observed data (e.g. smoothing of images or particle densities) would
> be listed directly under the comp branch:
>
> phys.size;comp.smooth
> (or, with the introduction of a phys.size.length UCD:
> phys.size.length;comp.smooth)
>
> Physical Parameters
> ---------------------
> Currently, there exists no UCDs for the main cosmological
> parameters. In terms of simulations, it is very important to be able
> define the assumed cosmology, when interpreting the results. To
> describe these parameters I propose a 'cosmology' sub-branch of
> the phys branch. So,
>
> phys.cosmology		(cosmology)
> phys.cosmology.omega 	(matter/energy density of universe)
> phys.cosmology.hubble 	(hubble constant)
> phys.cosmology.sigma8 	(Normalisation of matter power-spectrum)
>
> and also:
>
> phys.matter.dark 	(dark matter tag)
> phys.matter.baryon 	(baryonic matter tag)
> phys.DarkEnergy 	(dark energy tag)
>
> So, Omega_Lambda, Omega_DM, Omega_baryon would be
>
> phys.cosmology.omega;phys.DarkEnery,
> phys.cosmology.omega;phys.matter.dark
> phys.comsology.omega;phys.matter.baryonic
>
> Now we can also describe the number of dark matter (gas particles) in
> an SPH simulation, or a simulated object (star/galaxy/halo) using:
>
> meta.num;comp.sim.particles;phys.matter.dark(/baryonic)
>
> Furthermore, the mass and radius of dark matter halos in cosmological
> simulations are frequently defined in terms of a virial
> overdensity. Hence a phys.virial UCD would be usefull in specifying
> what is meant by the mass and radius of a halo:
>
> phys.mass;phys.virial (virial mass)
> phys.size.radius;phys.virial (virial radius)
>
> Time in Simulations
> ------------------
> People frequently analyse the output of simulations, or snapshots, at
> a series of different timesteps. This is often quoted in terms of the
> redshift of
> the snapshot. At the moment, redshift exists under the 'src'
> branch. Maybe it might be better under the `phys' branch as it is a
> measure of both distance and time, and can therefore be used to label
> both the distance of observed objects and to label a time-stamp for
> simulation snapshots:
>
> phys.redshift;comp.sim.snapshot
>
> Astrophysical Objects
> --------------------
> Another problem is the listing of astronomical objects types under the
> 'src' branch. This introduces confusion when trying to describe a
> simulated astrophysical object. For example, the first word in
> src.class.galaxy;comp.sim (simulated galaxy) implies that this is an
> observed astrophysical source, the second that it is simulated.
>
> Additionally, objects such as halos and subhalos are not typically
> observed (though i guess people do make estimates of their mass/size
> through
> gravitational lensing). It seems strange to have halo and subhalo
> listed under the src.class sub-branch. I therefore suggest that an
> object branch be introduced in which astrophysical (and theoretical)
> objects can be listed (as also proposed by others on the UCD suggestion
> page):
>
> object.galaxy;comp.sim (a simulated galaxy)
> object.galaxy.spiral;comp.sim (a simulated spiral galaxy)
>
> One example that I encountered of an actual quantity where this was
> useful is describing the mass in substructure, or the number of
> subhalos, in a simulated halo:
>
> phys.mass;object.DMhalo.subhalo
> meta.num;onject.DMhalo.subhalo
>
> It would be great to hear everyones thoughts, or ideas for alternative
> approaches, for all these.
>
> Cheers,
>
> Laurie
>
>
> List of Proposed UCDs
> ---------------------
> comp (computational astronomy)
> comp.sim (simulations)
> comp.sim.nbody (Nbody simulation)
> comp.sim.sph (Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside (Simulation box)
> comp.sim.gravsoft (gravitational softening)
> comp.sim.particles (simulation particles (for Nbody and SPH simulations))
> comp.sim.snapshot (output of a simulation box at a particular instant)
> comp.sim.grid (simulation grid (for hydro simulations))
> comp.resourse (to describe computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory (total size on disk of data)
> (comp.dataReduct ?
> comp.algorithm (general algorithms applied to sim/obs data) )
>
> phys.cosmology
> phys.cosmology.omega (matter/energy density of universe)
> phys.cosmology.hubble (hubble constant)
> phys.cosmology.sigma8 (Normalisation of matter power-spectrum)
> phys.matter.dark (dark matter tag)
> phys.matter.baryon (baryonic matter tag)
> phys.DarkEnergy (dark energy tag)
> phys.virial
> phys.size.length
>
> object  (astophysical object)
> object.planet (planet)
> object.satellite
> object.star   (star)
> object.galaxy (galaxy)
> object.DMhalo (DM halo)
> Object.DMhalo.subhalo (DM subhalo)
> etc
>
>
>






From glemson at xray.mpe.mpg.de  Tue May 16 09:29:21 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Tue, 16 May 2006 18:29:21 +0200 (METDST)
Subject: theory sessions
Message-ID: <Pine.HPX.4.21.0605161824040.14327-100000@mpehp1.mpe-garching.mpg.de>

Dear all

In the first theory sessions we decided that the following subjects
deserve more detailed attention during this Interop: data formats, 
UCDs,metadata and SNAP. On the meeting's TWiki page 
(http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006Theory 
I have added some structure to these proposals. Please mail me
if you would like to contribute to one of these discussions and when you
would have time to do so wrt the other sessions going on.
If possible I would like to start this afternoon.

Cheers
Gerard


From glemson at xray.mpe.mpg.de  Tue May 16 11:30:08 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Tue, 16 May 2006 20:30:08 +0200 (METDST)
Subject: theory UCD session
Message-ID: <Pine.HPX.4.21.0605162027280.14327-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
Taking into account replies to the email I suggest we meet this afternoon
after lunch, 2PM to discuss the UCDs for theory.
Andrea, If you can not make this I will report to you later.
Cheers
Gerard
PS
I will mail about a location later.


From glemson at xray.mpe.mpg.de  Tue May 16 11:57:48 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Tue, 16 May 2006 20:57:48 +0200 (METDST)
Subject: theory UCD session
In-Reply-To: <Pine.HPX.4.21.0605162027280.14327-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.HPX.4.21.0605162047030.14327-100000@mpehp1.mpe-garching.mpg.de>

The meeting will be in Boardroom B, up the stairs at the back of the main
meeting rooms.
We will start discussing UCDs, but hopefully we can deal with other issues
as well, for example a discussion how to approach the question of data
formats, which may not need too much time.
Gerard

On Tue, 16 May 2006, Gerard Lemson wrote:

> Dear collegues
> Taking into account replies to the email I suggest we meet this afternoon
> after lunch, 2PM to discuss the UCDs for theory.
> Andrea, If you can not make this I will report to you later.
> Cheers
> Gerard
> PS
> I will mail about a location later.
> 


From glemson at xray.mpe.mpg.de  Tue May 16 16:51:06 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Wed, 17 May 2006 01:51:06 +0200 (METDST)
Subject: theory UCD session
In-Reply-To: <Pine.HPX.4.21.0605162047030.14327-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.HPX.4.21.0605170141230.29629-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
Today the Cc:-s above met for a discussion about concepts that we need to
describe simulations. It started based on the email by Laurie Shaw with a
proposal for new UCDs. We realised that whereas some of the proposals were
properties, others were values. The former might be used to construct a
UCD, the latter to words in a/the standard vocabulary.
We decided that we first wanted to create a more comprehensive list of
these concepts, and only afterwards subdivide them into their apropriate
class, after weeding out concepts already existing in UCD list and/or
vocabulary.
To this end the first attempt is posted on the Twik pages, 
http://www.ivoa.net/twiki/bin/view/IVOA/TheorySemanticVocabulary.

Please add concepts and possible values.
It may be somewhat cryptic at the moment, this should improve.
The result will be discussed Thursday morning, first in UCD session I,
then in theory session III.
Regards
Gerard



From glemson at xray.mpe.mpg.de  Wed May 17 07:59:02 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Wed, 17 May 2006 16:59:02 +0200 (METDST)
Subject: theory data formats and SNAP session
In-Reply-To: <Pine.HPX.4.21.0605162047030.14327-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.HPX.4.21.0605171655160.9764-100000@mpehp1.mpe-garching.mpg.de>

Dear Collegues
As discussed earlier, today we will continue our discussions.
We'd like to talk about data formats and SNAP in particular.
As the exec meeting is actually planned to last until 15:30, and takes up
the Boardroom B where we'd be meeting, lets plan to meet at 16:00 there
after all.
Regards
Gerard




From mcs at iaa.es  Thu May 18 01:27:48 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 18 May 2006 10:27:48 +0200
Subject: FoV in Aladin and Virtual Telescopes
Message-ID: <523EFBF4-4FE2-4296-8103-F9F2C086F94D@iaa.es>

Dear all,

I am not in Victoria but I am following the session in the wiki pages.
I just see that Aladin provides now an implementation of any FoV,
that is described in a xml file (at least it is in the abstract).

I just realized that maybe it would be quite useful for future  
virtual telescope
developments, but it would need:
  - the xml file with the FoV would be a VOTable
  - there would be a "repository" or registry of FoV (may be provided by
      particular telescopes, or simple, a place where different FoV  
would be added
      by particular users that has done the work to define it for  
their observational proporsal)
      (i.e. the FoV is just another item in all the VO environment)

Well it is just a comment :)

cheers

	Miguel



From herve.wozniak at obs.univ-lyon1.fr  Thu May 18 08:33:51 2006
From: herve.wozniak at obs.univ-lyon1.fr (Herve Wozniak)
Date: Thu, 18 May 2006 17:33:51 +0200
Subject: semantics
Message-ID: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>

Hello,
I just have a look to the vocabulary list
(http://www.ivoa.net/twiki/bin/view/IVOA/TheorySemanticVocabulary)
that has been recently increased by Miguel. Thanks to fill the gap with all the
necessary tools for stellar population evolution.

I'm wondering however whether we need or not to introduce a second level of
'physical processes' (as suggested by Miguel, I guess). I understand that the
problem comes from stellar evolution and stellar population synthesis since the
real physical processes involved in such modelling are very embedded in several
shells of code. It could be difficult to classify PEGASE, GALAXEV etc. in the
'radiative transfer' or 'photoionization' boxes!
I could also anticipate that if I want to classify my own chemodynamical codes,
I will need more or less every keywords of the 'physical process' list (apart
from GR!)!!! Keeping in mind that these keywords are possible values of an UCD,
I would describe my chemodyn code as 'gravitational dynamics + hydrodynamics' at
the minimum, but how to describe star formation recipes, feedback, stellar
population evolution etc. which form the 'chemo' part of the code ?

Anyway, in my opinion, 'stellar evolution', 'stellar population synthesis', but
also 'stellar structure' and so on (still many gaps to be filled!), should be
also (or only?) listed in the 'subject'.

I suggest to include photoionization and photodissociation in 'physical process'
to be able to describe e.g. cloudy,mappings, Meudon code, etc., should we keep
or not the 'primary/secondary' distinction.

I would like to propose that hydrostatic is a particular case of hydrodynamics
since a growing number of star/planet/exo-planet atmosphere models includes
atmospheric circulation.

Cheers,
Herve

_______________________________________________________________
Herve WOZNIAK
Centre de Recherche Astronomique de Lyon (UMR 5574 UCBL/CNRS/ENS-Lyon)
9, avenue Charles Andre, F-69561 Saint Genis Laval cedex
Phone:  (+33) (0) 478 868 388     Fax:    (+33) (0) 478 868 386
http://www-obs.univ-lyon1.fr/herve.wozniak/

--------------------------------------------------------------------------
Ce message a ?t? envoy? depuis le webmail IMP (Internet Messaging Program)


From Franck.LePetit at obspm.fr  Thu May 18 10:22:29 2006
From: Franck.LePetit at obspm.fr (Franck.LePetit at obspm.fr)
Date: Thu, 18 May 2006 19:22:29 +0200 (CEST)
Subject: semantics
In-Reply-To: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>
References: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>
Message-ID: <Pine.OSF.4.58.0605181845490.509432@mesioq.obspm.fr>


Hello,

We thought a bit to this problem of definition we had on tuesday
afternoon. I put below my notes.
My conclusions are :
- we have to add an entry for the name of the developper or the
developping team. during the registration.
- The tag physical process will be our main problem. We will have to
describe far more our codes that we said on tuesday. Below I give the
example of somebody who would looked for a PDR code to compute
vibrationnal excitation of H2. It will require to describe codes in all
the details.
- On the other hand, as mentionned during the discussion on tuesday and
in last Herve's mail, registration of some codes would require to use far
too much "physical processes" values. An efficient search in registries
need to group them with more common names. Ex: photoionization region code
(cloudy type), PDR code.

Best regards
Franck Le Petit and Fabrice Roy

----------------------------------------------------------
Note about UCDs for the descrition of codes in registries
----------------------------------------------------------

First we have to precise if we try to caracterize a code or
a result from a simulation.
They should be considered as two different categories in the registries. A
metadata should be associated to simulation results to say from which code
it comes from. A search on this metadata should be possible.
Example : I want all simulation results from Zeus.


**********************************************
UCDs required FOR CODES
**********************************************

A search in the registries has to find a code.
Example of searches :
0) I want the wonderful code developped by the Albert E.
1) I want the Cloudy code.  (search by name)
2) I want the version of 1999 of the Cloudy code (add the version)
3) I want a radiative transfer code (category of code)
4) I want a radiative transfer code using the Ali method (method
specification)
5) I want a radiative transfer code able to deal with X-Rays in optically
thick media. (that is a tough one)
6) I want a radiative transfer code for interstellar clouds in the
millimetric producing spectra. (add a specification on the output)
8) I want an MHD code using characteristics methods for boundary
conditions. (method about boundary conditions - should be covered by
algorithm)
10) I want a stationnary (or time dependent) MHD shock model

Note : We could find very difficult queries. Ex: I want a PDR code
computing the vibrational excitation of H2.
Such queries would require to describe a lot the code in the registries
(excitation of H2).
I think that in a first step we do not have to go to this level but, at a
point, it may be necessary. It will require to have many possibilities in
the "physical process" tag (far more than in the thesaurus).

0 --- Team / developper ---------------------------------------
(Example 0)
A search on the name of a team or of a developper name should be possible.
It is frequent, we choose a code because we are confident in a team...

Required for registration : yes

1 --- Name --------------------------------------------------
(Example 1)
A UCD is required to tag the name of the code

Required for registration : yes
Multiple possibilities : no
Choice from a list : no

2 --- Version -----------------------------------------------
(Ex. 2)
A UCD is required to tag the number version of the code.

Required : yes
Multiple possibilities : no
Choice from a list : should follow common standards for versionning
(Herv?? knows that)


3 --- Physical Process (Type of code) -----------------------
(Ex. 3)
A UCD is required to specify the physical processes the code can deal
with.
Most of the possibilities can be found in the "thesaurus".
We should add some possibilities which are the common name given to codes
dealing with many physical processes.
Example : PDR code, Photoionization region code.

Multiple choice possible : yes
Defined list of possibilities : yes(?)
List of choices : Thesaurus (plus a few more to reflect the usual way
these codes are called ? )
Note: If we want to find a solution as the request :"search for a PDR code
computing the H2 excitation", the thesaurus will no more be sufficient.
Other solutions will have to be found.

Examples : 	- radiative transfer
		- MHD
		- gravitationnal dynamics (not in thesaurus)
		- photoionization (cover many physical processes)
		- PDR (cover many physical processes)

4 --- Subject ---------------------------------------------
(Ex. 6-7)
This UCD would precise the kinds of objects the code can simulate.
Example : - Accretion disk
	  - Molecular clouds
	  - Galaxies
...

Multiple choice : yes
Defined list of possibilities : yes
List : Thesaurus

Note : Example 5 is a problem. The request requires a code able to deal
with optically thick media. Such characterization is not found in the
thesaurus.

Note : A search using "Physical process" and "Subject" should succeed most
of the time excepted for specific researches

5 --- Algorithm ----------------------------------------
(Example : 4,8)

This UCD is required to specify an algorithm.
Example : N-body, SPH, Ali, ...,
Problem : The same algorithm can have different names.
Possible solution : Add as many values as it has of names.

The list should not be limited.
Reason : New algorithms can be found.

Should this field be filled for all codes ?
Not sure if such classification is relevant for physico-chemistry codes.
There are so many physical processes that nobody care how they are done
(excepted for radiative transfer).

6 --- Time Evolution algorithm ----------------------------

Is it a necessity to separate the time algorithm with the other algorithms
?
The main interest is that this UCD could help to discriminate between
stationnary and time dependent codes.

(7 --- Algorithmic parameters) ---------------------------

To be suppressed for the definition of codes in the VO.
Only relevant for the definition of results of simulations.

8 --- Result type -----------------------------------------
(Ex: 6)

A UCD is required for result type as seen in Ex. 6.
Multiple possibilities : yes
Defined list of possibilities : yes
List : 	- snapshot
	- animation
	- table
	- fits

9 --- Result parameters

I do not see the purpose of this UCD.




From derriere at newb6.u-strasbg.fr  Thu May 18 17:00:21 2006
From: derriere at newb6.u-strasbg.fr (derriere at newb6.u-strasbg.fr)
Date: Fri, 19 May 2006 02:00:21 +0200
Subject: semantics
In-Reply-To: <Pine.OSF.4.58.0605181845490.509432@mesioq.obspm.fr>
References: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>
	<Pine.OSF.4.58.0605181845490.509432@mesioq.obspm.fr>
Message-ID: <20060519020021.o1fqwxilb9344k40@astron.u-strasbg.fr>


   Hello,

   You can find the presentation that I did during
Registry session 5 on the meeting page:
http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006ResReg
   Especially, on the last slide, I tried to identify
the metadata tags from the Registry ResourceMetadata
document that could correspond to the main categories
that you identified. Comments are welcome.

   By the way, I'm a bit uncomfortable with the usage
of the UCD term in your mail. For example, I totally agree
that we need a UCD meaning "algorithm". But the different
possible values described by this UCD are not UCDs. They
can be words in a normalized vocabulary, you can write
them using a "a la UCD" syntax, but they really are not
UCDs.
   To tell it in a few words, we can have a UCD for each
ResourceMetadata element. The UCD is used to give a name
to the empty box, and this name is not specific to a given
schema, unlike the name of the XML element.
   The values you put in the box can be issued from a
normalized vocabulary, but they are not UCDs in the original
sense.

Sebastien.




From glemson at xray.mpe.mpg.de  Fri May 19 09:44:00 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Fri, 19 May 2006 18:44:00 +0200 (METDST)
Subject: metadata modeling
Message-ID: <Pine.HPX.4.21.0605191838340.25046-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
Today at 11 we will try to meet in Boardroom B, upstairs, to discuss the
approach to modeling metadata for discovering interesting simulations.
See you there
Gerard


From brian_thomas at earthlink.net  Fri May 19 10:42:15 2006
From: brian_thomas at earthlink.net (Brian Thomas)
Date: Fri, 19 May 2006 13:42:15 -0400
Subject: Links to W3C workflow/processing models
Message-ID: <200605191342.15312.brian_thomas@earthlink.net>


	As I mentioned in the DM session today there are a number of W3C efforts which
	should be considered (or at least mined for the 'good stuff') in terms of doing distributed
	workflows and processing descriptions.

	(at Mark Taylor's suggestion  I have cross posted to theory and grid-ws groups..don't shoot
	the messenger!!)

	=brian

Links:
http://www.w3.org/TR/proc-model-req/
http://www.w3.org/TR/xml-pipeline/ (older)
http://www.w3.org/Submission/OWL-S/

Software : 

http://www.mindswap.org/2004/owl-s/api/   (OWL-S API/execution environment)



	


From brian_thomas at earthlink.net  Fri May 19 10:42:15 2006
From: brian_thomas at earthlink.net (Brian Thomas)
Date: Fri, 19 May 2006 13:42:15 -0400
Subject: Links to W3C workflow/processing models
Message-ID: <200605191342.15312.brian_thomas@earthlink.net>


	As I mentioned in the DM session today there are a number of W3C efforts which
	should be considered (or at least mined for the 'good stuff') in terms of doing distributed
	workflows and processing descriptions.

	(at Mark Taylor's suggestion  I have cross posted to theory and grid-ws groups..don't shoot
	the messenger!!)

	=brian

Links:
http://www.w3.org/TR/proc-model-req/
http://www.w3.org/TR/xml-pipeline/ (older)
http://www.w3.org/Submission/OWL-S/

Software : 

http://www.mindswap.org/2004/owl-s/api/   (OWL-S API/execution environment)



	


From brian_thomas at earthlink.net  Fri May 19 10:42:15 2006
From: brian_thomas at earthlink.net (Brian Thomas)
Date: Fri, 19 May 2006 13:42:15 -0400
Subject: Links to W3C workflow/processing models
Message-ID: <200605191342.15312.brian_thomas@earthlink.net>


	As I mentioned in the DM session today there are a number of W3C efforts which
	should be considered (or at least mined for the 'good stuff') in terms of doing distributed
	workflows and processing descriptions.

	(at Mark Taylor's suggestion  I have cross posted to theory and grid-ws groups..don't shoot
	the messenger!!)

	=brian

Links:
http://www.w3.org/TR/proc-model-req/
http://www.w3.org/TR/xml-pipeline/ (older)
http://www.w3.org/Submission/OWL-S/

Software : 

http://www.mindswap.org/2004/owl-s/api/   (OWL-S API/execution environment)



	


From mcs at iaa.es  Thu May  4 05:42:34 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 4 May 2006 14:42:34 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>

Dear all,

I just send this comments that may be discussed in the next meeting.
It is just a comparison about how different VO applications manage
a SED building following the SED data model requirements.
The applications compared are VOSpec, specview, topcat, and VOplot.
(Note that topcat and VOplot are general propose tools and VOSpec and
specview are specific for SEDs).

I had find that more or less the current SED data model is fine for  
theory,
and may be, model parameters should be specified in  <GROUP> ...</GROUP>
fields for characterization or provenance (it is an issue to be  
defined in
the theory group). Note that in the theoretical domain, the  
parameters that
define the model are equally relevant than the model results themselves.

However, for the case of applications, (visualization tools mainly) I  
had found some
inconsistence/problems with a VOTable designed in such a way, and  
also internal inconsistency
between different tools. I summarize them here:

a) problem with units nomenclature: There is no recommendation about  
the use of units in the VOTable
fields. In particular, VOSpec and specview use different ways to  
define the units for the flux
e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be  
possible to define any
recommendation about that? Otherwise the same VOTable would not be
used for both applications!

b) Metadata and saved files: As pointed before, metadata in  
theoretical models are fundamental to
understand and perform any posterior analysis or comparison with real  
data (or "pipeline" process
for datamining as example). Again, metadata are sometimes equal in  
importance than the simulation result. However:

   - the VOTable metadata are not visualized by VOSpec, sepcview and  
VOPlot
   - metadata otuside <GROUP> are visualized by Topcat, but not  
metadata in <GROUP>...</GROUP>
         (so may be the use of a <GROUP> for characterization of the  
model is not a good idea after all...)

About the VOTables that can be saved by VOSpec, specview and Topcat  
(VOPlot do not save VOTables)
it is found that metadata is systematically lost!! (it means, such  
type of applications are not completely suitable
to retrieve theoretical models thought the VO registry for their  
posterior use!). In particular:

   - specview: do not include niether the original VOTable  <GROUP>  
of <PARAM> but include their own
         <GROUP> and <PARAM>'s
  -  VOSpec  do not include the original metadata
  - and  VOTables saved by topcat include table metadata but
       all <GROUP> parameters are lost.


c) Columns to be plotted:

      c.1) specview needs 3 requirements to plot a VOTable:

        i.- the Table must have a name (only VOTables with <TABLE  
name="whatever"> looks to work
        ii.- utype in x and y coordinates in FIELD must be specified

       c.2) VOSpec needs two (non-standard) <PARAM...> lines to  
specify the columns and only
               two columns can be plotted (i.e. do not include for  
example a column with errors that would be
               useful for both observations and theoretical data.

   Finally, for theoretical SEDs, they are some times stored in a  
multicolumn format, I have not tested
with spectview, but it is not supported by VOSpec.

d) A final comment, it looks that only VOSpec is able to manage a  
Theoretical spectral acces protocol:
It means, perform the query to a server that gives back a table with  
the parameter space covered by the
models that the server provides, and perform a "second" query over a  
subsample of the parameter space covered.



I hope that this comments would help to improve the applications and  
for the theory group

best regards

	Miguel Cervi?o



From mcs at iaa.es  Thu May  4 05:42:34 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 4 May 2006 14:42:34 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>

Dear all,

I just send this comments that may be discussed in the next meeting.
It is just a comparison about how different VO applications manage
a SED building following the SED data model requirements.
The applications compared are VOSpec, specview, topcat, and VOplot.
(Note that topcat and VOplot are general propose tools and VOSpec and
specview are specific for SEDs).

I had find that more or less the current SED data model is fine for  
theory,
and may be, model parameters should be specified in  <GROUP> ...</GROUP>
fields for characterization or provenance (it is an issue to be  
defined in
the theory group). Note that in the theoretical domain, the  
parameters that
define the model are equally relevant than the model results themselves.

However, for the case of applications, (visualization tools mainly) I  
had found some
inconsistence/problems with a VOTable designed in such a way, and  
also internal inconsistency
between different tools. I summarize them here:

a) problem with units nomenclature: There is no recommendation about  
the use of units in the VOTable
fields. In particular, VOSpec and specview use different ways to  
define the units for the flux
e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be  
possible to define any
recommendation about that? Otherwise the same VOTable would not be
used for both applications!

b) Metadata and saved files: As pointed before, metadata in  
theoretical models are fundamental to
understand and perform any posterior analysis or comparison with real  
data (or "pipeline" process
for datamining as example). Again, metadata are sometimes equal in  
importance than the simulation result. However:

   - the VOTable metadata are not visualized by VOSpec, sepcview and  
VOPlot
   - metadata otuside <GROUP> are visualized by Topcat, but not  
metadata in <GROUP>...</GROUP>
         (so may be the use of a <GROUP> for characterization of the  
model is not a good idea after all...)

About the VOTables that can be saved by VOSpec, specview and Topcat  
(VOPlot do not save VOTables)
it is found that metadata is systematically lost!! (it means, such  
type of applications are not completely suitable
to retrieve theoretical models thought the VO registry for their  
posterior use!). In particular:

   - specview: do not include niether the original VOTable  <GROUP>  
of <PARAM> but include their own
         <GROUP> and <PARAM>'s
  -  VOSpec  do not include the original metadata
  - and  VOTables saved by topcat include table metadata but
       all <GROUP> parameters are lost.


c) Columns to be plotted:

      c.1) specview needs 3 requirements to plot a VOTable:

        i.- the Table must have a name (only VOTables with <TABLE  
name="whatever"> looks to work
        ii.- utype in x and y coordinates in FIELD must be specified

       c.2) VOSpec needs two (non-standard) <PARAM...> lines to  
specify the columns and only
               two columns can be plotted (i.e. do not include for  
example a column with errors that would be
               useful for both observations and theoretical data.

   Finally, for theoretical SEDs, they are some times stored in a  
multicolumn format, I have not tested
with spectview, but it is not supported by VOSpec.

d) A final comment, it looks that only VOSpec is able to manage a  
Theoretical spectral acces protocol:
It means, perform the query to a server that gives back a table with  
the parameter space covered by the
models that the server provides, and perform a "second" query over a  
subsample of the parameter space covered.



I hope that this comments would help to improve the applications and  
for the theory group

best regards

	Miguel Cervi?o



From boch at newb6.u-strasbg.fr  Thu May  4 06:18:38 2006
From: boch at newb6.u-strasbg.fr (Thomas Boch)
Date: Thu, 04 May 2006 15:18:38 +0200
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <4459FF2E.A38836FB@newb6.u-strasbg.fr>

Dear Miguel,

I'd like to comment your first point.

> 
> a) problem with units nomenclature: There is no recommendation about
> the use of units in the VOTable
> fields. In particular, VOSpec and specview use different ways to
> define the units for the flux
> e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be
> possible to define any
> recommendation about that? Otherwise the same VOTable would not be
> used for both applications!

Section 4.3 of the VOTable document (
http://www.ivoa.net/Documents/latest/VOT.html ) gives a reference (
http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) about how units should
be expressed.
According to this section, $cm^2$ should be defined in a VOTable field
as unit="cm2"

Cheers,

Thomas


From boch at newb6.u-strasbg.fr  Thu May  4 06:18:38 2006
From: boch at newb6.u-strasbg.fr (Thomas Boch)
Date: Thu, 04 May 2006 15:18:38 +0200
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <4459FF2E.A38836FB@newb6.u-strasbg.fr>

Dear Miguel,

I'd like to comment your first point.

> 
> a) problem with units nomenclature: There is no recommendation about
> the use of units in the VOTable
> fields. In particular, VOSpec and specview use different ways to
> define the units for the flux
> e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). Would it be
> possible to define any
> recommendation about that? Otherwise the same VOTable would not be
> used for both applications!

Section 4.3 of the VOTable document (
http://www.ivoa.net/Documents/latest/VOT.html ) gives a reference (
http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) about how units should
be expressed.
According to this section, $cm^2$ should be defined in a VOTable field
as unit="cm2"

Cheers,

Thomas


From rplante at ncsa.uiuc.edu  Thu May  4 08:57:04 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 10:57:04 -0500 (CDT)
Subject: How to Publish to the NVO
Message-ID: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>

Gentle Theorists,

During a recent chat, Sebastien Derriere reported on a meeting of 
VOTheorists in which there was some discussion of how one should publish 
simulation data and/or services to the VO.  I thought that I would mention 
a document I wrote for the NVO called "How to Publish to the NVO".  It's 
meant to be a brief introduction to VO publishing with pointers to how to 
get started.  It's a little out of date at the moment (an update is in the 
works), but it is not inaccurate.  I would be interested to get some 
feedback from your group about how applicable you feel it is to 
theory-related resources.  In particular, if you have suggestions for 
addressing the theory community, this would get a great time to get those.  

In the VO, we talk a lot about registering standard services like SIA and 
SkyNodes.  However you may not be aware that it is currently possible to 
register general data collections and non-standard services, including 
those that have a web-page interface.  While I'm sure that you will 
benefit from some standards that are specifically targetted to the theory 
community in the future, you may find the generic resource descriptions 
useful today.  In fact, I would encourage you to visit the registry at 
NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try registering 
somethings.  This site provides a sandbox version that allows you to try 
out the interface without actually publishing anything.  

Finally, to the Registry WG, it's been suggested that we take a look at 
this document and see if there is an IVOA version we might publish as a 
note.  Your feedback is welcome as well.  

cheers,
Ray



From rplante at ncsa.uiuc.edu  Thu May  4 08:57:04 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 10:57:04 -0500 (CDT)
Subject: How to Publish to the NVO
Message-ID: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>

Gentle Theorists,

During a recent chat, Sebastien Derriere reported on a meeting of 
VOTheorists in which there was some discussion of how one should publish 
simulation data and/or services to the VO.  I thought that I would mention 
a document I wrote for the NVO called "How to Publish to the NVO".  It's 
meant to be a brief introduction to VO publishing with pointers to how to 
get started.  It's a little out of date at the moment (an update is in the 
works), but it is not inaccurate.  I would be interested to get some 
feedback from your group about how applicable you feel it is to 
theory-related resources.  In particular, if you have suggestions for 
addressing the theory community, this would get a great time to get those.  

In the VO, we talk a lot about registering standard services like SIA and 
SkyNodes.  However you may not be aware that it is currently possible to 
register general data collections and non-standard services, including 
those that have a web-page interface.  While I'm sure that you will 
benefit from some standards that are specifically targetted to the theory 
community in the future, you may find the generic resource descriptions 
useful today.  In fact, I would encourage you to visit the registry at 
NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try registering 
somethings.  This site provides a sandbox version that allows you to try 
out the interface without actually publishing anything.  

Finally, to the Registry WG, it's been suggested that we take a look at 
this document and see if there is an IVOA version we might publish as a 
note.  Your feedback is welcome as well.  

cheers,
Ray



From rplante at ncsa.uiuc.edu  Thu May  4 09:16:32 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 11:16:32 -0500 (CDT)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0605041115420.5042-100000@poplar.ncsa.uiuc.edu>

On Thu, 4 May 2006, Ray Plante wrote:
> Gentle Theorists,
> 
> I thought that I would mention 
> a document I wrote for the NVO called "How to Publish to the NVO".  

I guess I should provide you with an actual pointer to the document, 
right?   http://us-vo.org/pubs/files/PublishHowTo.html

cheers,
Ray


From rplante at ncsa.uiuc.edu  Thu May  4 09:16:32 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 11:16:32 -0500 (CDT)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0605041115420.5042-100000@poplar.ncsa.uiuc.edu>

On Thu, 4 May 2006, Ray Plante wrote:
> Gentle Theorists,
> 
> I thought that I would mention 
> a document I wrote for the NVO called "How to Publish to the NVO".  

I guess I should provide you with an actual pointer to the document, 
right?   http://us-vo.org/pubs/files/PublishHowTo.html

cheers,
Ray


From m.b.taylor at bristol.ac.uk  Thu May  4 11:02:16 2006
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 4 May 2006 19:02:16 +0100 (BST)
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <Pine.LNX.4.44.0605041841590.31496-100000@andromeda.star.bris.ac.uk>

On Thu, 4 May 2006, Miguel Cervi?o wrote:

> Dear all,
> 
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> The applications compared are VOSpec, specview, topcat, and VOplot.
> (Note that topcat and VOplot are general propose tools and VOSpec and
> specview are specific for SEDs).

Miguel,

thanks for this posting.  This kind of detailed feedback on what
does and doesn't work, and what you want to see, is useful for 
application developers (well, I speak for myself in any case).

As you say, TOPCAT doesn't pay much attention to GROUP elements at
present.  I believe what it does is to behave as if GROUP elements
(though not their contents) are not there, so the grouping will be 
lost, but columns and parameters within the group will not.  
It also ignores table structure (for instance RESOURCEs within 
RESOURCEs) in a similar way.  Trying to do improve this kind of 
table metadata retention for VOTables is on the to-do list, 
but not currently very near the top (there are some technical 
difficulties which I will forbear to explain).  However, if it's 
something which the theory community (and others?) see as important 
I can see about prioritising it.  Ranking on the to-do list is 
influenced by user requests; I have had a few requests for this 
in the past but not that many.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



From m.b.taylor at bristol.ac.uk  Thu May  4 11:02:16 2006
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 4 May 2006 19:02:16 +0100 (BST)
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <Pine.LNX.4.44.0605041841590.31496-100000@andromeda.star.bris.ac.uk>

On Thu, 4 May 2006, Miguel Cervi?o wrote:

> Dear all,
> 
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> The applications compared are VOSpec, specview, topcat, and VOplot.
> (Note that topcat and VOplot are general propose tools and VOSpec and
> specview are specific for SEDs).

Miguel,

thanks for this posting.  This kind of detailed feedback on what
does and doesn't work, and what you want to see, is useful for 
application developers (well, I speak for myself in any case).

As you say, TOPCAT doesn't pay much attention to GROUP elements at
present.  I believe what it does is to behave as if GROUP elements
(though not their contents) are not there, so the grouping will be 
lost, but columns and parameters within the group will not.  
It also ignores table structure (for instance RESOURCEs within 
RESOURCEs) in a similar way.  Trying to do improve this kind of 
table metadata retention for VOTables is on the to-do list, 
but not currently very near the top (there are some technical 
difficulties which I will forbear to explain).  However, if it's 
something which the theory community (and others?) see as important 
I can see about prioritising it.  Ranking on the to-do list is 
influenced by user requests; I have had a few requests for this 
in the past but not that many.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



From glemson at xray.mpe.mpg.de  Thu May  4 11:14:28 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Thu, 4 May 2006 20:14:28 +0200 (METDST)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.LNX.4.44.0605041039570.5042-100000@poplar.ncsa.uiuc.edu>
Message-ID: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>

Hi Ray

We did indeed came to the conclusion that it should be possible to
register resources without there being a fitting standard
specification/protocol. I would actually like to try to register some
such theory specific services and datasets during the interop, as there we
could benefit from interaction with registry connaiseurs such as you.
Would you be willing and to make a contribution to one of the theory
sessions on Monday to explain this in some more detail ?

Cheers
Gerard

On Thu, 4 May 2006, Ray Plante wrote:

> Gentle Theorists,
> 
> During a recent chat, Sebastien Derriere reported on a meeting of 
> VOTheorists in which there was some discussion of how one should publish 
> simulation data and/or services to the VO.  I thought that I would mention 
> a document I wrote for the NVO called "How to Publish to the NVO".  It's 
> meant to be a brief introduction to VO publishing with pointers to how to 
> get started.  It's a little out of date at the moment (an update is in the 
> works), but it is not inaccurate.  I would be interested to get some 
> feedback from your group about how applicable you feel it is to 
> theory-related resources.  In particular, if you have suggestions for 
> addressing the theory community, this would get a great time to get those.  
> 
> In the VO, we talk a lot about registering standard services like SIA and 
> SkyNodes.  However you may not be aware that it is currently possible to 
> register general data collections and non-standard services, including 
> those that have a web-page interface.  While I'm sure that you will 
> benefit from some standards that are specifically targetted to the theory 
> community in the future, you may find the generic resource descriptions 
> useful today.  In fact, I would encourage you to visit the registry at 
> NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try registering 
> somethings.  This site provides a sandbox version that allows you to try 
> out the interface without actually publishing anything.  
> 
> Finally, to the Registry WG, it's been suggested that we take a look at 
> this document and see if there is an IVOA version we might publish as a 
> note.  Your feedback is welcome as well.  
> 
> cheers,
> Ray
> 
> 


From rplante at ncsa.uiuc.edu  Thu May  4 11:20:06 2006
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Thu, 4 May 2006 13:20:06 -0500 (CDT)
Subject: How to Publish to the NVO
In-Reply-To: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.LNX.4.44.0605041319130.5042-100000@poplar.ncsa.uiuc.edu>

On Thu, 4 May 2006, Gerard Lemson wrote:
> Would you be willing and to make a contribution to one of the theory
> sessions on Monday to explain this in some more detail ?

Sure.  There's the usual juggling of parallel sessions.  I'm slated to 
give a talk at one of the GWS sessions but I'm not sure which, yet.

cheers,
Ray



From Franck.LePetit at obspm.fr  Thu May  4 14:01:36 2006
From: Franck.LePetit at obspm.fr (Franck Le Petit)
Date: Thu, 4 May 2006 23:01:36 +0200
Subject: How to Publish to the NVO
In-Reply-To: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>
References: <Pine.HPX.4.21.0605042010390.2027-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <68D040F3-2B11-46FA-93C1-12A1AF6236B2@obspm.fr>


	Dear Gerard, dear Ray and dear members of VO-Theory

	I followed Ray informations to register my PDR simulation code in  
the NVO registry.
	I did some mistakes (as the creation of an organization and an  
authority which do not want to disappear from the registry.  I hope  
this will be solved soon) but succeeded very easily to register it as  
a service (marked as a skyservice - another little problem)
	It is extremely simple to do.

	Once registered, I tried several searches in the NVO as somebody  
looking for a simulation code of interstellar clouds would do.
	Each time, the NVO search system has been able to find it.

	So, even if there are some points to improve, as Ray said, the way  
the inscription in registries is done can be used for simulations  
with a web interface (webservices as well I guess).

	Best regards and see you in Victoria.
	Franck

PS : For those who wonder, PDR codes are the codes which model the  
physics and the chemistry of interstellar clouds.
PPS: If you try to access the code, you will be blocked by a login  
and password. This is because it gives access to computing facilities  
of the Observatory of Paris. We need a bit more computing power  
before opening completely the access to the codes.

    ------------------------------------
    Franck Le Petit
    LUTH
    Observatoire de Meudon
    5 Place Jules Janssen
    92190 Meudon
    France
    Tel: (33) 1 45 07 75 66
    ------------------------------------


Le 4 mai 06 ? 20:14, Gerard Lemson a ?crit :

> Hi Ray
>
> We did indeed came to the conclusion that it should be possible to
> register resources without there being a fitting standard
> specification/protocol. I would actually like to try to register some
> such theory specific services and datasets during the interop, as  
> there we
> could benefit from interaction with registry connaiseurs such as you.
> Would you be willing and to make a contribution to one of the theory
> sessions on Monday to explain this in some more detail ?
>
> Cheers
> Gerard
>
> On Thu, 4 May 2006, Ray Plante wrote:
>
>> Gentle Theorists,
>>
>> During a recent chat, Sebastien Derriere reported on a meeting of
>> VOTheorists in which there was some discussion of how one should  
>> publish
>> simulation data and/or services to the VO.  I thought that I would  
>> mention
>> a document I wrote for the NVO called "How to Publish to the  
>> NVO".  It's
>> meant to be a brief introduction to VO publishing with pointers to  
>> how to
>> get started.  It's a little out of date at the moment (an update  
>> is in the
>> works), but it is not inaccurate.  I would be interested to get some
>> feedback from your group about how applicable you feel it is to
>> theory-related resources.  In particular, if you have suggestions for
>> addressing the theory community, this would get a great time to  
>> get those.
>>
>> In the VO, we talk a lot about registering standard services like  
>> SIA and
>> SkyNodes.  However you may not be aware that it is currently  
>> possible to
>> register general data collections and non-standard services,  
>> including
>> those that have a web-page interface.  While I'm sure that you will
>> benefit from some standards that are specifically targetted to the  
>> theory
>> community in the future, you may find the generic resource  
>> descriptions
>> useful today.  In fact, I would encourage you to visit the  
>> registry at
>> NCSA (http://nvo.ncsa.uiuc.edu/nvoregistration.html) and try  
>> registering
>> somethings.  This site provides a sandbox version that allows you  
>> to try
>> out the interface without actually publishing anything.
>>
>> Finally, to the Registry WG, it's been suggested that we take a  
>> look at
>> this document and see if there is an IVOA version we might publish  
>> as a
>> note.  Your feedback is welcome as well.
>>
>> cheers,
>> Ray
>>
>>
>



From Jesus.Salgado at sciops.esa.int  Fri May  5 03:48:11 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 12:48:11 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <1146826091.4221.24.camel@isol11.vilspa.esa.int>

Dear Miguel,

Just some comments about your applications benchmark.

Units:
------

> 1. problem with units nomenclature: There is no recommendation about
the use of units in the VOTable fields. In particular, 
> VOSpec and specview use different ways to define the units for the
flux e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). 
> Would it be possible to define any recommendation about that?
Otherwise the same VOTable would not be used for both 
>  applications! 

As you probably know, VOSpec is not using the units string definition
for the units handling but the scaleq and dimeq fields. 
We made the proposal to include this dimensional analysis data to
prevent the problems of multiple unit string convections (among other
things)
You have read it in the SED document, (point 3.2 Units) 
http://hea-www.harvard.edu/~jcm/vo/docs/spec0.93.html
The definition of the scaleq and dimeq syntax is (hopefully) uniform for
all the services, following our recommendation.  In any case, same
VOTables are currently used for both applications, so it looks that the
problem has been solved at application level (for us, using the
dimensional analysis information instead of the unit strings, for others
using aliases and string conversions)

Metadata in VOTable
-------------------

About the VOTable metadata issue, in our view, the information inside
the VOTable response is to be used automatically by the client
application (except for the VOTable editors). 

In case there is no implementation to use specific information in the
VOTable response, there is a risk to lose it. VOSpec is taking the
information for the row where the spectrum is described and it is shown
to the user if the user double-click on one spectrum in the result tree.
This should not be enough in the future, as any essential information
included in the VOTable response should be protocolized in some way to
be properly treated in the client (not only shown). If there is some
information only to be shown to the user linked to one result, probably
the best way to do it for the time being could be to include a link to a
dynamically generated page  (in a format readable by humans).

About the columns for errors, this will be included in VOSpec quite soon
for all the services that can provide them. The only constraint would be
the order of the columns in the ?columns? field.

TSAP:
-----

> d) A final comment, it looks that only VOSpec is able to manage a
Theoretical spectral acces protocol: 
> It means, perform the query to a server that gives back a table with
the parameter space covered by the 
> models that the server provides, and perform a "second" query over a
subsample of the parameter space covered.

This is not quite surprising as we were the ones to propose the
theoretical spectral access protocol in the IVOA. 
As you probably know, we proposed the creation of this kind of server to
the SVO coordinator (Enrique Solano) for the Kurucz models and we
implemented the client part in VOSpec. Some other services were created
later related to SVO and Mexican VO, and we have contacted some others
to create similar services (as the ones from the French VO), so all the
services have been created more or less under our coordination. We think
it is a good first step to include theoretical SEDs in the VO, and easy
to be implemented for SED VO applications.

Best Regards,
Jesus Salgado

ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From Jesus.Salgado at sciops.esa.int  Fri May  5 03:48:11 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 12:48:11 +0200
Subject: tehoretical SEDs in VO applications
Message-ID: <1146826091.4221.24.camel@isol11.vilspa.esa.int>

Dear Miguel,

Just some comments about your applications benchmark.

Units:
------

> 1. problem with units nomenclature: There is no recommendation about
the use of units in the VOTable fields. In particular, 
> VOSpec and specview use different ways to define the units for the
flux e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). 
> Would it be possible to define any recommendation about that?
Otherwise the same VOTable would not be used for both 
>  applications! 

As you probably know, VOSpec is not using the units string definition
for the units handling but the scaleq and dimeq fields. 
We made the proposal to include this dimensional analysis data to
prevent the problems of multiple unit string convections (among other
things)
You have read it in the SED document, (point 3.2 Units) 
http://hea-www.harvard.edu/~jcm/vo/docs/spec0.93.html
The definition of the scaleq and dimeq syntax is (hopefully) uniform for
all the services, following our recommendation.  In any case, same
VOTables are currently used for both applications, so it looks that the
problem has been solved at application level (for us, using the
dimensional analysis information instead of the unit strings, for others
using aliases and string conversions)

Metadata in VOTable
-------------------

About the VOTable metadata issue, in our view, the information inside
the VOTable response is to be used automatically by the client
application (except for the VOTable editors). 

In case there is no implementation to use specific information in the
VOTable response, there is a risk to lose it. VOSpec is taking the
information for the row where the spectrum is described and it is shown
to the user if the user double-click on one spectrum in the result tree.
This should not be enough in the future, as any essential information
included in the VOTable response should be protocolized in some way to
be properly treated in the client (not only shown). If there is some
information only to be shown to the user linked to one result, probably
the best way to do it for the time being could be to include a link to a
dynamically generated page  (in a format readable by humans).

About the columns for errors, this will be included in VOSpec quite soon
for all the services that can provide them. The only constraint would be
the order of the columns in the ?columns? field.

TSAP:
-----

> d) A final comment, it looks that only VOSpec is able to manage a
Theoretical spectral acces protocol: 
> It means, perform the query to a server that gives back a table with
the parameter space covered by the 
> models that the server provides, and perform a "second" query over a
subsample of the parameter space covered.

This is not quite surprising as we were the ones to propose the
theoretical spectral access protocol in the IVOA. 
As you probably know, we proposed the creation of this kind of server to
the SVO coordinator (Enrique Solano) for the Kurucz models and we
implemented the client part in VOSpec. Some other services were created
later related to SVO and Mexican VO, and we have contacted some others
to create similar services (as the ones from the French VO), so all the
services have been created more or less under our coordination. We think
it is a good first step to include theoretical SEDs in the VO, and easy
to be implemented for SED VO applications.

Best Regards,
Jesus Salgado

ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From mcs at iaa.es  Fri May  5 06:37:42 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 5 May 2006 15:37:42 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
Message-ID: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>

Thanks a lot Jesus,

I completely agree with you points, but
only for "increasing" the discussion:

About metadata in the VO table, there is two particular issues
specifically related with theory, and any analysis tool:
Suppouse that you overplot real data and several theoretical models.
And you obtain a good fit of a particular model. If the application  
is not able to show the
model parameters (that should be included somewhere in the VOTable  
metadata), how
can you recover them for, for example, a publication? I would agree  
that an
link to a generated page would be fine, but it would only works for  
catalogs,
and it would not work if the teoretical data is generated by the use  
of diferent
aplications (example a virtual telescope machine). Since model  
parameters should
be included in the VOtable, I think is more easy, and safer, that the  
applications
would be able to show the information that is yet included in the  
VOTable
they manage instead to refer to an external link. Additionally, an  
external link
will make not possible to work with downloaded data without internet  
conexion....

(An specific comment about that is that the providers of synthesis  
models
would not be very happy and may be will not join actively the VO  
iniciative if
they do not obtain credits for the use of their models, and metadata  
is the
only place where such a credit can be written explicitelly, including  
references to
the models papers etc...)

And about TSAP, yes, I know (I had been also working) it ;)
However, most of VOtools applications are not designed to
support a TSAP-like protocol: Obtain a parameter VOTable and
process it before access the data.... Maybe is time that other
applications also will think about this kind of implementation, isn't  
it?

cheers

	miguel



From mcs at iaa.es  Fri May  5 06:37:42 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 5 May 2006 15:37:42 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
Message-ID: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>

Thanks a lot Jesus,

I completely agree with you points, but
only for "increasing" the discussion:

About metadata in the VO table, there is two particular issues
specifically related with theory, and any analysis tool:
Suppouse that you overplot real data and several theoretical models.
And you obtain a good fit of a particular model. If the application  
is not able to show the
model parameters (that should be included somewhere in the VOTable  
metadata), how
can you recover them for, for example, a publication? I would agree  
that an
link to a generated page would be fine, but it would only works for  
catalogs,
and it would not work if the teoretical data is generated by the use  
of diferent
aplications (example a virtual telescope machine). Since model  
parameters should
be included in the VOtable, I think is more easy, and safer, that the  
applications
would be able to show the information that is yet included in the  
VOTable
they manage instead to refer to an external link. Additionally, an  
external link
will make not possible to work with downloaded data without internet  
conexion....

(An specific comment about that is that the providers of synthesis  
models
would not be very happy and may be will not join actively the VO  
iniciative if
they do not obtain credits for the use of their models, and metadata  
is the
only place where such a credit can be written explicitelly, including  
references to
the models papers etc...)

And about TSAP, yes, I know (I had been also working) it ;)
However, most of VOtools applications are not designed to
support a TSAP-like protocol: Obtain a parameter VOTable and
process it before access the data.... Maybe is time that other
applications also will think about this kind of implementation, isn't  
it?

cheers

	miguel



From Jesus.Salgado at sciops.esa.int  Fri May  5 07:35:04 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 16:35:04 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
 <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
Message-ID: <1146839704.4221.66.camel@isol11.vilspa.esa.int>

Hi Miguel,

On Fri, 2006-05-05 at 15:37 +0200, Miguel Cervi?o wrote:
> Thanks a lot Jesus,
> 
> I completely agree with you points, but
> only for "increasing" the discussion:
> 
> About metadata in the VO table, there is two particular issues
> specifically related with theory, and any analysis tool:
> Suppouse that you overplot real data and several theoretical models.
> And you obtain a good fit of a particular model. If the application  
> is not able to show the
> model parameters (that should be included somewhere in the VOTable  
> metadata), how
> can you recover them for, for example, a publication? I would agree  
> that an
> link to a generated page would be fine, but it would only works for  
> catalogs,
> and it would not work if the teoretical data is generated by the use  
> of diferent
> aplications (example a virtual telescope machine). Since model  
> parameters should
> be included in the VOtable, I think is more easy, and safer, that the  
> applications
> would be able to show the information that is yet included in the  
> VOTable
> they manage instead to refer to an external link. Additionally, an  
> external link
> will make not possible to work with downloaded data without internet  
> conexion....
> 

In this particular case, I would put the metadata to identify the
spectrum inside the spectrum itself, e.g., inside the header in case of
a fits or inside the votable spectrum in case of a votable spectrum. 
In this case, the file downloaded would be self-consistent and the model
provider will be sure that all the information to properly "understand"
the spectrum is there after saving the file. If I remember correctly,
all the applications have a save function for the file itself, so this
approach would work for all the VO applications. (in the case of VOSpec,
clicking twice on one spectrum, a window appears with a Save button)

Probably, there is room to more specific metadata in the VOTable
response (in particular publications links should be understood better
in the clients) but, except for the VOTable editors, many of the
metadata will be ignored by the VO clients. 
On the other hand, and probably because of the same reason, the VO
clients do not save the VOTable responses but only the data link files.

There is a problem added to save VOTable responses. For the client, the
result is a combination of several VOTables from different servers, so
the only two ways that I see to save the metadata is either saving every
single VOTable or to create a VOTable as a combination of several
heterogeneous VOTables (really a mess if we want to maintain this result
VOTable as something usable as input for future e.g. VOSpec sessions)

> (An specific comment about that is that the providers of synthesis  
> models
> would not be very happy and may be will not join actively the VO  
> iniciative if
> they do not obtain credits for the use of their models, and metadata  
> is the
> only place where such a credit can be written explicitelly, including  
> references to
> the models papers etc...)
> 
> And about TSAP, yes, I know (I had been also working) it ;)
> However, most of VOtools applications are not designed to
> support a TSAP-like protocol: Obtain a parameter VOTable and
> process it before access the data.... Maybe is time that other
> applications also will think about this kind of implementation, isn't  
> it?
> 
I agree with you as the implementation of TSAP for a VO SED client
application is quite easy and can be done for other applications.

During the presentation in Kyoto, it was agreed to include TSAP as a
particular case of SSAP. The only thing to be changed in the SSAP was to
demote the position compulsory input to optional, as "position" is
meaningless for most of the model servers. 
The call to the format=metadata was something standard to create
specific queries to servers and it should be already implemented in the
clients, but most of the VO applications create "blind" queries using
only the compulsory parameters (what it represents a problem for the
TSAP implementations)

In any case, the creation of on-the-fly query forms using the
format=metadata VOTables (or other more complex response in the future,
in case of evolution) should not be a major problem.


> cheers
> 
> 	miguel
> 
> 
Best Regards,
-- 
Jesus J. Salgado


ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From Jesus.Salgado at sciops.esa.int  Fri May  5 07:35:04 2006
From: Jesus.Salgado at sciops.esa.int (Jesus Salgado)
Date: Fri, 05 May 2006 16:35:04 +0200
Subject: tehoretical SEDs in VO applications
In-Reply-To: <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
References: <1146826091.4221.24.camel@isol11.vilspa.esa.int>
 <AD085FB1-D724-434C-8E5D-EEF0AC968862@iaa.es>
Message-ID: <1146839704.4221.66.camel@isol11.vilspa.esa.int>

Hi Miguel,

On Fri, 2006-05-05 at 15:37 +0200, Miguel Cervi?o wrote:
> Thanks a lot Jesus,
> 
> I completely agree with you points, but
> only for "increasing" the discussion:
> 
> About metadata in the VO table, there is two particular issues
> specifically related with theory, and any analysis tool:
> Suppouse that you overplot real data and several theoretical models.
> And you obtain a good fit of a particular model. If the application  
> is not able to show the
> model parameters (that should be included somewhere in the VOTable  
> metadata), how
> can you recover them for, for example, a publication? I would agree  
> that an
> link to a generated page would be fine, but it would only works for  
> catalogs,
> and it would not work if the teoretical data is generated by the use  
> of diferent
> aplications (example a virtual telescope machine). Since model  
> parameters should
> be included in the VOtable, I think is more easy, and safer, that the  
> applications
> would be able to show the information that is yet included in the  
> VOTable
> they manage instead to refer to an external link. Additionally, an  
> external link
> will make not possible to work with downloaded data without internet  
> conexion....
> 

In this particular case, I would put the metadata to identify the
spectrum inside the spectrum itself, e.g., inside the header in case of
a fits or inside the votable spectrum in case of a votable spectrum. 
In this case, the file downloaded would be self-consistent and the model
provider will be sure that all the information to properly "understand"
the spectrum is there after saving the file. If I remember correctly,
all the applications have a save function for the file itself, so this
approach would work for all the VO applications. (in the case of VOSpec,
clicking twice on one spectrum, a window appears with a Save button)

Probably, there is room to more specific metadata in the VOTable
response (in particular publications links should be understood better
in the clients) but, except for the VOTable editors, many of the
metadata will be ignored by the VO clients. 
On the other hand, and probably because of the same reason, the VO
clients do not save the VOTable responses but only the data link files.

There is a problem added to save VOTable responses. For the client, the
result is a combination of several VOTables from different servers, so
the only two ways that I see to save the metadata is either saving every
single VOTable or to create a VOTable as a combination of several
heterogeneous VOTables (really a mess if we want to maintain this result
VOTable as something usable as input for future e.g. VOSpec sessions)

> (An specific comment about that is that the providers of synthesis  
> models
> would not be very happy and may be will not join actively the VO  
> iniciative if
> they do not obtain credits for the use of their models, and metadata  
> is the
> only place where such a credit can be written explicitelly, including  
> references to
> the models papers etc...)
> 
> And about TSAP, yes, I know (I had been also working) it ;)
> However, most of VOtools applications are not designed to
> support a TSAP-like protocol: Obtain a parameter VOTable and
> process it before access the data.... Maybe is time that other
> applications also will think about this kind of implementation, isn't  
> it?
> 
I agree with you as the implementation of TSAP for a VO SED client
application is quite easy and can be done for other applications.

During the presentation in Kyoto, it was agreed to include TSAP as a
particular case of SSAP. The only thing to be changed in the SSAP was to
demote the position compulsory input to optional, as "position" is
meaningless for most of the model servers. 
The call to the format=metadata was something standard to create
specific queries to servers and it should be already implemented in the
clients, but most of the VO applications create "blind" queries using
only the compulsory parameters (what it represents a problem for the
TSAP implementations)

In any case, the creation of on-the-fly query forms using the
format=metadata VOTables (or other more complex response in the future,
in case of evolution) should not be a major problem.


> cheers
> 
> 	miguel
> 
> 
Best Regards,
-- 
Jesus J. Salgado


ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From glemson at xray.mpe.mpg.de  Tue May  9 20:23:55 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Wed, 10 May 2006 05:23:55 +0200 (METDST)
Subject: agenda
Message-ID: <Pine.HPX.4.21.0605100520350.15277-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
The current agenda for the theory sessions is posted on the meeting's
theory site, http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006Theory. 
It is not final as I am still waiting for some replies to requests.
But please let me know any questions you have already.
Note that I am currently already in Victoria, thus 9 hours out of synch
with Middle-European time.
Regards
Gerard


From andrea.preitemartinez at iasf-roma.inaf.it  Sun May 14 23:48:36 2006
From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez)
Date: Mon, 15 May 2006 08:48:36 +0200
Subject: UCD's for simulations
In-Reply-To: <Pine.GSO.4.58.0604142228280.6904@cass25>
References: <ODENKDLEINNEPJOIJLEFAELDCNAA.gerard.lemson@mpe.mpg.de>
	<Pine.GSO.4.58.0604142228280.6904@cass25>
Message-ID: <20060515084836.7xzmd39g4gk0c8ww@webmail.sic.rm.cnr.it>

Dear Laurie,

I've been collecting various proposal for upgrading the list of  
UCD-words, and I'll present these proposal for discussion (including  
yours) during the UCD/Semantic session (thu 18, 9.00-10.30).

The list of proposed modifications and the agenda can be found at
http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD

Regards,

Andrea
===================================================================================
Andrea Preite Martinez                 andrea.preitemartinez at iasf-roma.inaf.it
IASF                                   Tel.IASF:+39.06.4993.4651
Via del Fosso del Cavaliere 100        Tel.CDS :+33.3.90242473
I-00133 Roma                           Cell.1  :+39.320.43.15.383
                                        Cell.2  :+39.339.38.17.355
===================================================================================


Quoting Laurie Shaw <lds at ast.cam.ac.uk>:

>
> Dear All,
>
> I've recently been experimenting with assigning UCDs to the results of
> some cosmological simulations -- specifically to catalogues of dark
> matter halos and their associated subhalos. In general, i've found
> that the existing UCD tree is able to describe most of the properties of
> these objects that are typically analysed in the literature, albeit with a
> few exceptions.
>
> However, it is not currently possible to describe the properties and
> parameters of the simulations themselves. This includes some input
> physical parameters (i.e. cosmological parameters) that define the
> theoretical context of the simulation, and technical
> parameters that define its size,scope and resolution (e.g number of
> particles, length of simulation box side, gravitational
> softening length, time/redshift of a simulation output).
>
> Therefore, for the latter, I propose a new branch of the UCD tree to
> encompass computatational techniques in astronomy: 'comp'. This
> branch can be used to describe both astrophysical (and cosmological)
> simulations, and data reduction and post-processing algorithms for
> both simulation and observational data. It is roughly a computing
> analogue of the 'instr' branch. For the case of simulations I propose
> the following sub-branches
>
> comp.sim		(computational simulation)
> comp.sim.nbody		(Nbody simulation)
> comp.sim.sph		(Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside	(Simulation box)
> comp.sim.gravsoft	(gravitational softening)
> comp.sim.particles	(simulation particles (for Nbody and SPH
> simulations))
> comp.sim.snapshot	(output of a simulation box at a particular
> instant)
> comp.sim.grid		(simulation grid (for hydro simulations))
>
> The number of particles in the simulation box, number of grid points,
> particle mass, gravitational softening length and simulation box side
> length would therefore be:
>
> meta.num;comp.sim.particles
> meta.num;comp.sim.grid
> phys.mass;comp.sim.particles
> phys.size;comp.sim.gravsoft
> phys.size;comp.sim.boxside
>
> (For the last two, introduction of a phys.size.length UCD might provide a
> more accurate description.)
>
> The mass of an object in terms of the number of particles it contains:
>
> phys.mass;meta.num;comp.sim.particles
>
> Other possible sub-branches could be
>
> comp.resourse	         (computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory	 (total size of a data file)
>
> plus those that are more specific to data-reduction/post-processing of
> observational data.  Algorithms that might apply to both simulated and
> observed data (e.g. smoothing of images or particle densities) would
> be listed directly under the comp branch:
>
> phys.size;comp.smooth
> (or, with the introduction of a phys.size.length UCD:
> phys.size.length;comp.smooth)
>
> Physical Parameters
> ---------------------
> Currently, there exists no UCDs for the main cosmological
> parameters. In terms of simulations, it is very important to be able
> define the assumed cosmology, when interpreting the results. To
> describe these parameters I propose a 'cosmology' sub-branch of
> the phys branch. So,
>
> phys.cosmology		(cosmology)
> phys.cosmology.omega 	(matter/energy density of universe)
> phys.cosmology.hubble 	(hubble constant)
> phys.cosmology.sigma8 	(Normalisation of matter power-spectrum)
>
> and also:
>
> phys.matter.dark 	(dark matter tag)
> phys.matter.baryon 	(baryonic matter tag)
> phys.DarkEnergy 	(dark energy tag)
>
> So, Omega_Lambda, Omega_DM, Omega_baryon would be
>
> phys.cosmology.omega;phys.DarkEnery,
> phys.cosmology.omega;phys.matter.dark
> phys.comsology.omega;phys.matter.baryonic
>
> Now we can also describe the number of dark matter (gas particles) in
> an SPH simulation, or a simulated object (star/galaxy/halo) using:
>
> meta.num;comp.sim.particles;phys.matter.dark(/baryonic)
>
> Furthermore, the mass and radius of dark matter halos in cosmological
> simulations are frequently defined in terms of a virial
> overdensity. Hence a phys.virial UCD would be usefull in specifying
> what is meant by the mass and radius of a halo:
>
> phys.mass;phys.virial (virial mass)
> phys.size.radius;phys.virial (virial radius)
>
> Time in Simulations
> ------------------
> People frequently analyse the output of simulations, or snapshots, at
> a series of different timesteps. This is often quoted in terms of the
> redshift of
> the snapshot. At the moment, redshift exists under the 'src'
> branch. Maybe it might be better under the `phys' branch as it is a
> measure of both distance and time, and can therefore be used to label
> both the distance of observed objects and to label a time-stamp for
> simulation snapshots:
>
> phys.redshift;comp.sim.snapshot
>
> Astrophysical Objects
> --------------------
> Another problem is the listing of astronomical objects types under the
> 'src' branch. This introduces confusion when trying to describe a
> simulated astrophysical object. For example, the first word in
> src.class.galaxy;comp.sim (simulated galaxy) implies that this is an
> observed astrophysical source, the second that it is simulated.
>
> Additionally, objects such as halos and subhalos are not typically
> observed (though i guess people do make estimates of their mass/size
> through
> gravitational lensing). It seems strange to have halo and subhalo
> listed under the src.class sub-branch. I therefore suggest that an
> object branch be introduced in which astrophysical (and theoretical)
> objects can be listed (as also proposed by others on the UCD suggestion
> page):
>
> object.galaxy;comp.sim (a simulated galaxy)
> object.galaxy.spiral;comp.sim (a simulated spiral galaxy)
>
> One example that I encountered of an actual quantity where this was
> useful is describing the mass in substructure, or the number of
> subhalos, in a simulated halo:
>
> phys.mass;object.DMhalo.subhalo
> meta.num;onject.DMhalo.subhalo
>
> It would be great to hear everyones thoughts, or ideas for alternative
> approaches, for all these.
>
> Cheers,
>
> Laurie
>
>
> List of Proposed UCDs
> ---------------------
> comp (computational astronomy)
> comp.sim (simulations)
> comp.sim.nbody (Nbody simulation)
> comp.sim.sph (Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside (Simulation box)
> comp.sim.gravsoft (gravitational softening)
> comp.sim.particles (simulation particles (for Nbody and SPH simulations))
> comp.sim.snapshot (output of a simulation box at a particular instant)
> comp.sim.grid (simulation grid (for hydro simulations))
> comp.resourse (to describe computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory (total size on disk of data)
> (comp.dataReduct ?
> comp.algorithm (general algorithms applied to sim/obs data) )
>
> phys.cosmology
> phys.cosmology.omega (matter/energy density of universe)
> phys.cosmology.hubble (hubble constant)
> phys.cosmology.sigma8 (Normalisation of matter power-spectrum)
> phys.matter.dark (dark matter tag)
> phys.matter.baryon (baryonic matter tag)
> phys.DarkEnergy (dark energy tag)
> phys.virial
> phys.size.length
>
> object  (astophysical object)
> object.planet (planet)
> object.satellite
> object.star   (star)
> object.galaxy (galaxy)
> object.DMhalo (DM halo)
> Object.DMhalo.subhalo (DM subhalo)
> etc
>
>
>






From andrea.preitemartinez at iasf-roma.inaf.it  Sun May 14 23:48:36 2006
From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez)
Date: Mon, 15 May 2006 08:48:36 +0200
Subject: UCD's for simulations
In-Reply-To: <Pine.GSO.4.58.0604142228280.6904@cass25>
References: <ODENKDLEINNEPJOIJLEFAELDCNAA.gerard.lemson@mpe.mpg.de>
	<Pine.GSO.4.58.0604142228280.6904@cass25>
Message-ID: <20060515084836.7xzmd39g4gk0c8ww@webmail.sic.rm.cnr.it>

Dear Laurie,

I've been collecting various proposal for upgrading the list of  
UCD-words, and I'll present these proposal for discussion (including  
yours) during the UCD/Semantic session (thu 18, 9.00-10.30).

The list of proposed modifications and the agenda can be found at
http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD

Regards,

Andrea
===================================================================================
Andrea Preite Martinez                 andrea.preitemartinez at iasf-roma.inaf.it
IASF                                   Tel.IASF:+39.06.4993.4651
Via del Fosso del Cavaliere 100        Tel.CDS :+33.3.90242473
I-00133 Roma                           Cell.1  :+39.320.43.15.383
                                        Cell.2  :+39.339.38.17.355
===================================================================================


Quoting Laurie Shaw <lds at ast.cam.ac.uk>:

>
> Dear All,
>
> I've recently been experimenting with assigning UCDs to the results of
> some cosmological simulations -- specifically to catalogues of dark
> matter halos and their associated subhalos. In general, i've found
> that the existing UCD tree is able to describe most of the properties of
> these objects that are typically analysed in the literature, albeit with a
> few exceptions.
>
> However, it is not currently possible to describe the properties and
> parameters of the simulations themselves. This includes some input
> physical parameters (i.e. cosmological parameters) that define the
> theoretical context of the simulation, and technical
> parameters that define its size,scope and resolution (e.g number of
> particles, length of simulation box side, gravitational
> softening length, time/redshift of a simulation output).
>
> Therefore, for the latter, I propose a new branch of the UCD tree to
> encompass computatational techniques in astronomy: 'comp'. This
> branch can be used to describe both astrophysical (and cosmological)
> simulations, and data reduction and post-processing algorithms for
> both simulation and observational data. It is roughly a computing
> analogue of the 'instr' branch. For the case of simulations I propose
> the following sub-branches
>
> comp.sim		(computational simulation)
> comp.sim.nbody		(Nbody simulation)
> comp.sim.sph		(Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside	(Simulation box)
> comp.sim.gravsoft	(gravitational softening)
> comp.sim.particles	(simulation particles (for Nbody and SPH
> simulations))
> comp.sim.snapshot	(output of a simulation box at a particular
> instant)
> comp.sim.grid		(simulation grid (for hydro simulations))
>
> The number of particles in the simulation box, number of grid points,
> particle mass, gravitational softening length and simulation box side
> length would therefore be:
>
> meta.num;comp.sim.particles
> meta.num;comp.sim.grid
> phys.mass;comp.sim.particles
> phys.size;comp.sim.gravsoft
> phys.size;comp.sim.boxside
>
> (For the last two, introduction of a phys.size.length UCD might provide a
> more accurate description.)
>
> The mass of an object in terms of the number of particles it contains:
>
> phys.mass;meta.num;comp.sim.particles
>
> Other possible sub-branches could be
>
> comp.resourse	         (computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory	 (total size of a data file)
>
> plus those that are more specific to data-reduction/post-processing of
> observational data.  Algorithms that might apply to both simulated and
> observed data (e.g. smoothing of images or particle densities) would
> be listed directly under the comp branch:
>
> phys.size;comp.smooth
> (or, with the introduction of a phys.size.length UCD:
> phys.size.length;comp.smooth)
>
> Physical Parameters
> ---------------------
> Currently, there exists no UCDs for the main cosmological
> parameters. In terms of simulations, it is very important to be able
> define the assumed cosmology, when interpreting the results. To
> describe these parameters I propose a 'cosmology' sub-branch of
> the phys branch. So,
>
> phys.cosmology		(cosmology)
> phys.cosmology.omega 	(matter/energy density of universe)
> phys.cosmology.hubble 	(hubble constant)
> phys.cosmology.sigma8 	(Normalisation of matter power-spectrum)
>
> and also:
>
> phys.matter.dark 	(dark matter tag)
> phys.matter.baryon 	(baryonic matter tag)
> phys.DarkEnergy 	(dark energy tag)
>
> So, Omega_Lambda, Omega_DM, Omega_baryon would be
>
> phys.cosmology.omega;phys.DarkEnery,
> phys.cosmology.omega;phys.matter.dark
> phys.comsology.omega;phys.matter.baryonic
>
> Now we can also describe the number of dark matter (gas particles) in
> an SPH simulation, or a simulated object (star/galaxy/halo) using:
>
> meta.num;comp.sim.particles;phys.matter.dark(/baryonic)
>
> Furthermore, the mass and radius of dark matter halos in cosmological
> simulations are frequently defined in terms of a virial
> overdensity. Hence a phys.virial UCD would be usefull in specifying
> what is meant by the mass and radius of a halo:
>
> phys.mass;phys.virial (virial mass)
> phys.size.radius;phys.virial (virial radius)
>
> Time in Simulations
> ------------------
> People frequently analyse the output of simulations, or snapshots, at
> a series of different timesteps. This is often quoted in terms of the
> redshift of
> the snapshot. At the moment, redshift exists under the 'src'
> branch. Maybe it might be better under the `phys' branch as it is a
> measure of both distance and time, and can therefore be used to label
> both the distance of observed objects and to label a time-stamp for
> simulation snapshots:
>
> phys.redshift;comp.sim.snapshot
>
> Astrophysical Objects
> --------------------
> Another problem is the listing of astronomical objects types under the
> 'src' branch. This introduces confusion when trying to describe a
> simulated astrophysical object. For example, the first word in
> src.class.galaxy;comp.sim (simulated galaxy) implies that this is an
> observed astrophysical source, the second that it is simulated.
>
> Additionally, objects such as halos and subhalos are not typically
> observed (though i guess people do make estimates of their mass/size
> through
> gravitational lensing). It seems strange to have halo and subhalo
> listed under the src.class sub-branch. I therefore suggest that an
> object branch be introduced in which astrophysical (and theoretical)
> objects can be listed (as also proposed by others on the UCD suggestion
> page):
>
> object.galaxy;comp.sim (a simulated galaxy)
> object.galaxy.spiral;comp.sim (a simulated spiral galaxy)
>
> One example that I encountered of an actual quantity where this was
> useful is describing the mass in substructure, or the number of
> subhalos, in a simulated halo:
>
> phys.mass;object.DMhalo.subhalo
> meta.num;onject.DMhalo.subhalo
>
> It would be great to hear everyones thoughts, or ideas for alternative
> approaches, for all these.
>
> Cheers,
>
> Laurie
>
>
> List of Proposed UCDs
> ---------------------
> comp (computational astronomy)
> comp.sim (simulations)
> comp.sim.nbody (Nbody simulation)
> comp.sim.sph (Smoothed Particle Hydrodynamics simulation)
> comp.sim.boxside (Simulation box)
> comp.sim.gravsoft (gravitational softening)
> comp.sim.particles (simulation particles (for Nbody and SPH simulations))
> comp.sim.snapshot (output of a simulation box at a particular instant)
> comp.sim.grid (simulation grid (for hydro simulations))
> comp.resourse (to describe computational resources used in simulation/data
> processing)
> comp.resource.processors (processors used)
> comp.resource.memory (total size on disk of data)
> (comp.dataReduct ?
> comp.algorithm (general algorithms applied to sim/obs data) )
>
> phys.cosmology
> phys.cosmology.omega (matter/energy density of universe)
> phys.cosmology.hubble (hubble constant)
> phys.cosmology.sigma8 (Normalisation of matter power-spectrum)
> phys.matter.dark (dark matter tag)
> phys.matter.baryon (baryonic matter tag)
> phys.DarkEnergy (dark energy tag)
> phys.virial
> phys.size.length
>
> object  (astophysical object)
> object.planet (planet)
> object.satellite
> object.star   (star)
> object.galaxy (galaxy)
> object.DMhalo (DM halo)
> Object.DMhalo.subhalo (DM subhalo)
> etc
>
>
>






From glemson at xray.mpe.mpg.de  Tue May 16 09:29:21 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Tue, 16 May 2006 18:29:21 +0200 (METDST)
Subject: theory sessions
Message-ID: <Pine.HPX.4.21.0605161824040.14327-100000@mpehp1.mpe-garching.mpg.de>

Dear all

In the first theory sessions we decided that the following subjects
deserve more detailed attention during this Interop: data formats, 
UCDs,metadata and SNAP. On the meeting's TWiki page 
(http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006Theory 
I have added some structure to these proposals. Please mail me
if you would like to contribute to one of these discussions and when you
would have time to do so wrt the other sessions going on.
If possible I would like to start this afternoon.

Cheers
Gerard


From glemson at xray.mpe.mpg.de  Tue May 16 11:30:08 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Tue, 16 May 2006 20:30:08 +0200 (METDST)
Subject: theory UCD session
Message-ID: <Pine.HPX.4.21.0605162027280.14327-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
Taking into account replies to the email I suggest we meet this afternoon
after lunch, 2PM to discuss the UCDs for theory.
Andrea, If you can not make this I will report to you later.
Cheers
Gerard
PS
I will mail about a location later.


From glemson at xray.mpe.mpg.de  Tue May 16 11:57:48 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Tue, 16 May 2006 20:57:48 +0200 (METDST)
Subject: theory UCD session
In-Reply-To: <Pine.HPX.4.21.0605162027280.14327-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.HPX.4.21.0605162047030.14327-100000@mpehp1.mpe-garching.mpg.de>

The meeting will be in Boardroom B, up the stairs at the back of the main
meeting rooms.
We will start discussing UCDs, but hopefully we can deal with other issues
as well, for example a discussion how to approach the question of data
formats, which may not need too much time.
Gerard

On Tue, 16 May 2006, Gerard Lemson wrote:

> Dear collegues
> Taking into account replies to the email I suggest we meet this afternoon
> after lunch, 2PM to discuss the UCDs for theory.
> Andrea, If you can not make this I will report to you later.
> Cheers
> Gerard
> PS
> I will mail about a location later.
> 


From glemson at xray.mpe.mpg.de  Tue May 16 16:51:06 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Wed, 17 May 2006 01:51:06 +0200 (METDST)
Subject: theory UCD session
In-Reply-To: <Pine.HPX.4.21.0605162047030.14327-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.HPX.4.21.0605170141230.29629-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
Today the Cc:-s above met for a discussion about concepts that we need to
describe simulations. It started based on the email by Laurie Shaw with a
proposal for new UCDs. We realised that whereas some of the proposals were
properties, others were values. The former might be used to construct a
UCD, the latter to words in a/the standard vocabulary.
We decided that we first wanted to create a more comprehensive list of
these concepts, and only afterwards subdivide them into their apropriate
class, after weeding out concepts already existing in UCD list and/or
vocabulary.
To this end the first attempt is posted on the Twik pages, 
http://www.ivoa.net/twiki/bin/view/IVOA/TheorySemanticVocabulary.

Please add concepts and possible values.
It may be somewhat cryptic at the moment, this should improve.
The result will be discussed Thursday morning, first in UCD session I,
then in theory session III.
Regards
Gerard



From glemson at xray.mpe.mpg.de  Wed May 17 07:59:02 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Wed, 17 May 2006 16:59:02 +0200 (METDST)
Subject: theory data formats and SNAP session
In-Reply-To: <Pine.HPX.4.21.0605162047030.14327-100000@mpehp1.mpe-garching.mpg.de>
Message-ID: <Pine.HPX.4.21.0605171655160.9764-100000@mpehp1.mpe-garching.mpg.de>

Dear Collegues
As discussed earlier, today we will continue our discussions.
We'd like to talk about data formats and SNAP in particular.
As the exec meeting is actually planned to last until 15:30, and takes up
the Boardroom B where we'd be meeting, lets plan to meet at 16:00 there
after all.
Regards
Gerard




From mcs at iaa.es  Thu May 18 01:27:48 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 18 May 2006 10:27:48 +0200
Subject: FoV in Aladin and Virtual Telescopes
Message-ID: <523EFBF4-4FE2-4296-8103-F9F2C086F94D@iaa.es>

Dear all,

I am not in Victoria but I am following the session in the wiki pages.
I just see that Aladin provides now an implementation of any FoV,
that is described in a xml file (at least it is in the abstract).

I just realized that maybe it would be quite useful for future  
virtual telescope
developments, but it would need:
  - the xml file with the FoV would be a VOTable
  - there would be a "repository" or registry of FoV (may be provided by
      particular telescopes, or simple, a place where different FoV  
would be added
      by particular users that has done the work to define it for  
their observational proporsal)
      (i.e. the FoV is just another item in all the VO environment)

Well it is just a comment :)

cheers

	Miguel



From herve.wozniak at obs.univ-lyon1.fr  Thu May 18 08:33:51 2006
From: herve.wozniak at obs.univ-lyon1.fr (Herve Wozniak)
Date: Thu, 18 May 2006 17:33:51 +0200
Subject: semantics
Message-ID: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>

Hello,
I just have a look to the vocabulary list
(http://www.ivoa.net/twiki/bin/view/IVOA/TheorySemanticVocabulary)
that has been recently increased by Miguel. Thanks to fill the gap with all the
necessary tools for stellar population evolution.

I'm wondering however whether we need or not to introduce a second level of
'physical processes' (as suggested by Miguel, I guess). I understand that the
problem comes from stellar evolution and stellar population synthesis since the
real physical processes involved in such modelling are very embedded in several
shells of code. It could be difficult to classify PEGASE, GALAXEV etc. in the
'radiative transfer' or 'photoionization' boxes!
I could also anticipate that if I want to classify my own chemodynamical codes,
I will need more or less every keywords of the 'physical process' list (apart
from GR!)!!! Keeping in mind that these keywords are possible values of an UCD,
I would describe my chemodyn code as 'gravitational dynamics + hydrodynamics' at
the minimum, but how to describe star formation recipes, feedback, stellar
population evolution etc. which form the 'chemo' part of the code ?

Anyway, in my opinion, 'stellar evolution', 'stellar population synthesis', but
also 'stellar structure' and so on (still many gaps to be filled!), should be
also (or only?) listed in the 'subject'.

I suggest to include photoionization and photodissociation in 'physical process'
to be able to describe e.g. cloudy,mappings, Meudon code, etc., should we keep
or not the 'primary/secondary' distinction.

I would like to propose that hydrostatic is a particular case of hydrodynamics
since a growing number of star/planet/exo-planet atmosphere models includes
atmospheric circulation.

Cheers,
Herve

_______________________________________________________________
Herve WOZNIAK
Centre de Recherche Astronomique de Lyon (UMR 5574 UCBL/CNRS/ENS-Lyon)
9, avenue Charles Andre, F-69561 Saint Genis Laval cedex
Phone:  (+33) (0) 478 868 388     Fax:    (+33) (0) 478 868 386
http://www-obs.univ-lyon1.fr/herve.wozniak/

--------------------------------------------------------------------------
Ce message a ?t? envoy? depuis le webmail IMP (Internet Messaging Program)


From Franck.LePetit at obspm.fr  Thu May 18 10:22:29 2006
From: Franck.LePetit at obspm.fr (Franck.LePetit at obspm.fr)
Date: Thu, 18 May 2006 19:22:29 +0200 (CEST)
Subject: semantics
In-Reply-To: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>
References: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>
Message-ID: <Pine.OSF.4.58.0605181845490.509432@mesioq.obspm.fr>


Hello,

We thought a bit to this problem of definition we had on tuesday
afternoon. I put below my notes.
My conclusions are :
- we have to add an entry for the name of the developper or the
developping team. during the registration.
- The tag physical process will be our main problem. We will have to
describe far more our codes that we said on tuesday. Below I give the
example of somebody who would looked for a PDR code to compute
vibrationnal excitation of H2. It will require to describe codes in all
the details.
- On the other hand, as mentionned during the discussion on tuesday and
in last Herve's mail, registration of some codes would require to use far
too much "physical processes" values. An efficient search in registries
need to group them with more common names. Ex: photoionization region code
(cloudy type), PDR code.

Best regards
Franck Le Petit and Fabrice Roy

----------------------------------------------------------
Note about UCDs for the descrition of codes in registries
----------------------------------------------------------

First we have to precise if we try to caracterize a code or
a result from a simulation.
They should be considered as two different categories in the registries. A
metadata should be associated to simulation results to say from which code
it comes from. A search on this metadata should be possible.
Example : I want all simulation results from Zeus.


**********************************************
UCDs required FOR CODES
**********************************************

A search in the registries has to find a code.
Example of searches :
0) I want the wonderful code developped by the Albert E.
1) I want the Cloudy code.  (search by name)
2) I want the version of 1999 of the Cloudy code (add the version)
3) I want a radiative transfer code (category of code)
4) I want a radiative transfer code using the Ali method (method
specification)
5) I want a radiative transfer code able to deal with X-Rays in optically
thick media. (that is a tough one)
6) I want a radiative transfer code for interstellar clouds in the
millimetric producing spectra. (add a specification on the output)
8) I want an MHD code using characteristics methods for boundary
conditions. (method about boundary conditions - should be covered by
algorithm)
10) I want a stationnary (or time dependent) MHD shock model

Note : We could find very difficult queries. Ex: I want a PDR code
computing the vibrational excitation of H2.
Such queries would require to describe a lot the code in the registries
(excitation of H2).
I think that in a first step we do not have to go to this level but, at a
point, it may be necessary. It will require to have many possibilities in
the "physical process" tag (far more than in the thesaurus).

0 --- Team / developper ---------------------------------------
(Example 0)
A search on the name of a team or of a developper name should be possible.
It is frequent, we choose a code because we are confident in a team...

Required for registration : yes

1 --- Name --------------------------------------------------
(Example 1)
A UCD is required to tag the name of the code

Required for registration : yes
Multiple possibilities : no
Choice from a list : no

2 --- Version -----------------------------------------------
(Ex. 2)
A UCD is required to tag the number version of the code.

Required : yes
Multiple possibilities : no
Choice from a list : should follow common standards for versionning
(Herv?? knows that)


3 --- Physical Process (Type of code) -----------------------
(Ex. 3)
A UCD is required to specify the physical processes the code can deal
with.
Most of the possibilities can be found in the "thesaurus".
We should add some possibilities which are the common name given to codes
dealing with many physical processes.
Example : PDR code, Photoionization region code.

Multiple choice possible : yes
Defined list of possibilities : yes(?)
List of choices : Thesaurus (plus a few more to reflect the usual way
these codes are called ? )
Note: If we want to find a solution as the request :"search for a PDR code
computing the H2 excitation", the thesaurus will no more be sufficient.
Other solutions will have to be found.

Examples : 	- radiative transfer
		- MHD
		- gravitationnal dynamics (not in thesaurus)
		- photoionization (cover many physical processes)
		- PDR (cover many physical processes)

4 --- Subject ---------------------------------------------
(Ex. 6-7)
This UCD would precise the kinds of objects the code can simulate.
Example : - Accretion disk
	  - Molecular clouds
	  - Galaxies
...

Multiple choice : yes
Defined list of possibilities : yes
List : Thesaurus

Note : Example 5 is a problem. The request requires a code able to deal
with optically thick media. Such characterization is not found in the
thesaurus.

Note : A search using "Physical process" and "Subject" should succeed most
of the time excepted for specific researches

5 --- Algorithm ----------------------------------------
(Example : 4,8)

This UCD is required to specify an algorithm.
Example : N-body, SPH, Ali, ...,
Problem : The same algorithm can have different names.
Possible solution : Add as many values as it has of names.

The list should not be limited.
Reason : New algorithms can be found.

Should this field be filled for all codes ?
Not sure if such classification is relevant for physico-chemistry codes.
There are so many physical processes that nobody care how they are done
(excepted for radiative transfer).

6 --- Time Evolution algorithm ----------------------------

Is it a necessity to separate the time algorithm with the other algorithms
?
The main interest is that this UCD could help to discriminate between
stationnary and time dependent codes.

(7 --- Algorithmic parameters) ---------------------------

To be suppressed for the definition of codes in the VO.
Only relevant for the definition of results of simulations.

8 --- Result type -----------------------------------------
(Ex: 6)

A UCD is required for result type as seen in Ex. 6.
Multiple possibilities : yes
Defined list of possibilities : yes
List : 	- snapshot
	- animation
	- table
	- fits

9 --- Result parameters

I do not see the purpose of this UCD.




From derriere at newb6.u-strasbg.fr  Thu May 18 17:00:21 2006
From: derriere at newb6.u-strasbg.fr (derriere at newb6.u-strasbg.fr)
Date: Fri, 19 May 2006 02:00:21 +0200
Subject: semantics
In-Reply-To: <Pine.OSF.4.58.0605181845490.509432@mesioq.obspm.fr>
References: <1147966431.446c93dfe5179@webmail.univ-lyon1.fr>
	<Pine.OSF.4.58.0605181845490.509432@mesioq.obspm.fr>
Message-ID: <20060519020021.o1fqwxilb9344k40@astron.u-strasbg.fr>


   Hello,

   You can find the presentation that I did during
Registry session 5 on the meeting page:
http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006ResReg
   Especially, on the last slide, I tried to identify
the metadata tags from the Registry ResourceMetadata
document that could correspond to the main categories
that you identified. Comments are welcome.

   By the way, I'm a bit uncomfortable with the usage
of the UCD term in your mail. For example, I totally agree
that we need a UCD meaning "algorithm". But the different
possible values described by this UCD are not UCDs. They
can be words in a normalized vocabulary, you can write
them using a "a la UCD" syntax, but they really are not
UCDs.
   To tell it in a few words, we can have a UCD for each
ResourceMetadata element. The UCD is used to give a name
to the empty box, and this name is not specific to a given
schema, unlike the name of the XML element.
   The values you put in the box can be issued from a
normalized vocabulary, but they are not UCDs in the original
sense.

Sebastien.




From glemson at xray.mpe.mpg.de  Fri May 19 09:44:00 2006
From: glemson at xray.mpe.mpg.de (Gerard Lemson)
Date: Fri, 19 May 2006 18:44:00 +0200 (METDST)
Subject: metadata modeling
Message-ID: <Pine.HPX.4.21.0605191838340.25046-100000@mpehp1.mpe-garching.mpg.de>

Dear collegues
Today at 11 we will try to meet in Boardroom B, upstairs, to discuss the
approach to modeling metadata for discovering interesting simulations.
See you there
Gerard


From brian_thomas at earthlink.net  Fri May 19 10:42:15 2006
From: brian_thomas at earthlink.net (Brian Thomas)
Date: Fri, 19 May 2006 13:42:15 -0400
Subject: Links to W3C workflow/processing models
Message-ID: <200605191342.15312.brian_thomas@earthlink.net>


	As I mentioned in the DM session today there are a number of W3C efforts which
	should be considered (or at least mined for the 'good stuff') in terms of doing distributed
	workflows and processing descriptions.

	(at Mark Taylor's suggestion  I have cross posted to theory and grid-ws groups..don't shoot
	the messenger!!)

	=brian

Links:
http://www.w3.org/TR/proc-model-req/
http://www.w3.org/TR/xml-pipeline/ (older)
http://www.w3.org/Submission/OWL-S/

Software : 

http://www.mindswap.org/2004/owl-s/api/   (OWL-S API/execution environment)



	


From brian_thomas at earthlink.net  Fri May 19 10:42:15 2006
From: brian_thomas at earthlink.net (Brian Thomas)
Date: Fri, 19 May 2006 13:42:15 -0400
Subject: Links to W3C workflow/processing models
Message-ID: <200605191342.15312.brian_thomas@earthlink.net>


	As I mentioned in the DM session today there are a number of W3C efforts which
	should be considered (or at least mined for the 'good stuff') in terms of doing distributed
	workflows and processing descriptions.

	(at Mark Taylor's suggestion  I have cross posted to theory and grid-ws groups..don't shoot
	the messenger!!)

	=brian

Links:
http://www.w3.org/TR/proc-model-req/
http://www.w3.org/TR/xml-pipeline/ (older)
http://www.w3.org/Submission/OWL-S/

Software : 

http://www.mindswap.org/2004/owl-s/api/   (OWL-S API/execution environment)



	


From brian_thomas at earthlink.net  Fri May 19 10:42:15 2006
From: brian_thomas at earthlink.net (Brian Thomas)
Date: Fri, 19 May 2006 13:42:15 -0400
Subject: Links to W3C workflow/processing models
Message-ID: <200605191342.15312.brian_thomas@earthlink.net>


	As I mentioned in the DM session today there are a number of W3C efforts which
	should be considered (or at least mined for the 'good stuff') in terms of doing distributed
	workflows and processing descriptions.

	(at Mark Taylor's suggestion  I have cross posted to theory and grid-ws groups..don't shoot
	the messenger!!)

	=brian

Links:
http://www.w3.org/TR/proc-model-req/
http://www.w3.org/TR/xml-pipeline/ (older)
http://www.w3.org/Submission/OWL-S/

Software : 

http://www.mindswap.org/2004/owl-s/api/   (OWL-S API/execution environment)