[nkalkote]

Hi All,


In many papers, I came across cut-cell methods for the same I would be great-full to know your opinion from your experience about cut-cell methods.

1) As most of the cells are orthogonal it supposes to be more accurate.

2) What are the mesh formats (preferably open) that can be used? (I'm using CGNS for current IO).

3) What will be the form of data structure, face based data structure which is commonly used in unstructured grid methods is it possible to use? Or do we have to use Octree? (Any base paper/article will be helpfull)

4) What are major pros and cons of the method?

[mprinkey]

I can answer some of these

(1) Accuracy is good as long as wall bounding effects (drag from boundary layers, heat transfer to walls, etc) are not very critical. Cut-cell methods are generally a mess when coupled with boundary layer creation for arbitrary surfaces. SnappyHexMesh in OpenFoam does a pretty good job, but honestly, it still leaves a lot to be desired for many CFD applications.

(2) I can't speak to this, but my understanding is that you need to dump data to unstructured data of some type because I don't know that any visualizations packages directly support cut-cell specifically. Also that many viz packages only support four 3d element types (tets, hexs, pyramids, and wedges) and cut cells can be more complicated then those four. (seven-sided elements are common)

(3) Cut-cell does NOT have to use oct-tree but some unstructured data storage is likely necessary. I know that some codes started as cartesian with (i,j,k) 3d array storage, but you will end up with lots of wasted storage due to inactive cells. Oct-tree makes a lot of sense from an adaptive/refinement standpoint and it gives a nice structure to avoid wasting memory storage and the loop/memory stride inefficiencies that come with it. But, you could just use an lexigraphical or sorted 1d array with neighbor arrays like you do for general unstructured codes.

(4) Pros are that it "eliminates" grid generation problems by making it automatic, it nominally reduces code complexity...or at least...reduces the need to embrace a fully unstructured code approach (I'm not convinced that it is really simpler in the end). Also it can let you glue make legacy codes handle more complicated geometries (see cut-cell options in MFIX, for example). Finally, it tends to keep most of the domain with logical coordinate axes and can support "structured" interpolation schemes like WENO and QUICK that require East-of-East and West-of-West neighbor data, something that is lost in unstructured grid codes and devilishly complicated and expensive to add back in via, say, multidimensional interpolation, etc.

Cons are that grid generation is limited and can be a poor fit for some CFD applications, although oct-tree refinement can help. But, then you get 3D grid refinement when you really only want 1D wall-normal refinement. To be space- and compute-efficient, you need to use 1D unstructured style storage with neighbor lists as you would with a fully unstructured code, so converting an 3D array code to cut-cell is more like a full rewrite to 1D storage or a bit of a "hack" into the 3D code with lists of inactive cells taking up memory and ruining cache accesses.

[nkalkote]

Thanks a lot and I appreciate your efforts in detailed explanation for all the queries.

Here are my take away, please correct me if I'm wrong.

1) Cut-cell methods works for most of the flows involving boundary effects unless there something unusual is happening. Boundary layer creation is one of the problem to focus on. SnappyHexMesh is one of great tool can come handy.

2) Data structures for cut-cells can be octree(cell based) but it will be more advantageous if it is somehow wrapped up in unstructured grid (face based) type of data base so that direct available commercial/open post processors can used directly.


3) Pros involves the features of unstructured/structured grid methods can handle complex geometry and also allows direct implementation of structured grid schemes. Automatic mesh generation comes handy.

4) Majors cons are grid refinement is sort of must and may not be as efficient.


Again thanks a lot for pointing out lot of insights.

[BlnPhoenix]

As an engineer i generally very much like the Cut Cell Method whether it is in Ansys Fluent or in Snappyhexmesh. The mesher in Ansys is as easy to use as it can get. What i don't understand though is, why Ansys is not trying to optimize this tool further. This issue with Boundary Layers and Orthogonal Quality for example, Openfoam has iterations that can optimize overall mesh quality. Also the mesh quality indication in Ansys Meshing is not the same as in Fluent, so i really see some flaws in this current method that Ansys doesn't seem to like to adress.

[sbaffini]

Under the CutCell label you can really find a relevant number of approaches, the common theme being, roughly, a cartesian grid (or sort of, e.g., octree) which is cut along the boundary to produce the final body fitted grid.

Now, concerning your questions, I think that it really boils down to what is your starting point and what are your goals. Also, pedantly following the basic CutCell idea might not be the right approach in any case.

In my experience, if your goal is just having a robust grid generator (i.e., to directly mesh a dirty cad) producing mostly cartesian cells (yes, they tend to be more accurate and robust even for unstructured schemes), I would just do that (i.e., a mesh generator) and keep the solver just unstructured. Besides their merits, this is what the Fluent CutCell and Snappy are (and use this to avoid poor cells which would result from applying the straight cutcell recipe). In this case you can appropriately manage the BL part of the grid. Also, non-isotropic octrees are a possibility (https://www.esi-group.com/software-s...te/cfd-viscart) which, while not being perfect for any case, are really more flexible than the pure 3D refinement of octrees.

On the other side, if you already have a previous, more limited, data structure in a code (either structured or octree), you can keep it mostly the same by just keeping the boundary cells (and all their faces, including interior ones) separate from the rest. Then, you just need to add a loop on such cells (you need a separate list of them) in which you treat both the boundary conditions and fluxes toward the interior. You can look at this as a multiblock approach, with the boundary block actually being unstructured and the interior one being just what you had previously.

Both the approaches above are meant to actually produce a body fitted grid with unused cells just discarded. So, as clearly emerged, some unstructured part is really a necessity. This is also true for the visualization. Both the octree part (if present) and the boundary are, in general, made of polyhedral cells and you should use an unstructured IO format that will handle them properly (e.g., Ensight or OpenFOAM).

In contrast, other approaches exists, where you keep your full grid in memory, even the solid part (this might make sense in cases with moving objects). I don't have experience with such approaches but, according to the literature, they are typically managed following the original code structure (mostly cartesian or octree) and properly managing the cells near the boundary (in these cases there is not, usually, a real BL grid, so it might not be the best approach for some applications) and in the solid, both of which are somehow listed separately. I have no idea how IO is managed in this case.

In the end, if I had to choose, I would pick up the first option. Keep the solver and grid generator separate. Make the solver unstructured and agnostic of the grid generator. Make the grid generator capable of producing a general unstructured grid. This, at least, is the general point of view. As your problem is the grid, you solve that problem.

Whenever you have additional constraints, you might want to use one of the other approaches. But don't use pure complexity as an indicator of the best route. The first approach might seem more complex, but it really is the exact same matter if you want to do it properly. Obviously, the grid generator approach has no discounts, it can only produce valid grids to be of any value. But this is a great feature, which you can use as check. In the other cases this is not anymore present (not at the same level at least), and problems might go unnoticed.

Overall, the pros are:

- the handling of dirty cad geometries with more robustness with respect to bottom-up grid generators
- better accuracy and robustness for proper grids
- in some cases moving objects are treated without pain

The cons are:

- whatever approach you follow, cutting the underlying mesh while producing only good cells is complex or requires a complex special treatment on the solver side
- unless you try to do what Snappy does, i.e., inserting a BL, the grid near the boundary might not be awesome. Inserting a BL is also complex. Anisotropic octrees can only partially ameliorate this.
- if you don't follow the separate grid generator/solver approach, the resulting code will eventually increase in complexity
- at least for visualization, you're going to need polyhedral cells. You are then limited on the visualization software and format.