From lds at ast.cam.ac.uk Fri Apr 14 14:48:55 2006 From: lds at ast.cam.ac.uk (Laurie Shaw) Date: Fri, 14 Apr 2006 22:48:55 +0100 (BST) Subject: UCD's for simulations In-Reply-To: References: Message-ID: 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 lds at ast.cam.ac.uk Fri Apr 14 14:48:55 2006 From: lds at ast.cam.ac.uk (Laurie Shaw) Date: Fri, 14 Apr 2006 22:48:55 +0100 (BST) Subject: UCD's for simulations In-Reply-To: References: Message-ID: 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 lds at ast.cam.ac.uk Fri Apr 14 14:48:55 2006 From: lds at ast.cam.ac.uk (Laurie Shaw) Date: Fri, 14 Apr 2006 22:48:55 +0100 (BST) Subject: UCD's for simulations In-Reply-To: References: Message-ID: 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 lds at ast.cam.ac.uk Fri Apr 14 14:48:55 2006 From: lds at ast.cam.ac.uk (Laurie Shaw) Date: Fri, 14 Apr 2006 22:48:55 +0100 (BST) Subject: UCD's for simulations In-Reply-To: References: Message-ID: 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