Commit 128e8fb8 authored by Chad Lantz's avatar Chad Lantz
Browse files

Updated README

parent 44e18626
#### ZDC R&D MonteCarlo ####
## ZDC R&D MonteCarlo
Instructions from Mike Phipps (taken from his repo, michael.william.phipps@cern.ch)
Instructions from Mike Phipps (taken from his repo, michael.william.phipps@cern.ch). Updated by Chad Lantz in April 2020 for MC2.0 update
This simulation is intended to allow standalone (non-ATHENA) simulation of the current ZDC geometry, as well as configurable geometries that could be used for prototype studies.
1- GEOMETRY DEFINITION
The world is defined and the individual modules created in DetectorConstruction.cc. Depending what type of modules you've specified in the config file, different module construction classes will be called. For the EM Pixel module, use ModType1; for the Hadronic Pixel module, use ModType2; for the Hadronic Non-Pixel modules, use ModType3; and for the generic configurable modules (eg prototype designs), use ModTypeCustom. Parameters within mod types 1-3 should be kept static (in general -- since these geometries reflect the current ZDC geometry and that used in the ATHENA simulation). Parameters for custom modules should be chosen carefully within the config file.
This simulation is intended to allow standalone (non-ATHENA) simulation of the current ZDC geometry, as well as configurable geometries that could be used for prototype studies. The structure is intended to closely resemble examples/extended/analysis/AnaEx01 with the addition of several simulated environments and configurations stored in XML format.
For Modules 1 and 2, the geometry is highly "pixelized". In other words, it is composed of many geometry segments that must be stitched together. For example, each layer of tungsten plate is composed of 9 "lateral plates" and 8 "longitudinal plates" that are stitched together. The lateral plates are in the plane of the vertical strips and have a depth equal to the absorber gap depth. The longitudinal plates, on the other hand, run the length of the module and are located in the gaps between vertical strip groups. This scheme is done to match the geometries found in these modules in which pixels run the length of the detector in the gaps between the vertical plates, with air gaps in the vertical space between the pixels in each radiator gap. This may seem excessive, but within Geant, this sort of stitched-together, pixelized scheme is preferable to one with many boolean cut-outs. The processing time for this scheme should be similar to the other modules and an order of magnitude faster than the boolean cut-out option. For a more detailed explanation of this scheme and a diagram of the inheritance, see the ZdcSimulation section of the ATLAS ZDC twiki: https://twiki.cern.ch/twiki/bin/view/Atlas/ZdcSimulation
#### DetectorConstruction
For Modules 1 and 2, the pixel rods are currently not used as active elements of the detector. In other words, hits within these volumes are not retained.
- DetectorConstruction configures the simulation geometry based on the macro commands executed in geometry.mac. Multiple environments are/will be available for selection with the command ```/Detector/SelectEnvionment```.
Module 4 allows the following configurations:
- As an absorber block that could be used for test beams. To insert this, turn off the cladding, set NStripsPerGap, NRadiators, RadiatorGapLength and CladdingThickness to 0, and then set the Absorber size appropriately. Note: do not change the CoreDiameter to 0
- As a prototype module with cladding (but no buffer)
- As a prototype module with different sampling ratios
- As a prototype module that uses lead or tungsten absorber
2- PHYSICS LIST
The standard ATLAS hadronic physics lists is FTFP_Bert (Fritiof string model (>~5 GeV); Bertini-style cascade (<~10 GeV)) and that is the default list in this simulation. Although this can be changed in the config file. The other hadronic list currently configured is QGSP_Bert.
- For test beam environments, the particular environment must be set via ```/Detector/SelectEnvionment```, as well as the run number via ```/Detector/RunNumber```
By default, FTFP_Bert comes with the following EM and low energy lists also turned on: G4EmStandard, G4GAmmaLeptoNuclearPhys, Decay, hElasticWEL_CHIPS, hInelastic FTFP_BERT, stopping, ionInelasticFTFP_BIC, neutronTrackingCut.
- Manual construction can also be accomplished by using the macro command ```/Detector/ForcePosition true```. geometry.mac currently contains all detector construction commands available to the user. These commands include things like size and composition of absorbers, fibers and housing.
Pion and muon decay have also been turned on within the PhysicsList.cc module
3- ACTION INITALIZATION
- **Please note:** When positioning manually it is up to the user to ensure all detector geometry as well as the beam source is located inside the mother volume.
Action initialization begins within ActionInitialization.cc, where RunAction, EventAction and SteppingAction are all declared.
The RunAction module is just used to initialize the output TTree at the start of each run.
#### PhysicsList
The EventAction module is used primarily at the end of each event to fill the TTree.
- This package defaults to the standard ATLAS hadronic physics list which is is FTFP_Bert (Fritiof string model (>\~5 GeV); Bertini-style cascade (<~10 GeV)). This can be changed via macro command ```/Physics/SelectList```. The other hadronic list currently configured is QGSP_Bert.
The SteppingAction module is currently just a skeleton.
4- PRIMARY GENERATOR
The PrimaryGeneratorAction module uses G4ParticleGun to initialize the default positioning and configuration of the particle generator. By default the gun is set at the edge of the first module, centered in the (x,y) transverse plane.
5- DETECTOR RESPONSE
- By default, FTFP_Bert comes with the following EM and low energy lists also turned on: G4EmStandard, G4GAmmaLeptoNuclearPhys, Decay, hElasticWEL_CHIPS, hInelastic FTFP_BERT, stopping, ionInelasticFTFP_BIC, neutronTrackingCut.
The detector response is handled in the QuartzSD module. Each quartz rod (and notice, these are the vertical quartz rods, not the pixel rods) is set as a sensitive detector and hits within these volumes are parsed in the Quartz Sensitive Detector class (QuartzSD.cc) and QuartzHits are created and filled in Collection vectors. This allows retention of detailed information about the hit including the particular strip number it was registered in, the module, the radiator gap number, the trackID, the particleID, as well as kinematic information. This is also the stage where individual hits are turned into Cherenkov radiation and the number of Cherenkov photons retained in the acceptance of the quartz rod is calculated. This calculation finds the average number of photons created by each charged particle above threshold, shifts it by a Poisson smearing and then uses the appropriate emittance angle to determine whether the photon would have been captured by the quartz. All photons directed vertically downward in the detector are assumed to be lost, while all photons captured and directed upward are considered to be retained. This calculation also assumes Cherenkov photons are created in the quartz core and not the cladding.
The Cherenkov sampling window can be set from the config file. The min and max wavelengths are taken as inputs. The Frank-Tamm relationship is used to calculate the number of photons created across the step length and the wavelength range specified. Note, this relationship is sensitive to the charge^2, 1/(beta^2), and 1/(n^2), with the number of photons falling off linearly with wavelength.
- Pion and muon decay have also been turned on within the PhysicsList.cc module
A- VISUALISATION
#### ActionInitialization
The visualization manager is set via the G4VisExecutive class
- Action initialization begins within ActionInitialization.cc, where PrimaryGeneratorAction, RunAction, EventAction and SteppingAction are all declared.
- The RunAction module is just used to initialize the output via AnalysisManager and pass the optical flag to SteppingAction at the start of each run.
- The EventAction module is used primarily at the end of each event process hit collections and fill the output nTuples.
- The SteppingAction module is used to determine the location which the primary particles were killed, as well as kill optical photons in volumes where the optical flag is off.
#### PrimaryGeneratorAction
- The PrimaryGeneratorAction module uses G4ParticleGun to initialize the default positioning and configuration of the particle generator. By default the gun is set at the edge of the first module, centered in the (x,y) transverse plane.
- Expansion of this class will provide a generator configuration for each beam environment offered by DetectorConstruction.
#### FiberSD
- The detector response is handled in the FiberSD module. Each quartz rod is set as a sensitive detector and hits within these volumes are parsed in the Fiber Sensitive Detector class (FiberSD.cc) and FiberHits are created and filled in Collection vectors. This allows retention of detailed information about the hit including the particular fiber it was registered in, the module, the radiator gap number, the trackID, the particleID, as well as kinematic information.
- This is also the stage where individual hits generate Cherenkov radiation and the number of Cherenkov photons created is counted.
##### VISUALISATION
- The visualization manager is set via the G4VisExecutive class
in the main() function in exampleB1.cc.
The initialisation of the drawing is done via a set of /vis/ commands
in the macro vis.mac. This macro is automatically read from
the main function when the program is used in interactive running mode.
By default, vis.mac opens an OpenGL viewer (/vis/open OGL).
- By default, vis.mac opens an OpenGL viewer (```/vis/open OGL```).
The user can change the initial viewer by commenting out this line
and instead uncommenting one of the other /vis/open statements, such as
and instead uncommenting one of the other ```/vis/open``` statements, such as
HepRepFile or DAWNFILE (which produce files that can be viewed with the
HepRApp and DAWN viewers, respectively). Note that one can always
open new viewers at any time from the command line. For example, if
you already have a view in, say, an OpenGL window with a name
"viewer-0", then
/vis/open DAWNFILE
```/vis/open DAWNFILE```
then to get the same view
/vis/viewer/copyView viewer-0
```/vis/viewer/copyView viewer-0```
or to get the same view *plus* scene-modifications
/vis/viewer/set/all viewer-0
```/vis/viewer/set/all viewer-0```
then to see the result
/vis/viewer/flush
```/vis/viewer/flush```
The DAWNFILE, HepRepFile drivers are always available
- The DAWNFILE, HepRepFile drivers are always available
(since they require no external libraries), but the OGL driver requires
that the Geant4 libraries have been built with the OpenGL option.
From Release 9.6 the vis.mac macro has additional commands
- From Release 9.6 the vis.mac macro has additional commands
that demonstrate additional functionality of the vis system, such as
displaying text, axes, scales, date, logo and shows how to change
viewpoint and style. Consider copying these to other examples or
......@@ -83,27 +81,27 @@
ls or browse the available UI commands in the Application
Developers Guide, Section 7.1.
For more information on visualization, including information on how to
- For more information on visualization, including information on how to
install and run DAWN, OpenGL and HepRApp, see the visualization tutorials,
for example,
http://geant4.slac.stanford.edu/Presentations/vis/G4[VIS]Tutorial/G4[VIS]Tutorial.html
(where [VIS] can be replaced by DAWN, OpenGL and HepRApp)
The tracks are automatically drawn at the end of each event, accumulated
- The tracks are automatically drawn at the end of each event, accumulated
for all events and erased at the beginning of the next run.
B- USER INTERFACES
The user command interface is set via the G4UIExecutive class
in the main() function in zdc.cc. This script is the driver for your simulation
##### USER INTERFACES
- The user command interface is set via the G4UIExecutive class
in the main() function in zdc.cc. This script is the driver for your simulation
C- HOW TO RUN
- Execute zdc in the 'interactive mode' with visualization (must be run from the atlasZDC directory):
% ./build/zdc
- Execute zdc in the 'interactive mode' with visualization (must be run from the $JZCaPA/bin directory):
$ ./zdc
and type in the commands from run1.mac line by line:
Idle> /run/beamOn 1
Idle> /run/beamOn 1
Idle> ...
Idle> exit
or
......@@ -111,11 +109,6 @@
....
Idle> exit
- Execute zdc in the 'batch' mode from macro files
- Execute zdc in the 'batch' mode from macro files
(without visualization)
% ./build/zdc run.mac results/resultsFile.root
- Execute zdc MANY TIMES in the 'batch' mode from macro files
(without visualization) -- This is intended if you events broken up into separate runs/ttrees -- if you use this you should modify the arguments inside scan.sh
% source scan.sh
$ ./zdc -m run.mac -o results/resultsFile.root
#### Joint Zerodegree Calorimeter Prototype Analysis --- JZCaPA  
#### Created by Y.Kulinich, R.Longo and C.Lantz on 12/12/2018 ####
#### Created by Y.Kulinich, R.Longo and C.Lantz on 12/12/2018 ####
#### Migrated from CERN to UIUC Gitlab on 14th February 2019 ####
Basic structure defined and discussed during the Thursday meeting on 12/13/2018
Basic structure defined and discussed during the Thursday meeting on 12/13/2018
JZCaPA
     Analysis
