[mavguy]

Hi all,

First time to this forum. I've got a question about vorticity plots generated from (usually FV) CFD codes. It looks like the vorticity fields that are written out by solvers are not piecewise constant in each element (cell) as I would expect. As I understand it, in the standard second-order accurate FV method, the primal solution (U) should converge with the optimal order of accuracy, while it's gradient (Q) should be one order less (i.e. piecewise constant).

Is some type of post-processing smoothing operation done to make the vorticity look nicer? I'm currently writing a Discontinuous Galerkin code to solve the NS equations, and was just wondering why the vorticity animations look so nice when I would assume they should only be first order accurate.

Thank you for your time,
John

[mprinkey]

Of the CFD packages in which I am well versed, the primitive variable fields themselves are only piecewise constant--velocity, pressure, density, temperature are all defined as single values per cell. And while some might be slow to admit this, we do sometimes play fast and loose when constructing interpolation schemes (say, by conflating the cell AVERAGE value with the value at the cell CENTROID!). I'm afraid the situation with plotting results may be even worse.

For historical reasons, many visualization packages are designed to handle unstructured data at nodes (as Finite Elements do--one of the big historical reasons in fact). Results stored that way allow for bilinear/trilinear interpolation and for continuity of iso-lines and iso-surfaces across cells. And, it makes for very smooth contour plots. And as you rightly point out, those may be only a convenient fiction. To make the cell-based solution data fit into the visualization package format like Paraview's (or just into the "smooth iso/contour plot" norm we've come to expect), the CFD code or the viz package will generate "node values," often just as the average of the field values in the cells that share each node--on boundaries, it may be the average of the face values that share each node, but the same principle applies. These are the data used to build the graphs, and result in artificially smooth plots.

There are options to see the actual cell/face values--if memory serves, there is a node values check box in Fluent that can be disabled to generate the more patchy plots. And ParaFOAM gives you the option to plot cell or node values.

[adrin]

You need not worry about "looks". "Looking nice and smooth" is not synonymous to "being accurate"! As already mentioned, traditional (most commercial) CFD are low-order and _highly_ diffusive. For visualization purposes they look really nice until you begin focusing on the fine details of the flow and realize that the flow structures are either completely wrong or missing important details. High-order methods are the way to go, but they are burdened with stability issues, which is probably why most commercial codes haven't adopted them (yet)!

adrin

[mavguy]

Thank you for the replies Michael and Adrin. I'm not too worried about looks, but it is always nice to have a "pretty" solution. I'm using high order anyway, and you can't really discern between a 3rd order and 4th order accurate solution just by looking at it.


I think I will just have my code export a continuous solution to ParaView.

[FMDenaro]

Hello,
I would express my point of view about this issue.
What happens is not a specific problem of FV methods or plotting softwares but is more general.
This expresses simply the fact that we use discrete state vectors, that happens in any kind of numerical solution, not only in CFD.
The real fact is that we compute just a set of values in a finite number of nodes. This is the world we get from numerical computation, just a finite number of values, what is the actual behavior outside of the nodes is arbitrarily defined.
Even considering the case of piecewise reconstruction, we consider the average value at the node position. In FV method, this turns out to be the classical case when the temporal update of values is in terms of averaging in the cells but to do the update we need of a reconstruction of the flux function at the interfaces. Therefore, the continuous reconstruction used in each scheme is the only congruent way that one should adopt in purpose of plotting the fields.
However, graphics softwares use internal interpolations that are not necessarily congruent to the class of reconstruction used in the CFD solver.
Just think about a high order methods that provides a set of values to be plotted by a software having smooth linear interpolation. You could see a "too smooth" behavior that is only due to the arbitrary interpolation.

In your case, you simply see the set of values of the discrete vorticity field that is reconstructed by the software. Therefore, you see some smooth interpolation over nodal values representing the function the solver is providing.
If I remember correctly, Fluent provides an option to see the graphics in terms of piece-wise reconstruction, this way it appears a discontinuous representation from cell to cell