Abstract interface to request physics data about dagmc

[gonuke]

This may be as simple as renaming "mcnp_weight_calculation()" to something like "weight_calculation()" and ensuring that only one implementation is available in any given build.

[kldunn]

I don't think that we can just rename this function. What it does is call the dagmc_mesh_score function with the Fortran code to compute the tally multipliers in MCNP5. This is probably something better suited to meshtal_funcs than inside the individual tally implementations.

[kldunn]

One potential issue with just moving mcnp_weight_calculation to meshtal_funcs is that it is called in TrackLengthMeshTally for every tetrahedron that contributes for any given track segment. The KDEMeshTally implementation only calls it once. We may have to change how this function communicates with MCNP in order to separate it from the individual mesh tally implementations.

[gonuke]

Yes - the dagmc_mesh_score method added to MCNP5 fortran code requires the (sub)track length, but it only uses it in a single multiplication. The only trick is that this method sometimes returns a result independent of the track length. It should be possible to make this work, but we'll need to know whether we are getting a tally multiplier or an alternative score back from the dagmc_mesh_score method.

[kldunn]

Upon further investigation of the MCNP mesh tally code, the dagmc_mesh_score function is only called from within the DAGMC advanced mesh tally code. Other than for the special multiplier case that tallies the number of tracks, this function currently always computes:

score = track_length * particle_weight * tally_multipliers

We could just divide out the track_length part, but what I would prefer to do is to change this function so that it just returns only the tally_multipliers part (this would include the energy and dosef multipliers if requested). Then I would pass both the particle_weight and tally_multipliers to the individual mesh tally implementations for computing the final scores. All of the mesh tally implementations can then be generalized to the following:

final_score = score * particle_weight * tally_multipliers

The only difference between the different mesh tally implementations would be how score is computed. I think that this makes the implementation cleaner and easier to understand outside of MCNP.

[kldunn]

I suppose we could always pass through a track length of d=1 as well since that would not change the results that were reported back by MCNP. I already do this for KDE track length tallies. However, since this function is only used by the DAGMC advanced mesh tally code, it makes more sense to me to just change it so that it works for general mesh tally implementations instead.

[kldunn]

As a first step to see what would happen I simply moved mcnp_weight_calculation to meshtal_funcs.cpp and used a track length of d=1 and a particle weight of wgt=1 to see if I could just get the tally multiplier values. This works fine for KDE mesh tallies and most TrackLengthMeshTally test cases. However, the Meshtally test cases that define a tally multiplier as "fm -4 1" failed. This may have something to do with the fact that TrackLengthMeshTally modifies the MCNP cell ID directly when it tallies a track that crosses over cells if conformal logic is used.

[makeclean]

I would expect fm -1 0 -4 1 and -1 0 -5 -6, or indeed any tally that uses -1 as a the first argument to FMn to fail in the same manner.

[kldunn]

Tally multipliers for advanced mesh tallies were never tested very thoroughly as far as I know, but I do have one test case passing that uses conformal logic and fm -1 0 -1 -4. Of the two tests that do fail, one asserts convex geometry and the other does not. Neither uses conformal logic so their MCNP cell IDs are not changed if I understand what is going on in TrackLengthMeshTally correctly.

[kldunn]

I've spent some more time tracking down this issue today and realized that TrackLengthMeshTally actually can never modify the MCNP cell ID directly as it only provides a pointer to a constant value. This value is stored in a last_cell variable within TrackLengthMeshTally.

The discrepancy between the results seems to be because the original implementation does not work properly when the FM card has two arguments. For these cases the dagmc_mesh_score function only returns the tally multiplier instead of (track_length * particle_weight * tally_multiplier). Thus it is correct in the modified implementation because we only want the tally_multiplier from dagmc_mesh_score anyway. If FM has more than two arguments dagmc_mesh_score does return the complete score, which is why the other cases with tally multipliers worked properly.

[gonuke]

I'm not quite sure why conformal logic would make a difference here (although I'm not looking at the code). When @kldunn suggested that "fm -4 1" failed, I wonder if there is a typo? That doesn't look like a properly formed multiplier to me...

I disagree with @makeclean that any tally that uses -1 as the first argument will fail. For any given track, the local atom density is well-defined. If a tally uses a multiplier with a negative constant, MCNP should have no difficulty finding the atom density and using it for a track length contribution. Whether or not the user can interpret such a result properly is a different story, but I expect the tally to succeed.

[kldunn]

Looks like this is just how MCNP works when FM has two parameters (i.e C k). I thought that "fm -4 1" and "fm 4 1" would multiply the scores by 4*atom_density(cell ID) and 4 respectively, even though the bin sets were empty. But this does not seem to be the case since only the special multiplier cases of k = -1 and k = -2 produce tally results that make sense. The Meshtally test cases that use "fm -4 1" were stu_cyl and stu_cyl2, which I believe were meant to have heating multipliers and these were just entered incorrectly as @gonuke suggested when the tests were created.

What would we prefer DAG-MCNP to do when it gets an FM card with two parameters like this? This won't matter for the advanced mesh tally implementation outside of meshtal_funcs.cpp because it is an issue that is specific to MCNP.

[kldunn]

This physics data interface is mostly complete from the advanced mesh tally point of view. One more thing that we could do to reduce the amount of physics data that is needed is to move the selection of the energy bin to MeshTally, since we are storing the energy bin boundaries there already and we also pass the particle energy as a parameter. Currently, there is a portion of the Fortran code within fmesh_mod.F90 that determines the energy bin of the tally scores. It may be possible to add another function to MeshTally that does this instead, so that we don't have to pass the ebin from MCNP as a parameter when tallying scores. Right now the energy parameter that is passed to the mesh tallies does not do anything. It used to be passed into mcnp_weight_calculation to determine the tally multipliers, but this has now been moved to meshtal_funcs.cpp.

[gonuke]

The work under this ticket has provided some prototypes for future development (#95)