Ray tracing caching doesn't work for altered material properties

[wbinventor]

The TrackGenerator exports a binary file "cache" of all ray tracing data after each call to TrackGenerator::generateTracks(). This is useful when modeling the same geometric model many different times since OpenMOC will simply import tracks from the binary track file(s), eliminating the time needed to redundantly perform ray tracing over and over again.

The first element of the binary track file is a metadata string to identify the makeup of the Geometry. In particular, the Geometry::toString() method is used to create a string representation of all elements in the Geometry (materials, surfaces, cells, universes, lattices) and this string is stored to the file.

When TrackGenerator::generateTracks() is called, it first checks to see if there is a binary track file with all of the data from a prior run. If the metadata string in the file matches exactly that string for the current Geometry in use, then the TrackGenerator knows that it can safely use the tracks stored in the file without having to redundantly perform ray tracing again. This is particularly relevant when modeling the same Geometry but with different discretizations of rings/sectors/etc. The metadata identifies the difference and as a result, the TrackGenerator will manually perform ray tracing across the newly discretized Geometry.

The issue is that the Geometry::toString() method embeds Material properties (e.g., cross-sections) into the character sequences used to represent each Material. As a result, if the geometric model remains exactly the same, but user changes the cross-sections from run-to-run, then the TrackGenerator will perform ray tracing anew each time since the metadata strings will not match up. This is an issue since the Material cross-section values themselves do not impact the ray tracing itself. That said, the Materials should in some way be embedded into the metadata string since if a wider variety of Materials - or Materials with different IDs - are used in a model, then this will affect the Materials assigned to each FSR and hence each Track segment.

This issue came up for the Design-A-Reactor demo for OpenMOC, which uses the same geometry but with adjustable material properties. The quick fix is to simply comment out lines 1147-1148 which check the metadata string, but this is not a solution in any way.

[nathangibson14]

OpenMOC ray tracing /is/ a function of materials data right now, as tracks are segmented so that the optical length is within the limits of the exponential table. If we remove the materials from the check, the materials data could be changed to have very large cross sections that would break the exponential table.

[wbinventor]

Ok, so we should write out the maximum optical length to the tracks file rather than the cross-section data. This would go together well in a PR which adds some "hooks" to set the max optical length for the exponential table, etc.

[wbinventor]

This issue is resolved with PR #141.