Solidsim geometry spec

This page has been moved to https://solid.jlab.org/wiki/index.php/sim_geometry_spec in the new SoLID Wiki. Please do not edit this page.

This specification needs a lot of thought and work, but here's how I would outline it:

Format

flex and bison are used to develop the parser. The structure of the function calls are uniform enough, that there will only need to be several different forms of calls, which can be written directly into the grammar.

Capabilities

It should have the capability for the following:

nested if-then-else statements nested for loops arithmetic processing, i.e. evaluate statements like -(i+4)^2.2/cos(pi/4) arbitrary variables, with arrays up to at least 3 dimensions mathematical functions (cos, sin, tan, etc...) comments

requiring a preprocessor: (multidimensional) arrays defined by files files to be included/inserted into the master file

Materials

There's several functions used in geant to create materials. Should be possible to just do a parameter-by-parameter type call. Each material is specified with a name which can be called by the volume creation

Rotations

A set of named rotations will be specified which can be used in volume creation. There are several ways to specify rotations in Geant4, so we should keep these flexible

Volumes

In geant all volumes are placed in a "mother volume" (with a top level volume called world). Each volume in our specification will have a unique name and an optional material. Each volume we create will have a solid (or union/subtraction of solids) and a logical volume. A physical volume is created if a material is specified. They all have one "name", the appropriate type can be determined from context. Using the in <mother volume name> call for each volume needs to have a name, a list of solids and how they are combined, and if they are to be iterated.

Volume iteration will likely be useful and we need it for both

• azimuthal
• linear

Detectors

Sensitive detectors are associated with logical volumes in Geant4. Each detector is named and has a type (start with generic) (and can be associated with many volumes?). Each detector name is used in the ROOT tree. Should be able to get at global position through navigator. Possibly something more?