Compare KDE and TrackLength mesh tallies

[kldunn]

Check current implementations of KDE and TrackLength mesh tallies for redundancy and common functionality that can be moved to MeshTally.

[kldunn]

One example of redundancy is the print and write_results methods, since there appears to be no need to have both methods in both KDE and TrackLength mesh tally classes.

[kldunn]

I have added a few common functions and variables to the MeshTally base class that were involved in the setup process for both KDEMeshTally and TrackLengthMeshTally classes:

• _tally_meshset: stores the entity handle for the MOAB mesh data used by the mesh tally (needed for writing results to file)
• _outputfilename: determines the name of the file to which results will be written (also set default name in constructor if one not included in MeshTallyInput options)
• _inputfilename: added as a new variable to the MeshTallyInput struct, which is now set in _meshtalfuncs.cpp
• _load_moabmesh(): creates a mesh set and loads the MOAB mesh data from the input file associated with the mesh tally
• _set_tallypoints(): assigns a moab::Range of mesh elements to the set of tally points, resizes the data arrays to store the tally results for these points, and checks psize of the moab::Range
• _reduce_meshset_to3D(): reduces a mesh set to include only its 3D elements and returns those elements in case they are needed elsewhere in the setup process

[kldunn]

I have combined write_results() and print() methods in the KDEMeshTally and MeshTally implementation as a part of cleaning up the code formatting and adding detailed comments stage. There are still two print methods in TrackLengthMeshTally that can probably be simplified/extended to the MeshTally Base class.

[kldunn]

As part of the cleanup stage of KDEMeshTally, I generalized the end_history() and add_score_to_tally() methods. Both of these can probably be moved up to MeshTally as TrackLengthMeshTally also needs to perform these tasks and I do not think that there is a major difference in their implementations.

[gonuke]

See https://mywebspace.wisc.edu/groups/CNERG/Neutronics/WeeklyMeetings/2013.06.03/MeshTallyRefactorUpdate_kldunn06032013.pdf for some discussion

[gonuke]

This has been replaced by #92