Support optical surface interfaces

[sethrj]

The LZ and ePIC forward detectors both specify volume types not seen in the main LHC: "bordersurface" in the former, and "skinsurface" for the latter. Both are related to surface-processes for #886 . These two special GDML structure entries seem only to declare interfaces rather than "wrap" a volume: the logical volume it creates is not referenced by other parts of the geometry.

LZ, for example, has the following:

  <solids>
    <opticalsurface finish="4" model="1" name="liquidXeTeflonSurfacePMT" type="1" value="1"/>
  </solids>
  <structure>
    <bordersurface name="lXePMTSurface_1" surfaceproperty="liquidXeTeflonSurfacePMT">
      <physvolref ref="Bottom_PMT_Body_3000x76afca0"/>
      <physvolref ref="LiquidSkinXenonBank0x76058b0"/>
    </bordersurface>
  </structure>

From the geant4 application guide:

There are three methods of specifying an optical surface.

1. For the simple case of a perfectly smooth interface between two dielectric materials, all the user needs to provide are the refractive indices (RINDEX) of the two materials stored in their respective G4MaterialPropertiesTables.
2. A skin surface is the surface entirely surrounding a logical volume. This is useful where a volume is coated with a reflector and placed into many different mother volumes. A limitation is that the skin surface can only have one and the same optical property for all of the enclosed volume’s sides. An optical surface is created and defined using G4OpticalSurface. This surface is assigned to a logical volume using the class G4LogicalSkinSurface.
3. A border surface is defined by specifying the ordered pair of physical volumes touching at the surface. Because the pair of physical volumes is ordered, the user may specify different optical properties for photons arriving from the reverse side of the same interface. For the optical boundary process to use a border surface, the two volumes must have been positioned with G4PVPlacement. The ordered combination can exist at many places in the simulation. An optical surface is created and defined using G4OpticalSurface. This surface is assigned to the ordered pair of physical volumes using the class G4LogicalBorderSurface.

We can think of these surface definitions as pairs of {incident, exiting} volume IDs—I think. Our volume IDs are based on the "logical" (unplaced) volume properties, but since the "border surface" can refer to specific "physical" (placed) volumes, we could need to expose extra data through the geometry. We should be able to gather these surface boundary mappings during construction through our conversion routine. In both geometry cases, I think the "which surface" evaluation has to be done during the surface crossing: we need to query the next volume without committing to it.

From G4OpBoundaryProcess::PostStepDoIt and G4MicroElecSurface::PostStepDoIt, where the skin surface is used, it looks like there's also a precedence if both parent and child have a skin: the child's skin overrides the parent.

[sethrj]

@whokion @pcanal Do you know much about how internal reflection for optical photons (or other particles for that matter; I think neutrons can do it too under the right circumstances) works relative to the navigator, transportation process, "optical boundary process", etc.? From what I can tell, the track has to actually exit the old volume and enter the new one, then get its direction changed and return back to the original. Ideally we'd not have to leave the volume at all, since crossing in and out is expensive. But since the "border surface" condition takes precedence over the "skin surface" it seems like we wouldn't be able to determine the true reflection process until we cross the volume...

As an optimization we might be able to be certain of some surfaces before crossing. And for ORANGE we might be able to certain of even more...

[whokion]

As the optical boundary process is called after transportation, it seems that the redundant crossing is unavoidable if the navigator is push the particle to the other side of the boundary rather than on the boundary (or within a geometry tolerance) when the step is limited by the geometry and light is reflected. As the idea of border/skin surface is to handle different properties between optical surfaces which is decoupled from the navigation itself, it would be great If ORANGE can handle this ordering issue in the better way. Nevertheless, it may be subtle to combine these different pieces without a special treatment as the direction is normally handled by the physics process while the position is by transportation.