Adding tetmesh scoring to FluDAG

[makeclean]

When the time comes for us to implement tetmesh scoring in FluDAG, (after @kldunn has completed the refactor I guess) using https://www.fluka.org/free_download/course/portugal2010/Lectures/AdvancedUserRoutines2010.pdf as a guide to the Fluka internal variables and routines.

It appears that mgdraw.f gives us access to most of the Fluka variables at every particle substep. If I recall, the current implementation of advanced scoring works by waiting until the end of a history and allocating the track length backwards along the ray direction.

If we can wait until the end of the history then we can use usreou.f, which is called after the history is complete. By including the common block '(TRACKR)' we have access to all the data in the common block. If we need to do this after each history substep then using mgdraw.f would ideal.

[makeclean]

Yeah, I forgot to add the labels and must've clicked 'back' then submitted a new issue.

[kldunn]

The current tetmesh tally in DAGMC has one method for computing the score for a single track segment and then another method at the end of history. However, the end_history method just adds the temporary tally data to the total tally data and error arrays. You could probably implement it in Fluka at every track segment or wait until the end of history if you have a record of all the track data for that history, as the MeshTally implementation doesn't care when you call the compute_score method as long as it is done before you call the end_history method. However, I would think that using mgdraw.f would be the easiest option to implement.

As for the refactoring status, I am planning on changing the interface to MeshTally in the near future to make it easier to hook up into other physics codes. Once this interface is finished you will be able to start implementing the tetmesh scoring for Fluka, as the rest of the code will be encapsulated.

[gonuke]

Using the mgdraw interface would probably be easier as it would have the same MeshTally control flow; we'd need to also use usreou to invoke the end_history method.

That said, it sounds like accessing the TRACKR common block would be like parsing an event log, so we may have other efforts looking into this.