Generated from UML->XMI->intermediate->XSD. This class represents a physical processes that is modelled in a simulation code. Simulating a physical process generally corresponds to solving equations of motion numerically, evolving the simulated system from one state to the next. _12_1_8e0028f_1173262198953_752563_1200 Name by which this physical process is represented in the simulator code _12_1_8e0028f_1173262215531_643752_1272 Short description of the physical process represented by this class. _12_1_2_213004e4_1193921243734_520148_273 The SKOS concept identifying this process in a standardised SKOS vocabulary. _12_1_2_213004e4_1207378230750_422787_1797 This class represents the simulation software that one uses to run a simulation. It is a special case of a SimDM/Protocol. It is different from other SimDM/Protocols in that it explicitly defines the physical processes that are (can be) simulated. This indeed is the defining characteristic of the SimDM/Simulator: it simulates/models physical processes. This in contrast to a "mere" SimDM/PostProcessor which takes the input data and analyses it without adding new physics. It does not imply that simulators can not use existing results. For example consider semi-analytical galaxy formation routines which work on existing halo (merger) catalogues. _12_1_8e0028f_1173260371343_174540_519 A SimDM/Protocol represents software code that can be used to run astrophysical simulations or to post-process simulation results. A SimDM/Protocol defines the method by which SimDM/Experiment-s can be performed, like a blue-print, or template. The SimDM/Protocol concept is separated out from the execution of its code in SimDM/Experiment, which allows us to reuse it for all experiments using the same code. The concept is a direct gemeralisation of the concept by the same name in Martin Fowler's book "Analysis Patterns: Reusable Object Models" (Addison-Wesley Professional, 1996). _12_1_8e0028f_1175789188406_755001_115 link where the code can be downloaded, if available _14_0_8e0028f_1202819920515_152058_1851 the version of the simulator code that was used _14_0_8e0028f_1202819929968_569605_1854 This concrete subclass of SimDM/Protocol represents protocols that deal with post-processing results of earlier experiments. We do not specify the details of this type much further. Main difference with eg the SimDM/Simulator type is that NO new physical processes are introduced/simulated in the processing of the previous results. Examples are cluster finders, visualisation tools etc. _14_0_8e0028f_1202820488812_969868_2587 Represents a (natural) grouping of SimDM/InputParameters. Especially in protocols with large numbers of parameters it may be useful to group these for browsing purposes for example. As browsing is likely an important mode of access to SimDM/Resource-s stored in a SimDB for example, this possibility was introduced. But the main use should be reserved for semantic groupings. For example all parameters together defining the cosmology a certain simulation is run in. Or the parameters setting "merely" numerical properties such as smoothing lengths. _14_0_8e0028f_1202835054703_251049_3232 Name given to this group. _14_0_8e0028f_1202835086000_997902_3304 Short description of the purpose of this group. _14_0_8e0028f_1202835092843_646857_3306 Associative class, representing a selection of a parameter in a parameter grouping. _14_0_8e0028f_1202835113906_103077_3309 Reference to the selected input parameter. _12_1_8e0028f_1213803600953_419155_306 This class represents the type of data object that the container SimDM/Protocol can produce. This concept includes any type of data object the protocol deals with. It can range from the smallest data units such as individual N-Body particles or pixels in a synthetic spectrum, up to the largest which may be a collection of snapshots in an N-body simulation ,each of them containing collections of particles. It defines also the actual SimDM/OutputDataset-s that a SimDM/Experiment's has produced. Since a SimDM/OutputDataObjectType is-a SimDM/ObjectType, it can be related to other objects using SimDM/Relationship-s. In this way a hierarchy of data types can be described. For example a spectrum can be a such a data object and will be composed of pixels. A FOF group catalogue will be composed of FOF groups which are aggregations of particles. _12_1_8e0028f_1173260105000_913974_289 Name that this type of particle is given in an appropriate SKOS vocabulary. _12_1_1_8e0028f_1178788974093_492177_289 This class represent an input parameter on a protocol. In general,a simulation codes needs the user to set values to parameters that govern the running of the code. These may be parameters describing the physics in a simulation, or they may be numerical parameters governing the approximation of the process by a particular algorithm. _12_1_8e0028f_1213803387328_904148_265 A label to be given to this input parameter from an appropriate SKOS vocabulary. _12_1_8e0028f_1213803555937_756421_288 This class represents numerical algorithms available in a SimDM/Protocol. In Simulators an algorithm may approximate a physical process. Examples from cosmological simulations are different algorithms to implement gravity: direct particle-particle interaction, particle-mesh, or various types of tree based algorithms. In post-processors such as cluster finder this class can represent a partiular cluster definition such as friends-of-friends or spherical overdensity. _12_1_8e0028f_1175674070859_180053_115 A common name given to this algorithm. _12_1_2_213004e4_1193921189468_176786_271 Short description of this algorithm. _12_1_2_213004e4_1193921153031_543879_268 Short name by which this algorithm is known in the SKOS vocabulary of numerical algorithms. _12_1_8e0028f_1175674349265_448235_342 Type of data objects that the protocol needs in its execution. _12_1_213004e4_1305784451562_803919_404 Label indicating the type of data object represented by this InputDataObjectType through reference to a SKOS concept. _12_1_213004e4_1315648777093_134551_374 If not null, this reference provides the definition of the input data object type as being a predefined SimDM/OutputDataObjectType of another SimDM/Protocol. It's implication is that the current SimDm/Protocol requires the results of another SimDM/Protocol for its execution. If this reference is null the input data object type must be defined using the properties inherited from the base object type. _12_1_213004e4_1305784699640_606749_484