UCD's for simulations

[Andrea Preite Martinez]

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
>
>
>