Support #21789
larsim/EventGenerator/GENIE/GENIEGen_module.cc wastes a lot of CPU time
0%
Description
There's something in this code that causes this VERY lengthy calculation (20+ minutes):
%MSG %MSG-i Root_Information: GENIEGen:generator@Construction TGeoManager::Weight() 29-Jan-2019 12:02:33 CST ModuleConstruction Computing analytically weight of volCryostat %MSG %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->ROOTGeoManager(), geo->ROOTFile(), 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.
History
#1 Updated by Kyle Knoepfel about 2 years ago
- Assignee set to Kyle Knoepfel
- Status changed from New to Assigned
We will investigate.
#2 Updated by Robert Hatcher about 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).