Distance to surface for subtractions

[tdixon97]

Currently distance to surface is only implemented for generic polycones and not subtractions.
@EricMEsch worked on writing out the Geant4 calculation of distance and understands well how this is done, are you also interested in adding this feature to this package? This is needed since when we do post-processing we sometimes want to compute the distance to just some surfaces (eg. only n+ or only p+)
I don't think it should be so difficult if you follow the implementation in Geant4.

[EricMEsch]

I can have a look at this. The main issue with subtractions is, that they basicly calculate the distance to their individual components. This means also a method has to be implemented for each of their original base parts. I am not sure what kind of subtractions are currently used? If it is only G4GenericPolycone with G4Box it should not be difficult.

The main time investment for me is going to have a look into the structure of this python module and understand how all of the objects and information etc. are handled (but i guess i should do this anyways at some point)

[gipert]

I think this would be useful to have, but it's also not so urgent...

[ManuelHu]

I am not sure what kind of subtractions are currently used? If it is only G4GenericPolycone with G4Box it should not be difficult.

Yes, at the moment we only have subtractions "genericpolycone - box". A specialized implementation only for this single case would be totally fine.

The main time investment for me is going to have a look into the structure of this python module and understand how all of the objects and information etc. are handled (but i guess i should do this anyways at some point)

just as a pointer: HPGe.solid stores a python instance of the solid, which should be equivalent to the geant4 data structure (attribute names might not be the same).

essentially, the functions is_inside & distance_to_surface would need to be adjusted to account for subtractions...

[ManuelHu]

Another complication is that we need to take a global rotation into account here. THis is - I suppose - a general problem with the current setup, but it is not so important at the moment (i.e. we wouldn't handle "titled" detectors/strings right in the current reboost setup)

but for the asymmetric detectors, the rotation along z axis becomes important.

also see legend-exp/legend-pygeom-tools#6 for a similar feature

[EricMEsch]

Thanks for the pointers.

Another complication is that we need to take a global rotation into account here.

Will this be the users responsibility? As far as i understand, right now the user is responsible to pass the local point and not the global. As i am not sure how this is done in this package, but in General the Geant4 solid or logical volume has no way of knowing its own rotation, as that is given to the physical volume

[ManuelHu]

sure. the two problems are independant. I am already somewhat working on the global location/rotation thing (i.e. I have code, but I don't know if it works at all, I didn't even test it once 😅)

my comment was just meant as a general remark what needs to be done, so that "distance to surface for asymmetric detectors" can actually be used...

[EricMEsch]

Okay, but i actually think your code could be pretty beneficial to this implementation. As the way subtractions are build, is that you specify a translation and rotation for the secondary solid to be subtracted. If i want to calculate the distance to that secondary solid, i will have to transform my local point again with the given translation and rotation.

In the end that should just be inverting the transform, so i am not sure how much effort this would be, but if you already have code for that, that could be beneficial

[EricMEsch]

I have just realized that the DistanceToIn() function for G4SubtractionSolid is pretty inaccurate i think.

if( ( fPtrSolidA->Inside(p) != kOutside) &&   // case 1
      ( fPtrSolidB->Inside(p) != kOutside)    )
  {
    dist = fPtrSolidB->DistanceToOut(p);
  }
  else
  {
    dist = fPtrSolidA->DistanceToIn(p); 
  }
  
  return dist; 

In case 1 this would return a smaller distance when the point is close to a surface of the subtracted box, that is not within the Polycone volume (and would therefore not be a real surface).

In case 2 this would return a smaller distance when the point is close to the subtracted region.

For ReMaGe this should only be a problem in case a daughter volume of the detector happens to be a subtraction solid (As DistanceToIn() is only queried for daughters). But here the distance_to_surface() function is supposed to also work if the point is not inside? Implementing it for not-inside points seems to be pretty troublesome, if the Geant4 implementation is this simplified

[tdixon97]

@EricMEsch seems to be getting a bit complicated. In this case I agree with @gipert its not so urgent and can be left for now. I think we can make a hack in post-processing for V02160A using the distance to surface from geant4