......@@ -10,22 +10,22 @@ JZCaPA
          src
          userFunctions
     MonteCarlo
     2018_Utils
     2018_Utils
The project is cmake based, so you need a reasonably new cmake version ( version > 2.8 )
The standalone Analysis part requires only a root installation (https://root.cern.ch) and a xerces-c installation (http://xerces.apache.org).
Please note that xerces-c is usually available via your package installer (so easy to get installed).
The standalone Analysis part requires only a root installation (https://root.cern.ch) and a xerces-c installation (http://xerces.apache.org).
Please note that xerces-c is usually available via your package installer (so easy to get installed).
The MC part will be conditional since it requires additional software as Geant4 and all its dependencies
The corresponding README part will be written once MC will be included.
The 2018_Utils folder contains the .xml settings file encoding the useful information on 2018 beam test (automatically loaded in JZCaPA).
#### CMake and installation ####
To install the software using cmake will be trivial.
To install the software using cmake will be trivial.
In the same folder where you have JZCaPA, just do
```bash
mkdir JZCaPA_BUILD
mkdir JZCaPA_INSTALL
mkdir JZCaPA_INSTALL
```
at this stage, remember to add to your environment
```bash
......@@ -35,34 +35,35 @@ cd JZCaPA_BUILD
cmake -DCMAKE_INSTALL_PREFIX=../JZCaPA_INSTALL/ ../JZCaPA
make -j8
make -j8
make install
make install
```
please remember to re-make & make install every time you change the source code
please remember to re-make & make install every time you change the source code
#### Analysis ####
Each user can implement his/her own analysis creating a new userFunction.cpp in Analysis/userFunctions folder.
Please check AnalysisExample.cpp if you're looking for a basic template.
Each user can implement his/her own analysis creating a new userFunction.cpp in Analysis/userFunctions folder.
Please check AnalysisExample.cpp if you're looking for a basic template.
The code has been updated and improved considerably in the last period, so further description will be provided afterwards.
The code has been updated and improved considerably in the last period, so further description will be provided afterwards.
They are well commented by Yakov for each available method.
A doxygen documentation can also be created following the instruction below.
#### Monte Carlo ####
Monte Carlo folder added on 12/19/2018.
What's there at the moment is exactly what has been done so far by Mike Phipps (michael.william.phipps@cern.ch).
The only modifications implemented were to ensure the compatibility with newer Geant4 versions (>= 10.4.3).
Such changes have been implemented in order to allow also for backward compatibility with older Geant4 versions.
The Monte Carlo is an adapted version of what was provided by Mike Phipps (michael.william.phipps@cern.ch).
The package was heavily modified for adaptability so it may be used in the ZDC R&D. The overall structure now closely mimics geant4.x.x/examples/extended/analysis/AnaEx01.
Additionally, the package is able to import detector configurations from XML to replicate test beam runs.
Please note that MonteCarlo support is *DISABLED* by default. This choice is meant to avoid people not interested in MC to install Geant4 and the other dependencies.
In order to enable it, add the option
Please note that MonteCarlo support is *DISABLED* by default. This choice is meant to avoid people not interested in MC to install Geant4 and the other dependencies.
In order to enable it, add the option
```bash
-DJZCaPA_ENABLE_MC=YES
-DJZCaPA_ENABLE_MC=YES
```
while cmaking. Please note that you need the Geant4 toolkit (and the corresponding dependencies) to successfully enable the MC support.
More details will come in the future.
while cmaking. Please note that you need the Geant4 toolkit (and the corresponding dependencies) to successfully enable the MC support.
More details will come in the future.
#### Doxygen documentation ####
First, check that doxygen is installed on your machine.
......@@ -74,7 +75,7 @@ doxygen JZCaPA_doxy.cnf
```
This will generate for you $JZCaPA/html and $JZCaPA/latex folder.
If you start $JCaPA/html/index.html with your browser, you will get your doxygen docs (surfable).
Alternatively, you can compile the latex static documentation in $JZCaPA/latex
Alternatively, you can compile the latex static documentation in $JZCaPA/latex
#### Structure of processed data ####
......@@ -89,7 +90,7 @@ Each branch RawCn and Cn will be of size 1024 (corresponding to the number of sa
Therefore for each event we have N vectors of size 1024.
RawCn corresponds to the "raw" output, what one would see on the DRS scope.
Cn corresponds to processed output, as determined by rdcaqAnalysis.
One can take the RawCn and reprocess it as they wish using JCaPA analysis methods (or implementing new ones).
One can take the RawCn and reprocess it as they wish using JCaPA analysis methods (or implementing new ones).
Also, in the tree, there are branches that come from rcdaqAnalysis which have information on the output of each channel.
These are branches such as MaxCharge. Lets say there are M of them.
......@@ -101,30 +102,30 @@ Summarizing, there are
N branches of size 1024 for the channel waveforms.
and
M branches of size N for the processed data from rcdaqAnalysis. M is an arbitrary number.
#### XML Setting file support ####
Since 29th January you will need to install also xercesc as a dependency to compile JZCaPA. This is rather straight forward on machines where you have root access.
You've just to run
#### XML Setting file support ####
Since 29th January you will need to install also xercesc as a dependency to compile JZCaPA. This is rather straight forward on machines where you have root access.
You've just to run
```bash
your_package_installer install xerces-c
your_package_installer install xerces-c
```
If you are on a cluster and xerces-c is not installed/available by default, is straightforward to checkout the source from http://xerces.apache.org/xerces-c/download.cgi and compile it following the instructions available on the webpage.
If you are on a cluster and xerces-c is not installed/available by default, is straightforward to checkout the source from http://xerces.apache.org/xerces-c/download.cgi and compile it following the instructions available on the webpage.
If you are going for the source installation, please note that, for an easier detection by cmake, it is adviced to define the variables $XERCESC_DIR, $XERCESC_INCLUDE_DIR and $XERCESC_LIBRARY
Thanks to the .xml settings file support (hopefully) all the 2018 test beam settings will be loaded automatically when starting the analysis and associated to detectors objects (ZDC1, ZDC2 or RPD).
Thanks to the .xml settings file support (hopefully) all the 2018 test beam settings will be loaded automatically when starting the analysis and associated to detectors objects (ZDC1, ZDC2 or RPD).
More information can be added if needed, just formulate a request or do the implementation yourself!
#### Install JZCaPA on LXPLUS ####
Given the forthcoming migration to centos 7 of the whole lxplus system (2nd April 2019), the configuration was established directly for this OS.
The alias of lxplus will switch automatically to centos 7 from 2nd April 2019. Until this time, to profit of this configuration do
#### Install JZCaPA on LXPLUS ####
Given the forthcoming migration to centos 7 of the whole lxplus system (2nd April 2019), the configuration was established directly for this OS.
The alias of lxplus will switch automatically to centos 7 from 2nd April 2019. Until this time, to profit of this configuration do
```
ssh your_username@lxplus7.cern.ch
ssh your_username@lxplus7.cern.ch
```
If you are using bash, after logging in, add ${JZCaPA}/Utils/jcapa_env_lxplus.sh to your .bashrc
Please be sure to comment out the source of other softwares/compilers. This may conflict with the view that is being loaded by the script.
Please be sure to comment out the source of other softwares/compilers. This may conflict with the view that is being loaded by the script.
After this modification, log-out and in again. You will have all the dependencies needed (ROOT >= 6.08, Geant4 and xerces-c) loaded in your environment.
Go to the JZCaPA_BUILD directory and cmake using the flag
Go to the JZCaPA_BUILD directory and cmake using the flag
```
-DJZCaPA_ON_LXPLUS=YES
......@@ -132,7 +133,7 @@ Go to the JZCaPA_BUILD directory and cmake using the flag
and compile the software (with or w/o MC support, depending on your needings). The software should now compile fully.
#### Install JZCaPA on UIUC ####
#### Install JZCaPA on UIUC ####
The environment for UIUC is built in Centos 7 and uses an HTCondor cluster, similar to what is available on lxplus. However, a VPN is needed
to access these resources. Instructions for download and setup can be found at https://techservices.illinois.edu/services/virtual-private-networking-vpn/download-and-set-up-the-vpn-client
When you are connected to the VPN, you can access machines by
......@@ -153,5 +154,5 @@ echo 'source ${JZCaPA}/Utils/jzcapa_env_uiuc.sh' >> ~/.bashrc
The first line sources the required software so you can install JZCaPA, and the second line sources it for subsequent use.
You will have all the dependencies needed (ROOT 6.16, Geant4 and xerces-c) loaded in your environment.
Now you can follow the install instructions from the top and compile the software (with or w/o MC support, depending on your needs).
Now you can follow the install instructions from the top and compile the software (with or w/o MC support, depending on your needs).
The software should now compile fully.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment