Looking for ways to optimize code for faster execution

[Pete]

I am simulating an electron avalanche using the same method as shown in the GEM example. For my case, there are two main differences:

1. Instead of creating 10 random electrons at a given z0, the primary electrons are created from a track using Heed.
2. Instead of using the AvalancheMC to drift the ions, I use DriftLineRKF. This seems to speed things up by a little and doesn’t seem to create any significant difference to the signals.

As expected, this increases the runtime by a significant amount comparing to the example shown in GEM. Here is the part of my code that is responsible for creating the avalanche and drifting ions:

 double xc = 0., yc = 0., zc = 0., tc = 0., ec = 0., extra = 0.;
 int nc = 0;
 while (track.GetCluster(xc, yc, zc, tc, nc, ec, extra)) {`
    for (int k = 0; k < nc; ++k) {
      double xe = 0., ye = 0., ze = 0., te = 0., ee = 0.;
      double dx = 0., dy = 0., dz = 0.;
      track.GetElectron(k, xe, ye, ze, te, ee, dx, dy, dz);
      aval.AvalancheElectron(xe, ye, ze, te, ee, dx, dy, dz);
      const int np = aval.GetNumberOfElectronEndpoints();
      double xe1, ye1, ze1, te1, e1;
      double xe2, ye2, ze2, te2, e2;
      double xi1, yi1, zi1, ti1;
      double xi2, yi2, zi2, ti2;
      int status;
      for (int j = np; j--;) {
        aval.GetElectronEndpoint(j, xe1, ye1, ze1, te1, e1, 
                                    xe2, ye2, ze2, te2, e2, status);
        drift.DriftIon(xe1, ye1, ze1, te1);
      }
    }
  }

Is there any way to make this part of the program run faster?

[jblomer]

@hschindl Perhaps you have an idea?

[hschindl]

Hi,
apologies for the delayed response. It’s a very good question but I’m afraid I probably don’t have a good answer.

If your program is derived from the GEM example, then one trivial thing you can do (and which you’ve probably done already) is to switch off visualization of the drift lines.
A significant fraction of the time is typically spent on the look-up/interpolation of the electric field. It therefore helps if - by smart meshing or exploiting symmetries of your geometry - you somehow manage to reduce the size of your field map, but that’s of course not always easy.
You could also set an upper limit of the number of electrons in the avalanche using the function EnableAvalancheSizeLimit, but that does affect your signal.
There is definitely also significant room for speeding up the code by making better use of modern CPUs and using modern programming techniques (but this will need some work).
Best regards,
Heinrich

[Pete]

Hi,

Thank you for your reply. I am not sure if this is related, but I have a follow-up question.

When my code is running. It often outputs this:

MediumMagboltz::GetElectronCollisionRate:
    Rate at 43.9911 eV is not included in the current table.
    Increasing energy range to 46.1907 eV.
AvalancheMicroscopic::TransportElectron: Increasing null-collision rate by 5%.

What does this mean? Does it slow down my program if it happens too often?

[hschindl]

Hi,
by default, MediumMagboltz creates a table of the electron-atom/molecule cross-sections from 0 to 40 eV. If an electron energy higher than that is encountered, this table is updated, with the upper limit of the table increased by 5%. This will indeed slow down a bit the first avalanche. To avoid this from happening, you could set the upper energy limit upfront, e. g. to 200 eV:

gas.SetMaxElectronEnergy(200.);