search

mit-crpg / OpenMOC

A method of characteristics code for nuclear reactor physics calculations.
https://mit-crpg.github.io/OpenMOC/
Other
146 stars 82 forks source link

Versioning for Track Files #308

Open wbinventor opened 8 years ago

wbinventor commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/mit-crpg/OpenMOC/issues/308#issuecomment-215878290

GiudGiud commented 7 years ago

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 ?)