International Virtual Observatory Alliance

Difference: IVOATheorySimDBDMDiscussion (4 vs. 5)

Revision 52009-03-19 - RickWagner

META TOPICPARENT	name="IvoaTheory"

This page is for discussions of the Simulation Databaase (SimDB) data model (SimDB/DM). In SimDB the data model is represented by a UML diagram, which is stored as an XMI file in the volute GoogleCode SVN repository. The latest version of the model can be downloaded from http://code.google.com/p/volute/source/browse/#svn/trunk/projects/theory/snapdm/input. It is the file named SimDB_DM.xml. Authors of issues should indicate which revision of the data model they comment on. This number is indicated in the Rev column of the listing in the above mentioned URL.

AMR simulations & statistics issues (r902)

1. how to indicate the refinement conditions per AMR level ?

2. how to indicate the number of cells per AMR level ?

3. how to deal with functions like statistics (average velocity ...) computed per density threshold (or any other property) ? it is like a 2D characterisation (x, y) where x & y are both properties.

See the following document to have a detailled description of that point :

histogram_proposal.doc:

Various issues raised by Rick Wagner (r902?)

in this email.

Added:

>
>

Follow-Up

Added:

>
>

During a telecon with Gerard, we have identified a few use cases that can test the data model. Hopefully we can adjust the model to encompass these.

Added:

>
>

Issue: Utypes

This one is pretty straightforward. SimDAP needs to map the elements of its responses to the simulation data model. The way to do that is through the Utypes. Hence, the Utypes defined from the XMI file need to fit any standards defined for Utypes.

Issue: Protocol types

While simulators are (almost) clearly defined, initial conditions generators, post-processing and analysis tools are not.

Are initial conditions generators simulators, special cases?
Is using using a tool like Cloudy to add fields (properties) post-processing, or another simulation?
Are there specific sets of attributes, such as the physics used, that helps us to differentiate between these programs?

My suggestion is to remove the subclasses of Protocol from the model, and use a "type" attribute, with a choice of values. There are several common types of applications used in computational astrophysics that can initialize the list. If it turns out to be insufficient, we can add to it, or make it repeatable.

Here are my suggestions to start the list:

simulator
initial conditions generator
halo finder
extraction tool
projection tool
spectrum generator
analysis tool
post-processing tool

Issue: Snapshot types

A result of trying to encompass a larger variety of protocols and experiments is that the data may not fit the current Snapshot model. For example, a Snapshot has "spatial size" attribute, to provide a sense of scale. However, the output of a spectrum generator is a set of SEDs. But, the output of an initial conditions generator is almost equivalent to the output of a simulation code. The difference between post-processing and analysis tools, and simulation and IC generators, is that simulation results contain a complete representation of what's being simulated.

The choices here are to either make the uncommon attributes on Snapshot optional, or to have both a Results or Output class, and Snapshot. I feel that the latter is preferable, since it allows us to easily distinguish which data held or initialized the state of the simulation.

-- RickWagner - 19 Mar 2009

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

META FILEATTACHMENT	attr="" comment="" date="1233070705" name="histogram_proposal.doc" path="histogram_proposal.doc" size="321024" user="LaurentBourges" version="1.1"

View topic | History: r17 < r16 < r15 < r14 | More topic actions...