Add additional geometry specifications for hole-cutting.

[rlfontenot]

In this issue I plan to add the following geometries for overset-hole cutting geometric definitions:

box (as opposed to plain lists)
conic
hollow cylinder
sectors (angular sections of cylinders, conics, hollow cylinders)

as well as unions/intersections of these and currently existing geometries. Since the componentGeometryData apply rule has a "pass-fail" paradigm as it currently stands, I will either modify that rule with the new geometries or add subsequent apply rules. Probably the former.

[rlfontenot]

Add to this list: polySector, defined by a planar polygon description with plus/minus degree sector or thickness, with only one direction extrusion if desired.

[EdwardALuke]

I believe we both use the inside/outside and the signed distance function in the overset code. Note that the geometry is something that we have several similar constructions for, it might be useful to combine all of these features into a standard library provided by Loci. For example, initialConditionRegions code uses a similar geometry (and this isn't the only usage). I did something similar in the Immersed Boundary code where one of the options is to have a coarse triangulated mesh and also to be able to use union and intersection operators with geometric terms allowing one to compose a geometry using multiple fundamental elements. Probably all of these structures should be unified into a single common geometry facility.

[rlfontenot]

Yes, there's the distToSurface (which is defined in each class but doesn't seem to be used when I grepped it), and the inGeometry code in FVMOverset (geometry.loci). Similar infrastructure is definitely used in the ic code. I would be all for unifying these into a single common geometry file/header for accessible from the FVM module (that makes the most sense to me) that is accessible wherever is needed. Let me take a stab at that here first with the overset, and then we can extend that to the other features (ic etc.).

[EdwardALuke]

If you have a distance2Surface that you can trust, then you can implement geometry union and intersection code which allows you to build geometries as a composite of more fundamental geometries. I have done something like this in the immersed boundary module. I think if we were to refactor this code we should try to incorporate the functionality of the initialConditionRegions, Immersed Boundary, and hole cutting. They have so much overlap that it is a waste that we don't have a single unified structure for these. As I mentioned, the immersed boundary code even can define geometry using a triangulated surface mesh, so it is very powerful, but really about the same complexity as what we have for hole cutting.