clarkmcgrew / edep-sim Goto Github PK

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

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.

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.

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!

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.

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

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!

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.

GoTo command will be useful if I want to go directly to a given event number.

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)

Finalize arbitrary fields and clean up the merge request.

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:

1. There is no entry associated to value 0 for G4ProcessSubtype enum. Shouldn't there be?
2. The G4ProcessType enum entry associated to the value 0 is kProcessNotDefined.

• Is this only assigned to particles injected by a user? Or is it used for any other way for a particle to appear in Geant4 world?
• I am guessing it is exclusively for particles injected by a user (or a generator). Is there a reason for calling it 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!

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.

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);
}

• else if (geometryType == "G4EllipticalTube") {

•    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);
  

• }
  else if (geometryType == "G4Tubs") {
  const G4Tubs* tube = dynamic_cast<const G4Tubs*>(theSolid);
  // Root takes the angles in degrees so there is no extra
  (END)

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.

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

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.

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:

1. I thought, maybe the gap among points of the 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!
2. So, I thought maybe, node names are saved corresponding to each point of the "Points". subdividing the gaps may not help because maybe node names corresponding to those mean points are not stored in the root file!
3. So, as a desperate test, I increased the dimensions of my components 10 times, 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