Possibility to reduce # of faces generated for curved boundaries?

[rcarson3]

So, I was just working on a simple cylinder tessellation and mesh to run in my application code, and I noticed that there were a large number of faces generated for the cylinder.

For example the below set of commands generates 14 faces total (2 for the z faces and 12 for the surface of the cylinder)

./neper -T -n 1 -domain "cylinder(3,1)" -o n1_cyl

and

neper -M n1_cyl.tess -o n1_cyl -format 'msh' -faset 'faces' -order 1

I was wondering if there are any plans to consolidate the surfaces corresponding to a given curve surface or even just being able to output what faces correspond to a curved surface?

Additionally, I was also curious to see if in the future if higher order elements are used if it might be possible in the future to actually preserve the curved surface by moving mid nodes out onto the curve rather than just making things linear?

I understand that these are probably non-trivial to implement, so it's okay if there are no plans for this. I just know that at least the 1st one would help simplify my workflow as I start looking at running simulations of polycrystals for non-cube like domains.

[rquey]

As Neper was initially designed to work only with flat faces (Voronoi-type tessellations in a cubic domain), it does not well support curved faces. A 1-cell cylinder contains a face that has 2 closed edges and no vertices, and this is not something that the current TESS structure can take.

Are you comments related to the tessellation (.tess file) or to the mesh? Even if the cylinder is faceted in the tessellation, the mesh could certainly be smoothed (projected) to actually describe a cylinder. Same for moving the 2nd-order nodes to the surface of the cylinder, this should not be difficult to do...

You can determine what faces belong to the curved part of a tess using -statface domtype,domface. (The z0 and z1 domain faces are numbered 1 and 2; so all faces whose domain face (domface) is > 2 belong to the curved part of the tess.)

[rcarson3]

@rquey so my interests were more on the mesh side of things and more specifically the gmsh file being outputted. I definitely remember the good old days back when Neper only supported tessellations for basic voronoi or equiaxed type tessellations on cubic domains. So, I understand the limitations that exist there, and I can't say my current research even requires curved grain boundaries. Although, I would definitely try it out if you ever did add that feature.

Back on to the mesh side of things, so I agree for the cylinder it wouldn't be too bad to project nodes back on to the cylinder surface for higher order elements. However, my thoughts were a bit more down the road when I would be looking at something a bit more complicated like the two figures on the right here: https://neper.info/generation.html#new-non-convex-domains . So, I guess that's where I was wondering how I would easily be able to map all the faces outputted by -faset 'faces' back to the their respected curved face. Does the -statface domtype,domface provide this sort of information?

[rquey]

Yep, the good old days...

-statface domface works even better for domain faces created by -transform cut as in the examples you mentioned. You can see it like this:

$ neper -V n1000-id1.tess -showcell 0 -showface 1 -showedge 1 -datafacecol int:domface -print img

I think it would be trivial to position the 2nd-order nodes on the curved surface in this case (even simpler than when the domain is pseudo-curved...). Actually, would there be any drawbacks to making this the default behavior?

[rcarson3]

I can't think of any downsides to having the default behavior be to position 2nd-order nodes on the curved surface by default. Although, I guess one potential issue is you might end up with some elements being poorer quality after nodes have been moved. So, one might have to do some form of mesh optimization after the fact.

Also, I was just browsing through the transform as I didn't realize all the various features that are in there. It definitely seems like a powerful feature that's almost CAD like.