Support #21789

larsim/EventGenerator/GENIE/ wastes a lot of CPU time

Added by Robert Hatcher almost 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


There's something in this code that causes this VERY lengthy calculation (20+ minutes):

%MSG-i Root_Information:  GENIEGen:generator@Construction TGeoManager::Weight()  29-Jan-2019 12:02:33 CST ModuleConstruction
Computing analytically weight of volCryostat
%MSG-i Root_Information:  GENIEGen:generator@Construction TGeoManager::Weight()  29-Jan-2019 12:25:23 CST ModuleConstruction
Computed weight: 2238423.939670 [kg]

I don't think this should be necessary, so it would be useful to eliminate it when its unneeded to avoid chewing through a large amount of CPU time.

I think it comes from the geo->TotalMass() call at:

fGENIEHelp = new evgb::GENIEHelper(GENIEconfig, 
                   geo->TotalMass(pset.get< std::string>("TopVolume").c_str()));

Looking at the NuTools code, GENIEHelper only needs the detector mass in the case of:

 if ( fFluxType.find("histogram") == 0 && fEventsPerSpill < 0.01 ) {

That is, when using histogram fluxes (but no one should be using those for production anymore; they're only good for quick-and-dirty cases) and performing overlay (i.e. pileup in the near detector) by cutting off overlaying not based on a fixed number of events but based on POTs.

For NOvA this TotalMass calculation is inperceptable. But for multiple instances of LArSoft (DUNE, and at least one other experiment) this seems to be very, very, very expensive. And in this case unnecessary.

Though I do also wonder whether an unnecessarily complex geometry (that slows down the mass calculation) could also be impacting event generation speed as GENIE must propagate flux rays through the geometry to see the mass distribution along the ray [remember Prob(interaction) ~= cross-section * mass]. If there are lots of elements within the "TopVolume" (say wires) that contribute little-to-nothing to the mass but must be checked for ray interception then this slows things down while contributing nothing to the fidelity of the simulation.


#1 Updated by Kyle Knoepfel almost 2 years ago

  • Assignee set to Kyle Knoepfel
  • Status changed from New to Assigned

We will investigate.

#2 Updated by Robert Hatcher almost 2 years ago

  • Assignee changed from Kyle Knoepfel to Robert Hatcher

This was meant to be self-assigned. I understand the issue, just need to plug in a fix (and possibly backup "fix" or at least warning/error to NuTools).

Also available in: Atom PDF