ExactGeometry System

[friedmud]

Yep: Already time for a new System! (THIS will be the last one! I swear! :-)

Here's what's up: we need a way to feed real, analytical geometry into MOOSE so that when we adapt the mesh the new nodes will automatically get moved to the surfaces of the exact geometry. Think of a coarsely meshed circle (think hexagon), if you refine it... you just get a finer hexagon... when in reality those new nodes should have "popped" to the circle to better fill out the circle.

This system should be modular so that we can plug in lots of different types of geometric descriptions. Here's what I'm thinking:

ExactGeometry base class. It will have a pure virtual function like so: moveNode(boundary_id_type boundary_id, Node & node). Obviously, derived classes will override this function and when it is called they will figure out the correct placement of that node and move it to the correct position. The calling of this function will happen right after the mesh is adapted.

As suggested by the above function definition, ExactGeometry objects will be associated with boundary IDs (similar to a BC). So you can apply different ExactGeometry objects to different boundaries (if you want).

Here is some suggested syntax for a few ExactGeometry objects I'm going to implement to get this started:

[ExactGeometry]
  [./circles]
    type = MultiCircleExactGeometry
    boundary = '1 2' # One boundary per circle or just one boundary that will be on all circles
    centers = '1.2 4.3 7.3 8.4 8.3 8.0' # std::vector<Point>
    radii = '1.4 1.2' # std::vector<double>
    plane = xy # MooseEnum: xy, xz, yz
  [../]

  [./spheres]
    type = MultiSphereExactGeometry
    boundary = 'top right' # One boundary per sphere or just one boundary that will be on all spheres
    centers = '1.2 4.3 7.3 8.4 8.3 8.0' # std::vector<Point>
    radii = '1.4 1.2' # std::vector<double>
  [../]

  [./lattice]
    type = CircleLatticeExactGeometry
    boundary = '4' # Should only really be set to one boundary
    radius = '1.7' # double
    nx = 4 # unsigned int
    ny = 7 # unsigned int
    dx = 1.2 # Lattice spacing in x: double
    dy = 1.4 # Lattice spacing in y: double
    first_position = '1.2 1.4 1.8' # Point
  [../]
[]

Later on, of course, we can plug in some Constructive Solid Geometry (CSG) engines in. In particular, I want to find one that allows us to easily save CSG from Cubit and use it as ExactGeometry in MOOSE. For now though, I just need something simpler (the above will work fine).

[YaqiWang]

How about you have thousands of fuel pins in your mesh? Each will have its own circle. We cannot create thousands of side sets. The better way could be create simple geometry objects (typically d-1 dimension) but do not connect them to side sets. We can then attach each node with a geometry object. Just my thoughts.

[friedmud]

Nope: take another look at the syntax for CircleLatticeExactGeometry... it works by giving it one boundary_id that will be on the outside of all of your fuel rods. So only one boundary_id is required.

[friedmud]

Also: MultiCircleExactGeometry can work in that mode too (provide one boundary ID and multiple circles). It will first find which circle is closest to the current node and then move it accordingly.

[friedmud]

I updated the comments in the above syntax to reflect that capability

[YaqiWang]

Yeah, I am thinking a general Monte Carlo model, in which there could be lots of curved faces not in a regular lattice. Number of side sets could be a killer. I still think the long term solution should be create geometry objects and attach all mesh objects (nodes, especially sides, elements) to them. But if the solution is simple, refactoring it would not cost much, and it is urgently needed, go for it.

[dschwen]

Awesome! At the phase field workshop at Northwestern we had a hackathon problem for solving pf equations on the surface of a sphere. This will put moose further ahead of the competition by allowing for correct refinement on these geometries.

[friedmud]

@YaqiWang I'm doing this for neutronics as well... trust me... this is going to work well :-)

@dschwen Exactly. I really think this is going to be a feature a lot of people use over time.

[dschwen]

What about conservation of volume or surface area? If nodes just snap to the exact geometry the volume of element near surfaces would be changed. We will run into similar issues as we see in phase field with coarsening already where mass is not conserved if elements are coarsened over which the field variables have a non-zero curvature. That confused participants at the phase field hackathon quite a bit.

[friedmud]

@dschwen it's definitely something to look into. I was thinking about it quite a bit earlier today... and we may need to enable a "conservative projection" capability... but we're just going to have to wait and see.

I don't currently think it's going to make a big enough change to be noticeable... I mean, the current refinement / coarsening is technically non-conservative and we've been using it with phase field just fine for years (it's also used in a lot of tricky CFD calculations at NASA).

But yeah: it's definitely something to study.

[YaqiWang]

That will be difficult for general curved geometries. For evenly distributed points on circles, we can have an formulation to move the nodes a little to preserve the volume. If you use second order mesh, volume will be significantly better than the first order mesh.

[friedmud]

@YaqiWang even if you try to conserve total volume it won't conserve local element volume if you're moving nodes - and it's the local element conservation that can get you (if you add/remove a little bit of mass to an element in a CFD calculation it can cause shockwaves to appear!). The only way to conserve mass when moving nodes is to do a conservative remap like in an ALE method (for instance: http://epubs.siam.org/doi/abs/10.1137/0908037 ).

We're just going to have to "wait and see" on this whole thing. It's probably going to be fairly physics dependent. I suspect that for most of our fairly diffusive physics they won't even notice if you jiggle a node just slightly. Like I say... we've been gaining/losing mass every time we coarsen the mesh during adaptivity for years... without any ill-effects.

[adamLange]

Hey, I'm getting pretty good with the opencascade cad library. Let me know if I can be of help with that on any exact geometry things.

[friedmud]

Absolutely! I don't think the design is to the point I want it yet before I want people to try to help. I won't be doing much on it this month... but going into this summer this will be a big project for me and I'll definitely ping you for help.

OpenCascade does look like a good choice for a CAD backend. On Mon, Apr 4, 2016 at 11:44 PM Adam Lange notifications@github.com wrote:

Hey, I'm getting pretty good with the opencascade cad library. Let me know if I can be of help with that on any exact geometry things.

— You are receiving this because you were assigned. Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5932#issuecomment-205628758

[adamLange]

Looking forward!

[lw4992]

OCC is famous open CAD library. Gook luck for you.