clarkmcgrew / edep-sim Goto Github PK
View Code? Open in Web Editor NEWAn energy deposition simulation based on G4. The default output is a ROOT tree, but the simulation can also be directly called as a library.
License: Other
An energy deposition simulation based on G4. The default output is a ROOT tree, but the simulation can also be directly called as a library.
License: Other
This is a half question and a half observation :)
As I mentioned in issue 25, it looks like Process
and Subprocess
attributes of TG4TrajectoryPoint
are filled with 0
for particles injected by a user. A few points on this:
0
for G4ProcessSubtype
enum. Shouldn't there be?G4ProcessType
enum entry associated to the value 0
is kProcessNotDefined
.kProcessNotDefined
rather than something like kProcessInjected
(or something that's more uniquely associated with the fact they are primary particles injected by a user)?Thanks!
Hi,
while working on the external muon ID of DUNE ND, I wrote the following algorithm to see if a track passes through a pair of readout strips in an RPC, it looks like this:
The detector: The RPC is placed just outside the KLOE magnet, first layer being Foam0
, then XX copper Strips
, then bakelite etc and the gas gap, after the gas gap, again bakelite etc and in the end Foam1
followed by 'Strip YY'. So the order is Faom0->StripXX-> ... -> gas gap -> ... -> StripYY -> Foam1
The algorithm: I first check if I have hits
in the gas gap, if there are, then I scan that track using Points
class and access the node names corresponding to those Points
, I want to find the particular XX and YY strips in its path.
The issue: most of the time I find YY Strips
as well as Foam1
but do not find any XX Strip
in the track! That is so weird!
My thoughts and tests:
Points
could be wide enough to miss a thin node (0.5 mm thick strips), so I started subdividing the gap between two points that are widely separated (~0.25 mm), I still don't find the XX strips
!mean points
are not stored in the root file!0.5 mm
strips are now 0.5 cm
, I still find majority of tracks have YY Strips
but no XX Strips
names when accessed through FindNode(x,y,z)->GetName()
where (x,y,z)
are coordinates of Points
accessed using event->Trajectories[trackid].Points.at(ii).Position.X(), Y(), Z()
.By the way, in the mac file
I specified /edep/db/set/trajectoryBoundary charged:EMIRPC_lv_PV
where EMIRPC_lv
is the logical volume containing the whole RPC. I alo thought, maybe specifying each strip name would force Points
to not miss any of the strips, so I did include edep/db/set/trajectoryBoundary charged:volEMIRPCBakelite_0_PV
and all other (84 XX and 212 YY strips!).. which shouldn't be done I suppose because there will be thousands of components in some detectors, for example, straws in the STT
volume, writing each node name down seems impractical. Can you please tell me what I am doing wrong, or maybe Points
has limitations?
Thanks
A generic Birks calculation should be added for materials that are not Liquid argon. The implementation exists, but it requires setting the ionization properties for a material. I don't know how to do that via GDML. This needs advice on how to attach new material properties to materials defined in GDML.
GoTo command will be useful if I want to go directly to a given event number.
I have installed edep-sim using the Expert Installation instructions as I wanted a custom install location. Your installation instructions to not include what environmoent variables are needed to run the software. I added the bin/
directory to my path so I can run the edep-sim
command but now I am seeing the following error:
edep-sim: error while loading shared libraries: libedepsim.so: cannot open shared object file: No such file or directory
Is there an environment variable along the lines of $EDEPSIM_LIBRARY_PATH
I need to have pointing to libedepsim.so
? If so, are there any other environment variables that I need for the installation to work? These things should be included in the README.md
.
There seem to be an issue with values filling TG4TrajectoryPoint::Process
and TG4TrajectoryPoint::Subprocess
attributes. If I generate an event with particles (defined by me), these attribute values are set to 0
. In TG4Trajectory.h, G4ProcessType
enum is defined with the value 0
associated with kProcessNotDefined
. For G4ProcessSubtype
, 0
is not defined but I assume this is the right values to be filled for user-injected particles.
Here's the issue:
If I look at the 2nd and 3rd events where identical set of particles are injected into Geant4 world for tracking, these attributes (Process
and Subprocess
) are filled with non-zero values. This seems like a bug but please correct me if I am missing something.
Here's a sample data file produced using edep-sim.
Here is a print-out of TrackId
, ParentId
, Process
, and Subprocess
attribute values for the first three events.
Entry 0
Track ID 0 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 1 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 2 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 3 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 4 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 5 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 6 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 7 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 8 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 9 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 10 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Track ID 11 Parent ID -1 G4ProcessType 0 G4SubProcessType 0
Entry 1
Track ID 0 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 1 Parent ID -1 G4ProcessType 2 G4SubProcessType 12
Track ID 2 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 3 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 4 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 5 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 6 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 7 Parent ID -1 G4ProcessType 2 G4SubProcessType 13
Track ID 8 Parent ID -1 G4ProcessType 2 G4SubProcessType 22
Track ID 9 Parent ID -1 G4ProcessType 2 G4SubProcessType 22
Track ID 10 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 11 Parent ID -1 G4ProcessType 2 G4SubProcessType 22
Entry 2
Track ID 0 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 1 Parent ID -1 G4ProcessType 2 G4SubProcessType 13
Track ID 2 Parent ID -1 G4ProcessType 4 G4SubProcessType 111
Track ID 3 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 4 Parent ID -1 G4ProcessType 2 G4SubProcessType 22
Track ID 5 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 6 Parent ID -1 G4ProcessType 2 G4SubProcessType 22
Track ID 7 Parent ID -1 G4ProcessType 2 G4SubProcessType 13
Track ID 8 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 9 Parent ID -1 G4ProcessType 4 G4SubProcessType 111
Track ID 10 Parent ID -1 G4ProcessType 2 G4SubProcessType 2
Track ID 11 Parent ID -1 G4ProcessType 2 G4SubProcessType 22
Below, you find a simple python script I am running to printout this information.
from ROOT import TChain
import sys
ch=TChain('EDepSimEvents')
ch.AddFile(sys.argv[1])
for idx in range(ch.GetEntries()):
print('\nEntry',idx)
ch.GetEntry(idx)
for p in ch.Event.Trajectories:
if p.GetParentId() >= 0: continue
msg1 = 'Track ID %d Parent ID %d ' % (p.GetTrackId(), p.GetParentId())
pt = p.Points.front()
msg2 = 'G4ProcessType %d G4SubProcessType %d ' % (pt.GetProcess(),pt.GetSubprocess())
print(msg1,msg2)
Hi Clark,
Thanks for adding the feature of the step limit that was needed for the simulation in the gas TPC. I have a small question,
do you think it would be better to implement this feature as a G4Region?
Such example would be:
G4Region* reg = G4RegionStore::GetInstance()->GetRegion(name);
G4UserLimits* limits = new G4UserLimits();
limits->SetMaxAllowedStep(2.0*CLHEP::mm);
reg->SetUserLimits(limits);
For now, the step limit auxiliary value is assigned to a specific volume in the gdml but daughter volumes don't get the step limit set up in that way.
Hi, while building with edep-build doc
I am getting these errors.
[ 18%] Built target edep-disp Scanning dependencies of target edepsim [ 19%] Building CXX object src/CMakeFiles/edepsim.dir/EDepSimArbEMField.cc.o [ 20%] Building CXX object src/CMakeFiles/edepsim.dir/EDepSimArbElecField.cc.o [ 21%] Building CXX object src/CMakeFiles/edepsim.dir/EDepSimArbMagField.cc.o [ 22%] Building CXX object src/CMakeFiles/edepsim.dir/EDepSimBuilder.cc.o /home/atanu/Software/EDEP-SIM/src/EDepSimBuilder.cc: In member function ‘G4VisAttributes EDepSim::Builder::GetColor(G4Material*, double)’: /home/atanu/Software/EDEP-SIM/src/EDepSimBuilder.cc:170:50: error: ‘Invisible’ is not a member of ‘G4VisAttributes’ 170 | if (fOpacity < -9.9) return G4VisAttributes::Invisible; | ^~~~~~~~~ /home/atanu/Software/EDEP-SIM/src/EDepSimBuilder.cc:172:49: error: ‘Invisible’ is not a member of ‘G4VisAttributes’ 172 | if (opacity < -9.9) return G4VisAttributes::Invisible; | ^~~~~~~~~ make[2]: *** [src/CMakeFiles/edepsim.dir/build.make:102: src/CMakeFiles/edepsim.dir/EDepSimBuilder.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:325: src/CMakeFiles/edepsim.dir/all] Error 2 make: *** [Makefile:130: all] Error 2
System info:
OS: Linux Mint 20.3
cmake version: 3.16.3
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
ROOT Version: 6.26/02
Geant4 version: 11.0.1
CLHEP 2.4.5.1
Hello,
I am trying to generate a sample of cosmic rays with edep-sim
starting from a CORSIKA file. I wrote a converter that creates a RooTracker file starting from the CORSIKA output and I feed it to edep-sim
using this macro:
/generator/kinematics/rooTracker/input DAT000001.root
/generator/kinematics/set rooTracker
/generator/position/set free
/generator/add
However, I get a Segmentation fault
so I am not sure how to debug it further. You can find the DAT000001.root file here.
Thank you,
Roberto
Running edep-sim
from an in-source build of master
seems to allow an error free run.
Running it from an installed location leads to errors due to missing headers. The installation I'm testing is created using spack install edepsim@master
using the Spack fork in my GitHub area. But, I think this problem is unrelated to Spack per se but rather due to running from an installation location other than where the build occurred.
Here is the error output:
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for /opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4PrimaryVertex.h
requested to autoload type TG4PrimaryVertex
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for /opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4PrimaryVertex.h
requested to autoload type TG4PrimaryParticle
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for /opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4Trajectory.h
requested to autoload type TG4Trajectory
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for /opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4Trajectory.h
requested to autoload type TG4TrajectoryPoint
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for /opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4HitSegment.h
requested to autoload type TG4HitSegment
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for /opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4Event.h
requested to autoload type TG4Event
libedepsim dictionary payload:46:10: fatal error: '/opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4PrimaryVertex.h' file not found
#include "/opt/spack/spack/var/spack/stage/edepsim-master-aizbsjr3dc2qyhbbk6cd66q6qckgixvn/edep-sim/src/TG4PrimaryVertex.h"
^
Error in <TInterpreter::AutoParse>: Error parsing payload code for class TG4HitSegment with content:
The job does actually complete and a quick check of the output ROOT file shows no immediate problems but I've yet to get edep-disp
(which also gives errors like the above) to show meaningful results on the file.
That path referenced in the error is a temporary build area and doesn't exist after installation. It looks like something in the build is baking-in this path.
FWIW, setting ROOT_INCLUDE_PATH
to point at directories in a copy of edep-sim
source doesn't help.
The current implementation of ionization saturation (i.e. Birks saturation) assumes that the calculation is going to be done internal to edep-sim. It would be very good if the saturation calculation could be moved into the detector response simulatiion (i.e. outside of edep-sim).
This is filed in response to a merge request from @tomjunk which updates to std::shuffle. The old bit of code has problems since it's using a different generator relative to the rest of the simulation, and has problems with repeatability.
The preferred solution is use the generator interface provided by G4. This is to remind me to fix it!
I have noticed, when we process some geometry using the density option and including many physics volumes with same logical volume. EDEP-SIM locates the event in only one out of many physical volume.
Hello Clark,
I am trying to install edepsim 3.2.0 on my MacBook Pro 16 2019 model (macOS Monterey).
I have GEANT4 10.07 p03 and ROOT 6.24.04 installed in my system. However I am having the following errors while I am trying to build it with CMake. It would be really nice if there could be some comments about the same.
log.txt
Pls find the output logs here.
After PR #2 is applied a remaining problem is that loading libedepdisp
into ROOT gives two categories of error:
$ root -l
root [0] gSystem->Load("libedepsim")
(int) 0
root [1] gSystem->Load("libedepdisp")
Warning in <TClassTable::Add>: class TG4PrimaryVertex already in TClassTable
Warning in <TClassTable::Add>: class TG4PrimaryParticle already in TClassTable
Warning in <TClassTable::Add>: class TG4Trajectory already in TClassTable
Warning in <TClassTable::Add>: class TG4TrajectoryPoint already in TClassTable
Warning in <TClassTable::Add>: class TG4HitSegment already in TClassTable
Warning in <TClassTable::Add>: class TG4Event already in TClassTable
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for TG4PrimaryVertex.h
requested to autoload type TG4PrimaryVertex
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for TG4PrimaryVertex.h
requested to autoload type TG4PrimaryParticle
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for TG4Trajectory.h
requested to autoload type TG4Trajectory
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for TG4Trajectory.h
requested to autoload type TG4TrajectoryPoint
Error in cling::AutoloadingVisitor::InsertIntoAutoloadingState:
Missing FileEntry for TG4HitSegment.h
requested to autoload type TG4HitSegment
Error in <TCling::RegisterModule>: cannot find dictionary module libedepdisp_edepsim_rdict.pcm
(int) 0
The first is I think due to the "stolen" pattern in display/CMakeLists.txt
and the second is maybe because the edepdisp_edepsim
dictionary files are not being installed. Given the "stolen" pattern, I'm not sure what the "right" fix is. My guess is there is a conflict of intentions between in-source build/use and installed use.
Finalize arbitrary fields and clean up the merge request.
Getting a segfault for attempting to access TTree branch in "my usual" way:
$> python
>>> from ROOT import TChain
>>> ch=TChain("EDepSimEvents")
>>> ch.AddFile("tako.root")
>>> ch.GetEntries()
10
>>> ch.GetEntry(0)
>>> ch.Trajectories
<cppyy.gbl.std.vector<TG4Trajectory> object at 0x5b38630>
>>> ch.Trajectories.size()
8737931403336129456
>>> ch.Trajectories.at(0)
*** Break *** segmentation violation
Maybe there's an incomplete dictionary generated for this object?
Is this not supported in edep-sim
?
For a reference, data file is generated using inputs/example.gdml
, also available here.
Thanks for your help!
Make Edep-sim usable with gdml
with TG4EllipticalTube (TGeoEltu)
A solution could be:
diff --git a/src/EDepSimRootGeometryManager.cc b/src/EDepSimRootGeometryManager.cc
index 9436ee3..46db263 100644
--- a/src/EDepSimRootGeometryManager.cc
+++ b/src/EDepSimRootGeometryManager.cc
@@ -15,6 +15,7 @@
#include <TGeoTrd2.h>
#include <TGeoTrd2.h>
#include <TGeoSphere.h>
#include <TGeoPgon.h>
+#include <TGeoEltu.h>
#include <TGeoArb8.h>
#include <TGeoBoolNode.h>
#include <TGeoCompositeShape.h>
@@ -41,6 +42,7 @@
#include <G4Sphere.hh>
#include <G4Polyhedra.hh>
#include <G4Polycone.hh>
+#include <G4EllipticalTube.hh>
#include <G4Trap.hh>
#include <G4SubtractionSolid.hh>
#include <G4UnionSolid.hh>
@@ -232,6 +234,14 @@ TGeoShape* EDepSim::RootGeometryManager::CreateShape(const G4VSolid* theSolid,
box->GetYHalfLength()/CLHEP::mm,
box->GetZHalfLength()/CLHEP::mm);
}
const G4EllipticalTube* eltube = dynamic_cast<const G4EllipticalTube*>(theSolid);
// Create an elliptical tube.
double a = eltube->GetDx()/CLHEP::mm;
double b = eltube->GetDy()/CLHEP::mm;
double dz = eltube->GetDz()/CLHEP::mm;
theShape = new TGeoEltu(a, b, dz);
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.