[MOAB-dev] Digging into ray_intersect_* in the OBBTreeTool - proposing an interface change

[Vijay S. Mahadevan]

Paul, IMO, if there is DagMC specific logic embedded in general ray
intersection code, and if no one has complained about it so far, my
guess is there aren't many users relying on that API. In which case,
I'm all for simplifying it.

> These methods would no longer return lists of intersections, but would return them one at a time for consideration by the calling application.

However, it is very unclear to me how a calling application would know
whether to stop querying again or if it should be satisfied once the
first successful entity is found. If there is a stronger reasoning for
this behavioral change, that would help motivate the change better.
But as I said above, if DagMC is the sole consumer of this API, do
modify it so that it is part of the next version.

Vijay

On Tue, Dec 13, 2016 at 9:17 AM, Patrick Shriwise <shriwise at wisc.edu> wrote:
> Hi all,
>
> Having seen how many other ray tracing codes operate I think that these are
> valuable changes to the OrientedBoxTreeTool which will allow it to be
> extended to many other applications.
>
> Pulling out these DAGMC-specific intersection disambiguation operations into
> separate functions for filtering intersections will also allow them to be
> applied in other ray tracing kernels (AdaptiveKDTree, etc.) if desired.
>
> -Patrick
>
> Patrick C. Shriwise
> Research Fellow
> University of Wisconsin - Madison
> Engineering Research Building - Rm. 428
> 1500 Engineering Drive
> Madison, WI 53706
> (608) 446-8173
>
> On 12/09/2016 04:44 PM, Paul Wilson wrote:
>
> Hello all,
>
> I have been spending a lot of quality time with the ray_intersect_* methods
> of the OrientedBoxTreeTool over the last few weeks.  I think I have
> (re)learned all the subtleties of the additional code that exists in
> RayIntersectSets::leaf() (invoked with API function ray_intersect_sets).
>
> In general, these are all additional tests that make sense only in the
> context of a call from DagMC:
>
> is this facet in a list of previous facets intersected by this ray prior to
> this call
> is this facet in a list of previous facets (or their neighborhood)
> encountered during this call
> is this intersection a piercing or glancing intersection as defined by
> notions of surface sense known to DagMC
>
> There is then a complex logic related to how many intersections to keep
> based on three quantities: two are a "window" in which the distance to
> distance to intersection must fall and the third is a count of how many
> intersections to keep.
>
> The logic for ray_intersect_triangles() includes none of this.  I was
> contemplating an interface change to ray_intersect_triangles() that would
> add enough information to include the same tests, and modularizing those
> tests to reuse code in both places.  However, (a) the interface for that
> would be awkward and (b) it would be imposing DagMC conventions on even more
> code.
>
> Instead I propose the reduce the interface of all ray_intersect_* methods to
> include only the following:
>
> const EntityHandle root_set: points to the root of the OBB Tree
> const double tolerance: for use in searching for intersections (largely
> unused at the moment, I think)
> const double ray_point[3]: starting point of ray
> const double unit_vector[3]: direction of ray
> std::pair<double*, double*> window: window to narrow search for interesting
> intersections
> std::pair<double*, double*> register_intersection(...): call back function
> to perform application specific filtering/disambiguation of possible
> intersection, returning an updated window
>
> These methods would no longer return lists of intersections, but would
> return them one at a time for consideration by the calling application.
>
> Since this is such a major interface change, I thought I'd solicit feedback
> before embarking upon it.  It won't necessarily bee that much code change,
> but who knows how it impacts other possible users of this code???
>
> Paul
>
>
> --
> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
>
> Paul P.H. Wilson
> Grainger Professor of Nuclear Engineering
> 608-263-0807
> paul.wilson at wisc.edu
> 419 Engineering Research Bldg
> 1500 Engineering Dr, Madison, WI 53706
> calendar: http://go.wisc.edu/pphw-cal
>
> Computational Nuclear Engineering Research Group
> cnerg.engr.wisc.edu
>
> Faculty Director, Advanced Computing Initiative
> aci.wisc.edu
>
>