Weird artifacts on DAGMC geometry plots

[nlinden]

Hi everyone,

I have been using the DAGMC Cubit plugin to produce some DAGMC geometries that I could load into OpenMC. It seems to work well and I was able to successfully perform some eigenvalue calculations which yield sensible results.

However when trying to plot these geometries to check that the entire process went well, I noticed some weird artifacts on the resulting images. Since I could not trace these artifacts back to any of the DAGMC/Cubit operations I performed, I tried plotting the ready-made DAGMC geometries available in the openmc-notebooks repo. In particular I plotted the teapot running the following script:

import openmc
import math
from matplotlib import pyplot as plt
import urllib.request

teapot_url = 'https://tinyurl.com/y4mcmc3u' # 29 MB
def download(url, filename="dagmc.h5m"):
    """
    Helper function for retrieving dagmc models
    """
    u = urllib.request.urlopen(url)
    
    if u.status != 200:
        raise RuntimeError("Failed to download file.")
    
    # save file as dagmc.h5m
    with open(filename, 'wb') as f:
        f.write(u.read())

download(teapot_url, "teapot.h5m")
dagmc_univ = openmc.DAGMCUniverse(filename="teapot.h5m")
geometry = openmc.Geometry(root=dagmc_univ)

iron = openmc.Material(name="iron")
iron.add_nuclide("Fe54", 0.0564555822608)
iron.add_nuclide("Fe56", 0.919015287728)
iron.add_nuclide("Fe57", 0.0216036861685)
iron.add_nuclide("Fe58", 0.00292544384231)
iron.set_density("g/cm3", 7.874)

water = openmc.Material(name="water")
water.add_nuclide('H1', 2.0, 'ao')
water.add_nuclide('O16', 1.0, 'ao')
water.set_density('g/cc', 1.0)
water.add_s_alpha_beta('c_H_in_H2O')
water.id = 41

materials = openmc.Materials([iron, water])

settings = openmc.Settings()
settings.batches = 10
settings.particles = 5000
settings.run_mode = "fixed source"

space = openmc.stats.Box(*geometry.bounding_box)
my_source = openmc.Source(space=space, domains=[water])
my_source.energy = openmc.stats.Discrete(x=[12.0,], p=[1.0,])

settings.source = my_source

mesh = openmc.RegularMesh()  # could use from_domain here to avid setting lower_left and upper_right
mesh.dimension = (120, 1, 40)
mesh.lower_left = (-20.0, 0.0, -10.0)
mesh.upper_right = (20.0, 1.0, 4.0)

mesh_filter = openmc.MeshFilter(mesh)

pot_filter = openmc.CellFilter([1])
pot_tally = openmc.Tally()
pot_tally.filters = [mesh_filter, pot_filter]
pot_tally.scores = ['flux']

water_filter = openmc.CellFilter([5])
water_tally = openmc.Tally()
water_tally.filters = [mesh_filter, water_filter]
water_tally.scores = ['flux']


tallies = openmc.Tallies([pot_tally, water_tally])

model = openmc.Model(materials=materials, geometry=geometry, settings=settings, tallies=tallies)

p = openmc.Plot()
p.basis = 'xy'
p.origin = (0.0, 0.0, 0.0)
p.width = (50., 50.)
p.pixels = (1000, 971)
p.color_by = 'cell'
p.colors = {iron: 'gray', water: 'blue'}
model.plots = openmc.Plots(plots=[p])
model.export_to_model_xml()
openmc.plot_geometry()

The resulting plot looks like this:

Here we can clearly see the teapot’s body, spout, and handle, as well as the DAGMC graveyard. However we also see that there is some green tea bleeding into the implicit complement filled with void, we can also see some undefined white space.

Has anyone run into these problems before? I am wondering if these artifacts come from the plotting operation, or if there are some underlying issues with the CAD geometry.

Thanks,
Nicolas

[paulromano]

