I want to compare the wall shear stress calculated directly from Ansys Fluent with the value that I can calculate from ParaView based on the derivative of the velocity vector obtained from the GradientOfUnstructuredDataSet Filter. I have noticed that the value obtained from Paraview seems 2.5 times lower overall but both follow the same pattern.
I am quite confident on the formulation of the WSS I use and I checked the ouputs of the GradientOfUnstructuredDataSet Filter. I compared the vorticity obtained from the filter with that computed on Ansys Fluent and I can see that Paraview once again underestimates the results compared to the CFD solver. I’m not an expert on finite elements, but I suppose that this has to do with the way the filter calculates de velocity vector field, any hint of what could I do alternatively would be of great help. I attach an image with the WSS and vorticity values obtained.
To be honest, my math for the gradients is not exceptionally strong. The Gradient Of Unstructured Data Set filter basically calls the derivative functions of vtkCell, which have been around since the early days of VTK (I think circa mid 1990’s). I’m not saying they can’t be wrong, but I’m not brave enough to change them.
How exactly are you computing wall shear stress in ParaView? Simply finding the grading on the surface would be wrong.
Hi!
First of all thanks for replying so fast, computing derivatives on meshes isn’t my expertise either. In principle, I’m working with 4D Flow data but I wanted to validate my WSS calculating pipeline with a simulation obtained from Ansys Fluent (which I have assumed gives corrects estimates of the WSS, maybe I’m mistaken). I used the velocity gradients to compute the stress tensor in each cell and perform the dot product with the normal of each triangular element as defined in the table below, from this paper.
I’m no expert on finite element methods, so maybe there is something wrong with this formulation. That is why I decided to compare the vorticity obtained from the GradientOfUnstructuredDataSet Filter and the one computed by Ansys since I assumed they both calculated the rotational of the velocity vector and should in theory be equal. To my surprise, as you can see in the image I attached on my previous post, that is not the case. Before making this thread I bumped into other posts [1, 2] in which other people seem to have stumbled upon the same problem as me.
I don’t think this is a bug but more of an accuracy issue. For the most part the Gradient of Unstructured Data Set is probably either a zeroth or first order accurate method. I can’t say for sure since I have don’t a rigorous mathematical analysis of it. If some solver code computes a different gradient, or gradient-like quantity, that solver probably has ways to compute more accurate gradients, especially near the boundary. The Gradient of Unstructured Data Set algorithm is probably an order less accurate on the surface as well.
I think a better way to examine Gradient of Unstructured Data Set would be to input an analytic function with known gradient and compare the result to that known gradient. You can create your own analytic method with the Calculator filter, or faster through the Python Calculator.
@Andy_Bauer I get that different ways of computing gradient can give different answers. I’ve seen groups using specific versions of gradient estimation for this reason.
But a difference by a factor of 2 seems excessive. Could we reasonably expect the computation to be that different for two reasonable forms of computing the gradient?
I’m assuming that the shown visualization is for the surface of the domain where ParaView’s filters will likely be less accurate. A factor of 2 certainly seems excessive though but I’d still maintain that comparing Gradient Of Unstructured Data Set to an analytical result is the best comparison. At least comparing to internal values, e.g. on a Slice plane, may give more similar values. I don’t know if Fluent is using a finite-difference, finite-volume, FEM, or some other scheme for discretization but for at least a finite-volume scheme lifting the solution from cells to points at the boundary “properly” is probably not a straightforward algorithm. Fluent may do similar operations for the gradient.
I faced the same problem with Fluent. Vorticity at the wall is EXACTLY 0.5*the real value (using Fluent as a reference). However the vorticity value is OK in the rest of the flow field (interior points), i.e., both Fluent and PV provide identical values.
The fact is that Paraview do not have knowledge of the wall non-slip condition and also its gradient calculation relies on the velocity points on BOTH sides of a given point: since the wall points only have 1 neighbor point, the vorticity is half the expected value.
The best way to solve it is to keep your vorticity array as it is for all the points except the wall points. For the wall points you can extract surface and apply a calculator filter to multiply those values by 2.
Andy/ Miguel/ Ken,
Would the correct thing to do be to have the Gradient Of Unstructured Dataset actually do this calculation internally to figure out if it is near a wall?
IMHO, I don’t think this should be the default behavior. As an example, if you create a Wavelet source and then a Calculator filter with coordsX for the input and then use the Gradient of Unstructured Dataset you’ll get the proper result of [1, 0, 0] everywhere. If we hacked the Gradient of Unstructured Dataset we’d get the wrong answer here.
I think this issue is unique to CFD where there are high gradients at the surfaces due to the boundary layer and this is the reason for the poor gradient approximation there.
First of all, I wanted to thank you all for participating in the discussion. I generated some visualizations following some of the advice given on the replies above. As suggested by Miguel I extracted the surface and multiplied the Paraview obtained vorticity by a factor of 2. As you can see in the image, in my case the optimum scaling factor is around 2.66 (I’ve only adjusted it visually).
Next, I wanted to test if it is true that the vorticity just differs on the surface, since Paraview doesn’t account for non-slip condition (Since my data is coming from a Fluent simulation where the non-slip condition was fullfilled I don’t know if this matters in Paraview, v=0 in the surface of the structure). So I basically calculated the absolute difference between the magnitude of the Ansys and Paraview obtained vorticity and performed a Clip. In the image below I compared side by side the original and scaled data (the same 2.66 factor from above). I applied the scaling to the whole volume to observe if it somehow improved over the original.
Nevertheless, I thought that this visualization could be misleading since the range of the vorticity is quite high ([0,560] for the vorticity magnitude from Ansys), meaning that in areas of high vorticity it is highly probable that the difference is going to be higher. To solve this I divided the absolute vorticity difference in each point by the Ansys vorticity magnitude and multiply it by 100 to obtain a percentage of the error respect to the FEM solver. I attach the image below. I don’t venture to interpret the images, since my approach could be wrong, but to me it seems that the difference in the bulk is also reduced when scaling it, and that would not correspond to just an error on the surface.
I agree with the answer of Andy Bauer. It is just a CFD issue. However, it may be interesting to consider including a CFD option that multiplies the vorticity and strains by 2 at walls.
I agree that it is a CFD issue but for what you can see in my previous reply it doesn’t seem as simple as multiplying by a factor of 2 the values on the surface.
Thanks for your images. I forgot to mention that the verification I did was for external aerodynamics cases (2D and 3D CFD of wings and airfoils in subsonic and transonic conditions at high Reynolds number). Moreover, the simulations I used have a boundary layer mesh refinement with Y+=1 and Spalart Allmaras model. I didn’t use wall functions. I resolved the boundary layer up to the wall. In those conditions i found out the results i told you before (Vorticity OK inside but 0.5 at walls).
Is that your case? Please, could you provide more details of the wall functions and boundary layer mesh? This could have an impact in the vorticity calculations.
Dear All,
I ll follow the conversation as I was facing the same problem some months ago and ended up realizing that the way how PV calculates derivatives is not as accurate as any other CFD solver.
I ve already discussed with Kenneth Moreland in a previous post.
Hopefully we will find a way to go through this! Thanks to all
