search

alcap-org / g4sim

Simulation toolkit based on Geant4 and ROOT
http://wuchen1106.github.io/g4sim/
2 stars 2 forks source link

g4sim running slow for me #27

Closed AndrewEdmonds11 closed 10 years ago

AndrewEdmonds11 commented 10 years ago

In today's meeting we discussed that 1M muons should only take 10 minutes and not two hours. I will run a profiler to see what's happening but here are the possibilities we discussed:

I will update this issue with what I find.

millerj2111 commented 10 years ago

Andy, Please be careful about killing particles that go beyond detectors, they can produce troublesome secondaries we need to know about. --Jim

Date: Wed, 10 Sep 2014 12:48:46 From: AndrewEdmonds11 notifications@github.com Reply-To: alcap-org/g4sim <reply@reply.gi thub.com> To: alcap-org/g4sim g4sim@noreply.github.com Subject: [g4sim] g4sim running slow for me (#27)

In today's meeting we discussed that 1M muons should only take 10 minutes and not two hours. I will run a profiler to see what's happening but here are the possibilities we discussed:

  • target position mode slows things down because the spread is too large
  • change multiple scattering for coulomb scattering
  • kill particles that go beyond all the detectors

I will update this issue with what I find.

Reply to this email directly or view it on GitHub: https://github.com/alcap-org/g4sim/issues/27

AndrewEdmonds11 commented 10 years ago

Please be careful about killing particles that go beyond detectors, they can produce troublesome secondaries we need to know about.

Yes, I was only thinking about having this for the current tolerances study.

I've just run the profiler on a 1000 event run and it seems it's because of the target position mode. There seem to be ~25M calls to CLHEP::RandFlat::shoot() in PrimaryGeneratorAction::SetRandomPosition()!

Running with the gRand position mode, there are only 3000 (1 for each coordinate) calls to the equivalent CLHEP::RandGausQ::shoot().

The target position mode is nice because it ensures we have primaries generated at all points in the target so I'd like to keep using it. Currently, points are generated inside a 10cm x 10cm x 10cm box and then checked to see if they lie inside the target so I will see if I can reduce that tomorrow.

jrquirk commented 10 years ago

If the target is 10cm x 10cm x 0.0001 cm, that mean that 0.001 % of the time you're getting it inside the target. This has come up before, but to repeat just generate the primary vertex in local coordinates to ensure 100% of the time you're in the target and then transform to global coordinates.

thnam commented 10 years ago

@AndrewEdmonds11 Since we know the dimensions of the target, we can just:

Sure this is not a general solution but we can live with that, I think. I did that on my branch and accidentally merged to the master (sorry ...): https://github.com/alcap-org/g4sim/blob/master/src/PrimaryGeneratorAction.cc#L350-L408

Later we can improve it, such as implement an interface to do the transformation from the configuration file.

AndrewEdmonds11 commented 10 years ago

Thanks, Nam. That looks good.

Because I'm rotating the target for the tolerances, I'll look into changing the hard-coded rotation to use the value it is.

AndrewEdmonds11 commented 10 years ago

It turns out that commit was already in master before I branched off for tolerances. So I changed the position spread to be x=100mm, y=100mm and z=0.1mm and I managed to save about a third of the running time on a 100k muon run (for my 1M muon, 2 hour runs this would reduce by about 40 minutes) which doesn't seem like enough to me.

I'll look into changing the physics model as well

AndrewEdmonds11 commented 10 years ago

So I further changed my spread to x=50mm, y=50mm and z=0.05mm since PrimaryGeneratorAction gets random numbers as +- these values.

Also, there were different rotations being applied to the target geometry and the primary vertex. In the geometry we have Euler angles: phi=45 deg, theta=90 deg psi=0 deg and in the primary generator we had a -45 deg rotation around the y-axis.

I think this meant that the "thickness" dimension of the target was along a different axis (i.e. we would need to have spread of 0.05mm on a different axis), so I have changed it to match the geometry.

It now runs quite a bit quicker (100k events: 14min --> 8 min) and instead of getting 2M calls to CLHEP::RandFlat::shoot() in a 100 event run, I now get ~335000 (still not the optimal 300 but this call is no longer so high up the callgraph).

I will now close this issue and open another one for dehardcoding the rotation