1. MaGe workshop – summary (my collection!)
Luciano Pandola
INFN, Laboratori del Gran Sasso
MaGe Joint Workshop, Munich, January 2010

2. Scope and goals
Three years are past since the I MaGe meeting in Munich (and >5 since the meeting 0 at LNGS)
The development “burst” calmed down and a fairly stable version of MaGe is available
The burst now is on MGDO and pulse shape simulation software  coordinate the effort
“Minimize double work while making sure that work done is redundant enough to ensure connection to reality”
Majo and Gerda are going to start data taking
Need reliable/validated MC also for data interpretation
Open road towards a common 1-ton effort
Need new background studies
New scenarions for MC, need MaGe to be scalable

3. MGDO
Meant to be a common format (with tools) to help the interface between Monte Carlo and real data (exp. pulse shapes)
It was extensively developed in the past ~2 years (both Majorana and Gerda)
Includes:
Containers (“objects”) to treat and manage physical quantities, as waveforms, electric fields, geometry data
Interface to MaGe MC simulations via the hits ( MaGe depends on MGDO, not v.v.)
General-purpose tools for data treatment and analysis (FT, filters, calculations)  useful also for real data
A comprehensive manual not available up to now
This did not help newcomers to use MGDO interfaces and tools
Going to have documentation on TWiki

4. Geometry Geant4 includes a number of graphics drivers
Some of them for debugging, some for drawing paper-grade fancy figures, etc.
It is known that some drivers fail for some geometries, even if they are defined correctly in Geant4/MaGe (except RayTracer, which uses Geant4 tracking algorithms)
Not critical that visualization is correct (unless one wants to read dimensions from the plots), but indeed MaGe geometry must be correct (= no overlaps  unpredictable behaviour with Geant4)
Check that things remain ok even when one changes the Geant4 version, the compiler, the CPU kernel, etc.  not obvious a priori

5. Benchmarking - geometry
Action: prepare a small testing suite for geometry, which checks for overlaps using the Majo SurfaceSampler algorithm
To be run
For new Geant4 versions, main changes in MaGe, compiler upgrades, etc.
On a few “easy” geometries but tricky enough (e.g. “strange” solids) that problems may show up
On a sub-set of real geometries, that are critical for GERDA and Majorana
Things should be as automatic as possible. At least one geometry should contain an overlap ( verify that the test actually fails)

6. Pulse shape simulations
Software for pulse shape simulation is under very active development both in Gerda and Majorana.
Validation with real data also ongoing, good results
A least 3 independent codes developed up to now (although optimized/targeted to different types of detectors)
Advisable that results are cross-checked for a few easy cases (= benchmarks)
All codes should be integrated or have an interface to MGDO, to allow the re-use of common tools (not to re-invent the wheel)
Check also if memory issues appear with MGDO
It is important to make the Munich code (developed & tested for true coax detectors) work also for r=0, so that it can be used for other types of detectors (BEGe, not true coax)

7. Benchmarking – PS simulation
Action: Compare results obtained by the PS codes for two test cases (for which data will be made available)
Munich segmented detector (true coax)
Majorana BEGe
Comparisons step-by-step
Check E fields and VW on a crystal axis [e.g. V(r=0,z) for BEGe, V(z=0,r) for coax]  profiles to be compared quantitatively (2 ?)
Check final pulses (rather than trajectories) for ~10 test points distributed in the detectors (especially where one may expect problems)
Then validation with exp. data

8. 1-ton effort (1)
Need to simulate extremely rare events, goal is 10-4 counts/(keV kg y)
Monte Carlo job at the moment:
Check that there are no clear show-stoppers
Provide information to the engineers
Identify areas where R&D is required
Critical items likely to be close parts (e.g. insulators, electronics  irreducible) and surface contamination
Probably need a deeper & larger laboratory
At this point, manpower for the 1-ton MC effort is a limiting issue

9. 1-ton effort (2) Challenge from the Monte Carlo point of view:
Codes to be optimized for speed, need to simulate 1012’s Events
Optimized generators
Advisable to benchmark neutron tracking algorithms (e.g. MaGe/G4 vs. MCNP) with use cases that are easy enough (simple shielding)
Open discussion whether we want MaGe to be publicly available, as a general tool for the community
Consensus not reached. Surely, we distribute(d) the code to individuals who ask it
In any case, we don’t have manpower (nor will) to provide any support

10. Data format for analysis (1)
MGDO is a natural candidate as a format to convert MC and real data for further analysis
Common interface, many tools already available (transforms) for data treatment
Easier comparison with MC
Rawdata  MGDO would be the first step of the data processing (tier 1)
Experiments to take care of their own interface between rawdata (=DAQ groups) and MGDO
At this stage one could apply some blinding (proposed for GERDA)
Jason proposed to have modular analysis (e.g. via TAM)
Going to make a proposal at the GERDA meeting

11. Data format for analysis (2)
GERDA will stick to MGWaveform as an common output for Pulse Shape codes
Easier to compare and benchmark the PSS codes
GERDA will also evaluate the MCTMCEvent container proposed by Alexis as a standardized MC output
Luciano to have a closer look
At the first glance, needs some adjustments because experiments have different concepts (e.g. GERDA has Water Cherenkov)
Common problem: access the simulation geometry information in the post-processing (MGCrystalData?)
Try to do before Feb 29th

12. Databases
No doubt that we need database(s) to keep track of data and info
calibration, real, MC, slow control, logbook, etc.
Good to have one single database (not different formats/locations).
Maintainance going to be an issue
Mike has tried and proposed CouchDB
Phyton link between MGDO, CouchDB and ROOT
Database discussion in GERDA is still at a very preliminary (= conceptual) stage
To be agreed within the Collaboration

13. Background model(s)
Both Majorana and Gerda are developing independently tools for book-keeping of jobs in large simulation campaigns
Identify, store and retrieve the parameters of interest
File names, material properties, etc.
Could be done via a database (in GERDA it is a human-readable XML file)
Also tools for spectral fit will be useful
Consensus that the needs of the two experiments are different for this  no common development of book-keeping tools
Good to have redundancy in some cases

14. Geant4 9.3 …
You just heard it… no need for summary 