SNAP data model, online doc

This page gives the Wiki version of the documentation for the model and wil supplant that document. See the following links for

• latest UML version
• latest XML schema document

Table of Contents

1 Summary

This document presents a model for describing certain types of numerical computer simulations and certain types of simulation post-processing products. The model is to be used in the query part of the Simple Numerical Access Protocol (SNAP, TBD think of better name?], and in discovery of interesting SNAP services in the first place. We only consider simulations for systems that represent a space-time sub-volume of the universe and (part of) its material contents. In general these simulations will evolve this system forward in time and are able to produce snapshots, representing the state of the system at a number of consecutive times. These direct, raw results of simulations we call Level-0 products, following similar terminology for observations. SNAP also covers Level-1 products, which consist of the results of certain types of post-processing of simulations, namely those products that in some form represent a spatial sub-volume of the universe. We do not make any restrictions on the type of systems being simulated, or the size of the simulation, or the way the system is represented in the simulation code and results. We also make no restrictions on the type of “observables” produced by the simulations. The SNAP protocol includes online services that process level-0 or level-1 results and produce (by definition) other level-1 results. The allowed services deal with selecting the results in a sub-volume of the complete result, projections onto a 2-dimensional mesh, ... [TBC]

2 Use cases, scenarios, requirements

We have assembled a list of explicit use cases and scenarios from which we derive requirements for the current model and the SNAP protocol.

Scientific goals and corresponding questions to a repository of simulations:

• Scientific goal: investigate baryon wiggles in the evolved density field
  Query: Return all cosmological, pure dark matter, N-body simulations with WMAP 3 initial conditions and a box size of at least 1000 Mpc comoving, containing snapshots at about 10 redshifts between 3 and 0.
• Scientific goal: investigate whether observed structures in X-ray cluster that seem to indicate turbulence, can truly be that.
  Query: return all hydro-dynamical simulations of galaxy clusters of mass at least that have a model for viscosity included in the simulation. Moreover, return only those simulations that have associated to them an online visualisation service that can produce projected temperature and pressure maps.
• Scientific goal: interpret the possible histories of an observed galaxy merger to calculate possible star formation episodes and compare these to the observed stellar populations.
  Query: Return all simulations of galaxy mergers where the component galaxies have a particular mass ratio and where there are enough snapshots to follow the evolution over a few Gyr.
• Scientific goal: compare the luminosity function of galaxies in the SDSS survey with those in synthetic catalogues.
  Query: Select all cosmological simulations that have produced as secondary product synthetic galaxy catalogues on a light-cone and provide those via an SQL (ADQL?) query interface.
• ...

3 Modelling simulations and related data products

For the purpose of this specification we consider a simulation as the execution of software that produces a representation of a spatial system, and possibly follows its evolution form one state to the next by approximating the true physical processes acting on the system with numerical algorithms. A description of such a simulation can be provided by giving the representation of the state of the system at each point of time, of the physics being modelled as differential equations and the way these act on the representation variables. It requires initial condirtions and parameters describing the physics as well as numerical approximations. For discovery purposes it is also important to be able provide summarising information about the results.

To think about the appropriate structure of the model it is useful to think about the steps a user might go through when querying a database system in various “drilling down” steps. For example the following questions might be asked :

• What system/object is being simulated?
• What physical processes are included?
• How is the system being represented in the simulation (particles (Langrangian), (adaptive) mesh (Eulerian)), both, other?
• Per process:
  • How are the physical processes implemented ?
  • Characterise the numerical approximations (.e.g. resolution, softening parameter)
• What observables are available for the system/object, possibly as function of time? As it is a spatial system, at least size, center-of-mass position.
• What observables are available for the constituents, i.e. what is the “schema” of the “atomic” objects?
• Per snapshot, per atomic object type, per variable:
  • Characterise the possible values
  • Characterise the result
• Are post-processing results available?
• Are services/applications available working on the results?
• Which code ran the simulation?
• What were values of physical parameters?
• How were initial conditions created, what parameters?

4 Documentation UML diagram

The process shortly described in the previous sections has led first to an analysis, or domain model which we will not describe here (see here). That model in combination with the particular application specific requirements have led us to design a logical model for describing simulations and how this is to be used in the discovery and query phases in SNAP. The diagrams on this page show the UML version of that model and give the MagicDraw version of it. We now proceed to describe this model in detail, first the Class-es (orange), then the Datatype-s, which includes Enumerations, colored grey.

Below we list all the classes in the UML diagram.
We use the definitions in this page

Template table for documenting child elements

name	datatype	description
Attribute
Reference
Collection

The following namespace prefixes are used to refer to other models

• res: registry resource model
• iid: IVO identifier model

class SNAPResource

...

name	datatype	description
Attribute
name	string
description	string
referenceURL	anyURI	URL where generic information about this resource can be obtained
Collection
curation	res:Curation	Provides "standard" curation information about this resource. Borrowed from Resource model.

class SNAPProtocol extends SNAPResource

The base class of all protocols producing snapshots. These objects define how SNAP experiments can be performed, like a blue-print, template. For simulations the protocol will be the simulation code, here represented by SNAPSimulator. In the analysis model this class is more fully defined, but for the logical model for discovering SNAP experiments much of its components are moved to the SNAPExperiment itself.

name	datatype	description
Attribute
code	anyURI
Reference
version	string
Collection
parameter	InputParameter
parameterGroup	ParameterGroup

class SNAPSimulator extends SNAPProtocol

class InputParameter

name	datatype	description
Attribute
name	string
datatype	Datatype
cardinality\Cardinality
label	OntologyObject
description	string
Reference

class SNAPExperiment extends SNAPResource

The base class for those kinds of experiments that can produce representations of a part of the universe. It is an experiment in the sense as defined in the analysis model and in the original domain model.

name	datatype	description
Attribute
publisherDID	string	The identifier by which this experiment is identified in its archive. Any service working on the results of this experiment must understand this identifier as referring to the selected SNAPExperiment.
Reference
protocol	SNAPProtocol	The protocol according to which this experiment was performed. Will in general be overridden by sub-classes of SNAPExperiment to indicate a sub-class of SNAPProtocol.
Collection
parameter	InputParameter	The collection of simulator input parameters used in this simulation. These parameters must correspond to actual parameters that can be set on the simulator.
targetObject	TargetObjectType	An indication of the actual system that was being simulated. For example, star, jet, galaxy, large scale structure. The creation of this was the goal (were the targets) of the simulation
targetProcess	TargetProcess	An indication of a physical process, the study of which was the (a) goal of the experiment. For example, gravitational clustering, cosmology, star formation.
representation	RepresentationObjectType	Indicates the different object types used to represent the system that is being simulated/produced by the experiment.
snapshot	Snapshot	The collection of snapshots that are the individual results as function of time of the experiment.

class SNAPSimulation extends SNAPExperiment

class SNAPPostProcessing extends SNAPExperiment

class SNAPProject extends SNAPResource

class ObjectType

class TargetObjectType extends ObjectType

class RepresentationObjectType extends ObjectType

class Algorithm