@nlinden I’ve also run into this same issue recently. I don’t have a good idea of what’s going on yet. One thing that is slightly suspicious is that the artifacts lie at a 45 degree angle in the x-y plane. Internally in OpenMC’s plotting routines, it creates a particle at a given (x,y,z) location to determine what cell/material it corresponds to. It’s also necessary to define the particle’s direction, which is arbitrary but nevertheless right now the direction is assigned as (0.707, 0.707, 0), which corresponds to that 45 degree angle. So, that makes me suspect that it may be a plotting artifact but I don’t have a good explanation yet. Will let you know if I find out any more!

Pinging the DAGMC experts in case there are any more thoughts @pshriwise @Shimwell

[Shimwell]

I think this teapot was made with the Cubit + Cubit plugin method which is the most mature method we have, but perhaps Patrick can confirm.

All I can offer is another way to view it

If you have Moab installed then you should have a command line tool called mbconvert also installed

You can convert it to a vtk file and load it up with paraview

mbconvert dagmc.h5m dagmc.vtk

This nice thing about this method is you see the actual mesh triangles that make up the geometry

[gonuke]

We’ve also noticed this in some of our geometries. @camoreno may be able recall what we learned as we investigated

[camoreno]

Yes, I ran into this issue when plotting stellarator geometries. Looking at the VTK in Paraview didn’t show any obvious geometry issues. In our experience, the artifacts always lie at a 45 degree angle in the XY plane but in the XZ plane, show parts of the geometry that should be out of plane (see the included pictures, material overlap shown in red). The orientation of the artifacts makes sense given @paulromano 's explanation of how the plotter works.

We also tested for other geometries and we found the same issue. However, when meshing the geometry via Gmsh, rather than Cubit, these artifacts disappeared, though strange material overlaps were found. Here’s a nice little breakdown of what we observed:

XZ plot of stellarator geometry:

We never ended up figuring out any solutions, though, and just hoped it was an artifact of the plotter.

[camoreno]

Something else worth mentioning is that these geometries were made in OpenMC by reusing the same DAGMC universe. The universe is used four times, copying and rotating it, to make up each of the four quadrants. I think to some degree that explains why the artifacts “stop” at the end of each quadrant, corresponding to the boundary of each universe. When a full geometry is meshed and plotted in OpenMC, the artifacts appear differently:

[akoen]

This issue has also been affecting our stellarator workflows.

The following script reproduces the issue with a simple layered torus meshed using both CAD-to-OpenMC and CAD-to-DAGMC. We’ve also observed the issue with CAD-to-OpenMC’s cadquery backend, so it seems not to be mesh backend specific.

Can also confirm that it seems to be mostly on 45 degree angles to the X-Y plane.

Source: https://file.io/tlmxMXYyl7EB (not allowed to upload attachments as new user).

Script (screenshot expands)

[soha]

Adding these visuals to reflect @akoen 's comment above.

[pshriwise]

Hi all!

Thanks for spurring investigation of these issues, everyone! I’ve seen it a few times myself and the problem has always been nagging at me for a while now.

---

As far as the teapot model goes, @nlinden, I happen to know that the water surface starts at z=0, sot he plot is slicing right on one of the planar triangle surfaces of the model. This causes problems for CSG geometry as well – the sample points for the image can’t quite decide what side of the surface to be on numerically. Changing the z value of the plot origin even slightly, say to -0.0001, fixes this problem. That said, the direction we use for plotting is zero in the z direction, which isn’t ideal as it increases the likelihood of problems with intersections on z-axis aligned planes, something pretty common in our geometries. That’s something we can easily update.

---

As far as issues where plot slices don’t line up with geometry planes, I did some digging and, while there may be more than one cause for these artifacts, here’s one (long-winded) explanation in the presence of unmerged coincident surfaces in the DAGMC model. The fix I implemented did seem to fix the problem in that case.

An explanation of DAGMC plot artifacts

Before

After

I’d be curious if the fix I’ve implemented would help with some of the cases in this thread. Is anyone willing/able to send some of their models my way or try out the branch I’ve linked in the issue above?

Cheers,

Patrick

Branch link here for reference: GitHub - pshriwise/openmc at dagmc-find-cell-updates