1 / 10

Updating JUPITER framework using XML interface

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

selene
Download Presentation

Updating JUPITER framework using XML interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Updating JUPITER framework using XML interface Kobe University Susumu Kishimoto

  2. 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

  3. 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

  4. 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.

  5. 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 • “Visitor” parts: • For solving the problem of large “base class” • For generating the hierarchy of read stored external inputs • new “base classes” which can generate geometry structure dynamicallyby using external data.

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

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

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

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

  10. New Jupiter Kernel class diagram Soon be available

More Related