Versioning for Track Files

[wbinventor]

I recently ran into a scenario where I was trying to run the most up-to-date version of the "develop" branch on a model with some old track files. This unfortunately led to some segmentation faults because those old track files were incompatible with OpenMOC since #296. This issue was easily circumvented by deleting the "track" directory and forcing OpenMOC to generate a clean slate of tracks.

As a result of this experience, I propose that we add a header to our track files with a "version number." This is inspired by the statepoint and summary version numbers used in OpenMC. Each time we change anything about the layout of track data in a track file, the version number must be incremented. Then when the code attempts to import a track file, it will first compare the version number to its own and if they do not match, a clean slate of tracks will be generated. A solution such as this one seems all the more important as sophisticated ray tracing and track generation methods are migrated from ClosedMOC into here.

What do you think @geogunow @samuelshaner?

[samuelshaner]

I agree completely! I've run into this issue when tweaking the 3D tracking as well. How would the version number be exposed to the TrackGenerator?

[wbinventor]

The version number could simply be the first number in a track file. If it doesn't match, the track file import would fail and revert to explicit ray tracing (just as it does if the geometric ketatdata does not match).

[geogunow]

I really like this idea. Let's get an implementation and then debate about
it.

On Fri, Apr 29, 2016 at 4:50 PM Will Boyd notifications@github.com wrote:

The version number could simply be the first number in a track file. If it
doesn't match, the track file import would fail and revert to explicit ray
tracing (just as it does if the geometric ketatdata does not match).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#308 (comment)

[GiudGiud]

Would like to look at it, since I m doing easy PR / issues to train with the process.
However I couldn't find a command like openmoc.version, there are a few such commands but they don't seem to give the openmoc version (like currently v0.2.0 ?)