Impact of Lowering Order Question

[wrkendrick]

Hi all. I'm currently running a mesh in MOOSE with thermal expansion, then taking that deformed mesh and running it as my geometry in OpenMC via DAG-OpenMC. In order to capture some conservation effects better on MOOSE's side, the mesh is HEX27. When I go to OpenMC I would like to convert the deformed mesh to HEX8 before exporting my dagmc.h5 facet file, as it speeds up particle transport significantly.

When I downgrade the element order I get warnings that "Edges or nodes are not equivalent after node order correction". This makes sense to me, as there's probably some coarsening that comes from lowering the order. When I compare eigenvalue differences between the low-order and high-order OpenMC runs there's no statistically significant difference, so I'm assuming that this coarsening is small enough that I don't need to worry about it, and can keep lowering my element order for speed, but wanted to get y'all's opinion first.

TLDR:
Just via y'all's intuition, is the difference in facet geometry exported from a HEX27 geometry vs. a downgraded-to-HEX8 geometry significant, or is it OK to keep sticking with what allows my transport to solve the quickest?

Thanks so much,
Reed

[makeclean]

Hi @wrkendrick I have so many questions, but lets start with this - https://github.com/aurora-multiphysics/aurora - there exists a MOOSE app for doing this called Aurora - which allows you to take a MOOSE problem and transfer it to DAG-OpenMC via the MOOSE API - that might be of general interest to you as it allows you to look at the transient behaviour all controlled via the MOOSE time stepping.

Via what mechanism did you put in geometry? I'm quite confused how you put a hex8 based mesh into DAGMC and not have it complain? Let alone a hex27 geometry! So you must have some infrastructure in the way?

Either way the route for DAGMC would look something like, skin the mesh, get the exterior quads and pass those into dagmc who will then turn those to triangles. A second order quad wcould like have to be turned into 4 linear quads which approximate the higher order surface. A bit of interesting work would be to fit a quadratic surface to that element then we facet that.

[wrkendrick]

Yep! Know about Aurora, I'm doing a couple of extra things with my runs that require me to be a bit more hands-on with the MOOSE --> DAG-OpenMC process, so I do it myself for now.

Sorry, I forgot to mention, I'm using Coreform Cubit w/ the DAGMC plugin for generating my facets from the mesh. So in Cubit I lower the element order then export the facet.

Seeing your other reply, it seems like my general feeling was correct; As long the mesh resolution itself isn't too low and the deformations aren't so extreme that they need the extra quads, then a slight coarsening shouldn't hugely impact the exported facet geometry.

[makeclean]

No it shouldn't, but are you saying you're seeing a vastly different transport time between the two geometries? The same geometry faceted to double or 4 times the resolution should have a very small impact on runtime;

This graph shows the average ray fire time as a function of geometry resolution. so you're seeing a significant and measurable difference in runtimes between the two from OpenMC?

[makeclean]

To answer your final question, your mesh resolved to hex8 rather than hex27 is more of an approximation, now so really the answer is does your mesh represent well you system? If its a low resolution mesh it would likely not confirm to the geometry well and a hex20 or hex27 would likely match your geometry better with the extra nodes. IIRC for keff problems with DAGMC you would have to crack up the resolution of your mesh to get good agreement with benchmark answers.