LCD Parameter Handling

Why?

• All lcd programs need parameter input of one sort or another:   detector description, approximations, cuts,...
• Currently some information is contained in files of various ad hoc forms; the rest is hard-coded or just plain ignored.
• The essence of the simulation enterprise is to study a variety of designs.
• A flexible, extensible scheme for handling parameters would
  • save programming time (in the long run)
  • give people doing analysis the ability to investigate more alternatives.

What's missing now?

The structure of the parameters file used for full simulation (*.ini) has several deficiencies. 

• Elements logically tied together, such as those describing the geometry of a particular subdetector and those describing its materials have no connection in the file other than similar names.
• Values can be inconsistent with each other
• There is no uniform approach to describing the information.  This makes parsing more complicated and gives no guidance to anyone wanting to add new information in a natural way.

The files used for Fast MC also have problems.  Some of the values have little or no labeling, so that only an expert can determine what's there (or what should be there).   The master file references other files for inclusion.  This is a useful feature, but it is not done in a way which extends to other applications.

Proposed Approach

In order to promote reuse of code and of file formats, the job of  acquiring parameters can be broken into stages:

1. getting the information from files to an in-memory database.
2. providing a low-level (no application semantics) program interface to the database
3. for complex information such as detector description, providing a smarter program interface which does know something about the information it manages.