Updating JUPITER framework using XML interface Kobe University Susumu Kishimoto

Purpose and Requirements of ILC detector full Simulator Purpose –To optimize detector design by comparing physics performance with various detector configurations Requirements –For end users Easy to use for non-experts Easy to change detector configuration –For development clients Modularization of all detector components

What is JUPITER? A Simulator for ILC-Detectors based on Geant4 –Monte-Carlo Truth generator –Event reconstruction is made by Satellites. Features (originally aims): –Easy to modify of material, structure … etc –Easy to install/uninstall of detector components –A set of “base abstract classes” provide “methods” for installation of detector geometry hit data output

However in the present version … The detector attributes (solid, material, size, …) are hard-coded  Maintenance is difficult. The geometry structure (mother-daughter relation of detectors) is hard-coded  Reuse of geometry structure is difficult. The “Base class” has become very large –When a newly customized “G4VSolid-factory-method”, is used, the method has to be added to the base class.  The “Base class” becomes bigger and bigger.

How to improve Remove hard-coded parameters as far as possible and prepare them in external inputs Modify procedure of geometry installation: manually installing geometry structure, where clients must compile geometry structure code new “base classes” which can generate geometry structure dynamically by using external data. “Visitor” parts: 1.For solving the problem of large “base class” 2.For generating the hierarchy of read stored external inputs

How to use external parameter database in G4-geometry generation? 1.A fixed detector structure and variable detector parameters (material, size, color, etc.) –MySQL and XML are used in Mokka. –XML is used in LCD 2.A variable dynamical detector variable structure itself –GDML is developed at CERN –New Jupiter use XML data format 3.Geomodel

Why XML? 1.XML data is just a plain text 1.Easy to edit ( easy to change detector parameters, etc …) 2.Portability between Operating Systems and languages This point is advantageous for detector optimization. 2.XML data is a “well defined document” 3.XML data can be extensively customized 4.XML’s “Entity” enables us to reuse parameter module 5.XML is good at handling tree structure.

After(XML data) Before(mannualy intalling geometry C++ code)

Current Status XML parsing part (done) Detector component part (done) G4 detector geometry structure building Visitor part (under construction)

New Jupiter Kernel class diagram Soon be available