Necessary Maintenance #11978

TPC Active Volume

Added by Tyler Alion about 5 years ago. Updated over 3 years ago.

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


Estimated time:


Briefly: Either we need to change LArG4 to use track inside "volTPC" rather than "volTPCActive", or we need to change the Geometry interface to save the transformation from volTPC to volTPCActive.

LArG4 propagates drift electrons for activity only inside volumes named "volTPCActive." The Geometry interface, however does not know exactly where volTPCActive is inside of volTPC. In TPCGeo, there exist separate dimensions for the TPC and TPCActive (ActiveHalfWidth, etc...), and if anyone is using Active* dimensions about the TPC world-coordinate center, they are assuming the active volume is centered in the the TPC. This is never the case since the active volume is shifted away from the wire planes in the drift direction.

This is embedded in a larger issue which may or may not ever be resolved: Just have LArG4 track activity in the entire TPC volume. Activity between the wire planes is otherwise lost, which affects calorimetry and track/shower shape on top of the planes. I prefer this as the better solution, but it would require more thought and care. If we decided to make this change, then active vs. normal TPC boundaries would cease to be a problem.

Whatever is decided, the geometry initialization should print out the maximum active world-coordinate boundaries in all 6 directions. "Maximum" means the boundaries of the larger mostly-active rectangular prism comprised of one or more TPC volumes. This 4-line printout has been an extremely valuable in my experience, and inherently belongs in the initialization output. This gives a direct and immediate answer to any one of the many users wondering:
- where to generate event vertices
- active volume dimensions for the flux
- boundaries from which to apply fiducial cuts

Here is the basic code I use to find these maximum boundaries (notice I can only get the TPC center here, so I use TPC boundaries instead of active boundaries):

    for (geo::TPCGeo const& TPC: this->IterateTPCs()) {

      // get center in world coordinates
      double origin[3] = {0.};
      double center[3] = {0.};
      TPC.LocalToWorld(origin, center);

      double tpcDim[3] = {

      if( center[0] - tpcDim[0] < activeBounds[0] ) activeBounds[0] = center[0] - tpcDim[0];
      if( center[0] + tpcDim[0] > activeBounds[1] ) activeBounds[1] = center[0] + tpcDim[0];
      if( center[1] - tpcDim[1] < activeBounds[2] ) activeBounds[2] = center[1] - tpcDim[1];
      if( center[1] + tpcDim[1] > activeBounds[3] ) activeBounds[3] = center[1] + tpcDim[1];
      if( center[2] - tpcDim[2] < activeBounds[4] ) activeBounds[4] = center[2] - tpcDim[2];
      if( center[2] + tpcDim[2] > activeBounds[5] ) activeBounds[5] = center[2] + tpcDim[2];

    } // for all TPC

    mf::LogVerbatim("GeometryCoreActiveBounds") << "Active Boundaries: " 
                        << "\n\tx: " << activeBounds[0] << " to " << activeBounds[1]
                        << "\n\ty: " << activeBounds[2] << " to " << activeBounds[3]
                        << "\n\tz: " << activeBounds[4] << " to " << activeBounds[5]
                        << std::endl;


#1 Updated by Gianluca Petrillo about 5 years ago

  • Category set to Geometry
  • Status changed from New to Accepted

(might become "Simulation" according to the solution pursued)

The larger solution is worth a discussion among LArSoft stakeholders.

#2 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

A few additional methods query the active volume of a TPC were added with larcorealg:db191d930 .
Those include fetching the center of the active volume (geo::TPCGeo::GetActiveVolumeCenter()) and the direct access to the volume itself.

This addresses the "urgent" issue.

#3 Updated by Gianluca Petrillo over 3 years ago

  • Description updated (diff)

Also available in: Atom PDF