Implemented (Real) Ray Tracing by Stack

[geogunow]

In this PR, I introduce "real" ray tracing by z-stack. A z-stack is a set of 3D tracks that have the same polar angle, same axial spacing, and are separated by a constant axial spacing. This will allow more faithful quantification of axial ray tracing time.

This method determines intersections of all tracks in a z-stack with vertical or horizontal (x-y plane) surfaces analytically. This method is described in detail in "Reducing 3D MOC Storage Requirements with Axial On-the-fly Ray Tracing" submitted to PHYSOR 2016.

The resulting algorithm is significantly faster than the current axial on-the-fly ray tracing algorithm and allows for no additional computational complexity when moving to local axial meshes.

To construct the intersections of all tracks in a z-stack, the structure of the track laydown procedure is utilized. Specifically all tracks in the z-stack have the same polar angle, project onto the same 2D track, and are separated by a constant axial ray spacing. Therefore, from the intersection of the lowest track with the z-axis at the start of the associated 2D track, the axial height of every track in the z-stack can be computed as a function of 2D distance traveled in the radial plane. This leads to the ability to analytically determine the indexes in the z-stack of the first and last tracks to cross a given FSR. An illustration is given below:

In this picture two FSRs are selected. The first and last tracks to cross the FSRs are denoted with green and red arrows. Notice that in FSR A, there are some tracks with the same length, implying they form the same segment information. This can be utilized to speed up axial ray tracing and also allows for the potential of spatial locality when accessing FSRs since adjacent tracks can hit the same FSR.

[geogunow]

@jtramm This PR adds faithful ray tracing to SimpleMOC. This should be reviewed and tested before merging with master.

[jtramm]

Is the integer abs() call intentional here? If you want the floating point one, that would be fabs or fabsf.

[geogunow]

It should be floating point

[jtramm]

• I tried out the PR on the JLSE Haswell node. It compiles well with gcc and intel, but after running for half an hour it hasn't finished or output any status text yet either. How long was the default runtime taking in your testing?
• It appears the problem size has grown a bit from the old default, as it now requires 30 GB (up from 13 GB previously). The memory estimator (in the input summary) no longer seems to be accurate given the increase in 3D tracks, so we should update that function as part of the PR so the memory estimate is accurate.
• We may also want to parse the default problem size down so that it runs in a reasonable timeframe (the old default took a minute or so), and can fit on a BG/Q node (<16 Gb).