Disagreement betweem OpenMC and DAGMC results

[AnthonyB08]

Hi all,

I am verifying my DAGMC implementation by replicating the same geometry, and somewhat the same mesh, using the traditional OpenMC method (XML file). I am post-processing both simulated results using Moose, i.e the Cardinal Wrapper, and below are the results.

For context, I am simulating a plutonium ball (ra=3.44cm) surrounded beryllium shield (rb=10cm) . I am only showing the first domain.

My question is if this is a typical disagreement between DAGMC and OpenMc Xml usage or if my simulations may have an issue. I am not worried about the right-side OpenMC point because it is very close to the edge of the domain.

-Thanks,
Anthony

[pshriwise]

Hi @AnthonyB08,

Thanks for running this comparison! I'm curious to know more about the models. My understanding is that you've generated a DAGMC geometry that is equivalent to the OpenMC geometry (aside from the tesselation tolerance used in the DAGMC model). Are you using a mesh to tally results?

[makeclean]

Also statistics? The multiplicity assuming that related to keff, would make sense to me, you've likely gone for a faceting tolerance of around 1e-4 by the looks of it, so we would expect differences in the 4th sf.

[AnthonyB08]

I am working to open the state point file to look at the raw data. I am having issues with the cardinal, openmc, and dagmc (dagmc now). I backed up my work in this repository https://github.com/AnthonyB08/DAGMC_MOOSE . I will update this discussion as soon as Cardinal is back up and working! Thanks for the response .

@pshriwise I am using as mesh tally , correct.

tally_type = mesh
tally_name = 'flux '

The post-processor is a vector
[flux_vec]
type = LineValueSampler
start_point = '0 0 0'
end_point = '0 0 3.4'
num_points = 256
sort_by = id
variable = flux
execute_on = 'timestep_end final'
[]

[pshriwise]

Hi @AnthonyB08. Just wanted to check in on this. Any updates?