[Jaydi_21]

When working with NSE or with the depth averaged NSE, what are the complexities involved with using triangular grids? or curvilinear grids?

For the curvilinear grids, I understand that the equations itself change, are the curvilinear ones more difficult to solve numerically?

For the triangular grids, it seems that the equations are the same...when using finite volume schemes, how to deal with the different reference system for each pair of neighbors cells? I mean, for two given neighbor cells the outward normal pointing vector is not in the same direction than for another two different pair of neighbors, and maybe it does not even coincide with the xy plane...do we strictly need some coordinate transformation when computing the fluxes at each cell?

[mprinkey]

Originally Posted by Jaydi_21

When working with NSE or with the depth averaged NSE, what are the complexities involved with using triangular grids? or curvilinear grids?

For the curvilinear grids, I understand that the equations itself change, are the curvilinear ones more difficult to solve numerically?

For the triangular grids, it seems that the equations are the same...when using finite volume schemes, how to deal with the different reference system for each pair of neighbors cells? I mean, for two given neighbor cells the outward normal pointing vector is not in the same direction than for another two different pair of neighbors, and maybe it does not even coincide with the xy plane...do we strictly need some coordinate transformation when computing the fluxes at each cell?

If you are using triangular grids, you will likely need to use either a Finite Volume or a Finite Element Method (or Discrete Galerkin that is sorta both). Those formulations involve integration over the volume/element and in the process, use the mapping/shape functions to assemble your control volume balances or Galerkin projected residual equations and use the Cartesian form of the equations. There are some unstructured finite difference methods, but none of them are widely used.

Curvilinear grids can (in principle) be used with finite difference, finite volume, and finite element schemes, but if you can come up with a grid mapping for your geometry, the finite volume/element schemes lose some of their value. You'd likely use a control volume finite difference formulation for simplicity.

A CVFD code would likely be done with simple 2D and 3D arrays and allow you to address neighbors as (i+1,j), (i-1,j),... It admits a wide variety of multi-sample difference and interpolation schemes (compact difference, QUICK, ENO/WENO). Also, special purpose linear equation solvers and smoother (line relaxation, FFT Poisson solver, etc.) are available because of the 2D/3D data organization. The only big price you pay is the incorporation of the metric coefficients from the grid transformation and the extra cross derivatives that arise. The core issue with curvilinear grids is that mappings to real geometries can be very (VERY) difficult. You will likely end up needing to build a multi-block solver to make it useful in even vaguely practical flow configurations if your intention is to model real engineering flows.

An unstructured CFD code (FE or FV) will be organized COMPLETELY differently. There is no implicit assumptions about neighbors because data is likely stored in 1D arrays. Neighbors would be found via neighbor (integer) arrays, say two 1D array running over all of the faces that list the cells on the positive and negative side of the face. For FE, the neighbor information is tied up in a per-element list of nodes that are shared by multiple edge-neighbor elements. The lack of neighbor-of-neighbor information and smooth coordinate lines prevent the use of high-order schemes like WENO and QUICK. Multidimensional, extended stencil schemes are possible (see unstructured WENO, for example) but the computational and coding complexity goes up very fast and you see diminishing returns. The linear equations that arise from these unstructured formulations gives you fewer options for solvers/smoothers. This is less of an issue though because Krylov and Algebraic/Geometric Multigrid schemes are state-of-the-art (albeit, not very simple to implement) and work fine with FE and FV. The big advantage of these schemes is that you can mesh almost any engineering flow configuration. Disadvantages is the limited order of the scheme and the need to incorporate special (usually explicit) skewness corrections, which can make non-linear convergence a bit less robust if you have ugly highly skewed cells.

[Jaydi_21]

I just need to see the advantages of quadrilateral grids over triangular and curvilinear ones (when working with finite volume). In my opinion, the first ones are much easier and you can have similar accuracy, but I don't know how to explain this in a technical manner. I've never tested a FV code with triangular elements, so it is not clear to me how to compute the fluxes when the triangle faces orientation does not coincide with xy cartesian plane for the whole domain.

[FMDenaro]

Originally Posted by Jaydi_21

I just need to see the advantages of quadrilateral grids over triangular and curvilinear ones (when working with finite volume). In my opinion, the first ones are much easier and you can have similar accuracy, but I don't know how to explain this in a technical manner. I've never tested a FV code with triangular elements, so it is not clear to me how to compute the fluxes when the triangle faces orientation does not coincide with xy cartesian plane for the whole domain.

Generally, the advantage of curvilinear gird lies in the alignement of the flow with the coordinate lines. In case of more complex flows, (unsteady, separated, turbulent) this advantage is somehow less evident.

A Finite Volume code is suitable to be implemented on any type of grid just defining the numerical flux function on each of the sections that built the FV. You can find some paragraphs on the book of Peric & Ferziger describing the implementation on triangular grid. Years ago I developed my formulation on tringular grid in a FEM manner: https://www.researchgate.net/publica...blicationTitle

A software like Fluent manages this method, too. You can have a read to the guide.

[mprinkey]

I answered your question about "complexity" of the two approaches. And (IMO) the construction of face fluxes on unstructured meshes is sort of the easier part compared to the data structure complexity and geometric reference mechanisms that are necessary.. That is all utterly foreign to the structured u(i,j) finite-difference approach to coding that most people are familiar with.

Prof Murthy's CFD notes will give you all of the details about implementing an unstructured FV CFD code:

http://cft.gau.ac.ir/parameters/nash...20,%202002.pdf

She was one of the key architects of the FLUENT in the 1990s when they were making it unstructured, so she knows very well all of the difficulties. Chapter 4 covers the details associated with handling unstructured flux computations. Convection is usually done via first- or second-order upwind using limited gradients for the 2nd-order terms, so that is fairly easy. Diffusion is much more complicated as you can explore in Section 4.2.