Dear Laurie,
dear members of the Theory Interest Group,
First, thanks to Laurie for the setting up of the "Theory Semantics" technical
note.
I would also like to make a few further comments:
- in the "Introduction", should not the registration of "theoretical on-line
services" be mentionned as well as of codes and simulation data sets, in
accordance with Sébastien Derrière's talk at the Registry session of the last
interop meeting ?
- In 2 "List of Categories" :
- I would suggest to list here the complete list of Categories, therefore
corresponding exactly to the subparagraphs of paragraphs 3 to 6 of the
"Contents" ; "Type of Results" and Algorithm Parameters" are missing.
- "Type of results" would be "d,c", similarly to "result format"
- "Algorithm parameters" would be "d,c"
- "Version of code" could be significant also for data (therefore should be
"d,c") ; a simulation can be very (at least somewhat) different when obtained
with a new version of a code ; so one has to know which version of the code it
refers to.
- 3.2 Name of code :
As Dave de Young stated it, the word "name" is probably not the best one to
refer to the code here.
May be a vaguer word (appellation ?) should be used instead ; the associated
ucd would then point to what the "appelation" is actually:
- meta.id: identifier or name, although the recent discussion on the ucd-sci
list, that Miguel mentionned in a previous mail, could make think that "id"
refering to "identifier", could be considered in the future as something very
specific (it has to be unique) and therefore should be distinguished from a name
or a designation (but there is no meta.name at the moment),
- meta.bib.xxx (author, bibcode) if the code is referred to by a publication
reference
- meta.ref.url in case of a reference to a web page
- ...
Notice that the second ucd word "comp.code" is not mentionned in the list of
suggested UCDs at the end of the document. Two questions here:
- can the atom "code" be used with a meaning different from what it has in
other ucd words (meta.code) ?
- is not it possible to use the already existing ucd "meta.software" instead
?
- 3.3 Version of code :
requiring the version to be a number may seem constraining ; it could be any
string, especially the month or date of the release of the version ("jul2006",
"2005-11-23", ...) ; I then agree with the precisions added by Miguel.
- 4. Physics of Code :
I think it would be more natural to put "Subject" before "Physical
Objective" and "Physical Processes" ("which object ?", "what ?", "how ?")
- 4.1 Physical Objective :
there is probably no need to add the word "meta.main" at the end of the ucd
as Laurie suggested to leave the possibility of multiple entries for (almost)
all categories.
- 5.3 Protocol
the name of this category comes from the initial suggestion by Laurie but this
name seems now unrelevant given all the related additional proposals. May be a
broader category should be thought of here ("Computing" ?) under which several
more specific informations are possibly supplied :
- parallelisation (yes/no), vectorisation
- if parallelisation, library used : OpenMP, MPI; way memory is used, ...
- language(s) of the code : C, C++, Fortran77, Fortran90, ...
- ...
The above are relevant for codes, but some informative parameters could
possibly be added for simulation data under a "Computing" header :
- cpu time needed to compute the simulation (+ info on processor)
- size of the simulation
These informations could may be be useful in worflows: "given the size and
cpu time needed, is it worth rerunning the program ?" - could have to do with
SNAP as well -
6.2 Results Formats
why not adding VOTable here which was agreed after Victoria to be data
format used by theory specific services to send data products ?
Very minor supplementary comments :
- the "Abstract" should probably be more explicit in the final version
- adding the page numbers on each page of the document would ease its reading
- in par. 1 (Introduction), why talking about "snip of simulation code" whereas
the aim is certainly to register very big codes ? (a wink ;-) in a tough text
?...)
Finally, I have a suggestion which may be worth being discussed :
as a goal of the present technical note is to provide clues to register codes
and simulations and if the content of the note is more or less agreed in
Moscow, would it be worth setting up a tentative "theory registry" (or ask
people managing one of the registries to implement the theory extensions); the
aim of it would be to have a testbench for trying to register existing
simulation codes and data in the framework of the technical note and for
simulating queries aiming at locating simulation codes/data.
May be this would have to be discussed with big projects such as VO-Tech.
With best regards,
Bernard Debray
--
Observatoire de Besançon | http://www.obs-besancon.fr/
41 bis, avenue de l'Observatoire | bernard.debray-at-obs-besancon.fr
BP 1615 | Tel : (33) 3 81 66 69 28
25010 Besançon cedex | Fax : (33) 3 81 66 69 44
France |
Laurie Shaw wrote:
>Hi Everyone,
>
>Attached is a first draft of the technical note that I have been writing
>for simulation Semantics. Based on the discussions at and after the
>Victoria meeting, and on early work on the Simulation data models, I break
>down the meta-data requirements to describe simulations into a set of
>categories. Each category itself must be labelled by a UCD, for which have
>made initial suggestions. The typical contents of a category varies
>between single characters or numbers, ascii text (or urls, names etc) and
>words from the standard vocabulary (which is still largely to be defined).
>
>I've attached the doc in both ms word and pdf formats. Would be great to
>have a brief discussion about this before the Moscow meeting -- I still
>have time to make lots of changes, if needed!
>
>Thanks,
>
>Laurie
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Received on 2006-09-15Z03:16:25