CFX Periodicity Bug
 

In any CFX-Post of one-pitch blade rows, the contour plots on a turbo surface at a constant stream or a constant blade aligned show a discontinuity at the periodic interface when two blade counts are on the screen. More discontinuity is shown with total pressure (with Stn or without). Turn on the line contour plot to see the issue.

Ansys help has just confirmed the bug. Even in their tutorial file of a single-stage turbine (stator+rotor), they found the issue. Their answer is the culprit is an unmatched mesh at the interface under GGI treatment.

I feel very serious because it means that CFX solver fails to meet the rotational periodicity exactly at every local node, which means the flow variable values are not fed into the right neighboring node, probably resulting in a wrong solution.

I hope that this info would be helpful in dealing with CFX.

Can you show an image of what you are seeing?

Attached here.

Though the discontinuity may be true (as support indicated to you), the total pressure is not part of the solution. Recall is computed from solved variables.

If you require the variable at periodic boundaries to be exact on both sides of the periodics, you MUST also provide a matching mesh; otherwise, you get a discretization error at the unmatched mesh faces.

The discretization error is a function of the mesh quality on both sides of the interface (see theory documentation). Then, how good is your mesh near the periodics, and what is your mesh resolution change across the interface.

Hope the above helps,

I have also discussed this with ANSYS some time ago. My understanding is that what you are seeing is mainly an issue with the post processor, CFD-Post drawing the contours. The post processor does not use the other side of the GGI interface to draw the contours and that results in small mismatches over GGI interfaces. My understanding is that the solver still achieves conservation across the interface to within the convergence tolerance achieved.

So I think the problem you are describing is a post processing issue, not a solver issue. I think you will find the solver is accurately resolving the interface.

Thanks for sharing your thoughts, Opaque and ghorrocks.

Flux conservation can be easily checked in the solver output through the balance at the periodic interface. No problems with the connectivity. My point is there could be many sets of local flow distributions while keeping the flux conservation. If you see an area near the interface, you should decide which side contours are correct across the discontinuity. Nobody knows !

More refined mesh will be better, but there is hardly one-to-one interface in meshing in reality despite refinement. My view is that CFX needs a better interpolation scheme to match the local flow variable values across the interface.

I do not think the Post has a problem because it uses each boundary node values in the contour plot. Already the other side of the interface has different values from the solver. If the Post issues, trying other plot program can fix the issue ? I do not think so.

I am not sure what you mean by "a better interpolation scheme to match flow variables". Finite volume methods do not match variables at interfaces, but fluxes corresponding to conservation balances. The solution variables are computed at the center of (or somewhere within) a control volume, and several approximations are made when discretizing the fluxes.

For matching interfaces, there is no flux discretization since the nodal value at the periodic faces are guaranteed to be equal to their counter part on the other side. That is, the periodic interface becomes an internal face of a control volume made of two parts: side 1 and side 2.

If your geometry is periodic, I assume I should be able to reproduce the other periodic boundary by an exact rotational/translational transformation. Not sure, why you imply that is nearly impossible for a mesher to create such pair of surface meshes. What meshing software are you using ?

Hope the above helps,

Thanks for your opinion, Opaque.

There are two kinds of FVM in CFD : one is the time marching method based on conservative forms of equations which solves the equations at a time, and the other is the Pressure Correction method which solves the equations in a pre-determined sequence. "FineTurbo" would belong to the former class, while CFX and Fluent to the latter.

As for the former class, there are also two kinds : the cell-centered or vertex schemes. In the cell-centered FVM, in order to obtain the rate of flux changes per time advances we need all flow variable values at each vertex, which come to the periodic or any interfaces.

What I meant for the better interpolation scheme was to exactly match each flow variable values across the interface vertex under the situation of mis-aligned mesh nodes.

I have never seen such a big discontinuity inside the blade from FineTurbo solutions. Please think that the gap exists in the middle of the blade passage. The wrong transferred values will impact the whole solution.

Opaque,

Forgot to answer your question : my case in the picture was using Turbogrid which has almost one-to-one matched structured mesh at the periodic interface. The tutorial one, I guess, looks to be with coarse irregular unstructured meshes.

You might wonder about my case in spite of the nearly one-to-one matched structured mesh. The contour in the picture is total pressure Stn, but there is no discontinuity shown in all other variable contours in CFX-Post. Thus, I thought that the Post would have some issues. Interestingly Ansys support team sent me the tutorial .res file to try out because they suspected my computer graphic troubles. Finally they and I happened to see the same discontinuity in the tutorial file, and even for EVERY variable contours. I have found the issue is not from the Post.

I will point out that you can see discontinuities like this with 1:1 interfaces as well. Even though no interpolation is required, the contour drawing issue I discussed can affect it and cause the contours to be non-continuous.

This is not correct, at least from my understanding of it. At boundary edges the contour plotting algorithm only has values on one side of the edge to interploate values from and generate contours. At internal locations it has values all around to interpolate from. Therefore you will get different contours on boundary nodes compared to the identical variable field at an internal node. A further issue is when the order of interpolation is different betwen the contour function and the solver - this will also cause mismatches.

Thanks for your post, ghorrocks.

Your saying is similar to Ansys support, but I cannot agree still. I will try out Tecplot to draw the same contours to see if the issue comes from the Post.

If anyone else can show the same issue, that would be more helping us.

Dear Turbo,

I think that you should take a closer look at the theory documentation for ANSYS CFX and ANSYS FLUENT.

I do agree about the different cell formulations: cell-centered, and cell-vertex ; however, your interpretation of how the fluxes are computed or interpreted seems a bit off (unless I misunderstood your sentence). Neither FLUENT or CFX have a solution value representing the boundary value: FLUENT solves for the vertex near the boundary (center), and CFX solves for the mean control value (also named conservative value in CFX speak). In CFX, the value of the vertices on the boundaries do NOT represent the solution at the boundary, but within the control volume adjacent to the boundary.

Also, to clarify ANSYS CFX does not uses any Pressure Correction discretization scheme. See theory documentation for explanation of the coupled pressure-velocity solver details.

Further clarifications for both FLUENT and CFX, both codes use the conservative form of the transport equations. They may not have it written in the vector form commonly used in the gas dynamic community (Hirsch's book for example), but the 3 codes are solving the same equations in the same form. You may have to dig deeper to notice the differences.

Hope the above helps,

Dear Opaque,

Thanks for your comments, but I'd like to reply to help you understand more clearly.

The Pressure Correction (or Based) Method, the 2nd class of FVM CFD, can be said to use a conservative form of governing equations but not a column matrix form like the Time Marching Method (the 1st class of FVM) which is of a true conservation formation.

In a broad sense, FLUENT, CFX and STAR-CD belong to the 2nd class, but in details CFX differs from FLUENT in the location where flow variables are obtained : i.e., CFX is a cell-vertex code, while FLUENT a cell-centered one. Another big difference between the two is that CFX gets pressure and velocity at a time but FLUENT follows the SIMPLE style sequence. Ansys CFX Solver Theory pdf shows clearly that CFX is a cell-vertex code, too.

At any boundary face where the mesh vertex is positioned, therefore, all the flow variables should be required in CFX and FineTurbo to estimate the change of flux going through each face. FLUENT can avoid it by using the staggered control volume concept because velocities are always obtained at the center of each edge, and pressure is found at the center of the control volume.

CFX is also different from FLUENT in terms of how to estimate the change of flow variables across each cell, i.e., it uses a shape function similar to the Finite Element Method concept. Recalling the old time when I had developed a time marching code in school, I am describing some features about each code.

I hope you could agree to my point that CFX needs more advanced interpolations at the periodic interface vertices (if the solver has the bug).

By the way, going back to the Post, I have tried to plot the same contours using Tecplot, but in vain. That is because Tecplot does not provide the surface slice on the surface of revolution, which fails to show the periodicity.

Current issue is which one is to be blamed between CFX solver and Post for the discontinuous peridiocity contours. I carefully vote for the solver, but ghorrocks points at the post. Ansys support is not willing to fix it, because they think the discontinuity is what all CFD codes have, which is not true.

UPDATE :

I created an exact one-to-one matching mesh case, and ran CFX with the GGI and the 1:1 connection options for the rotational periodicity. If the Solver has no bug, the two cases should show the same. The 1:1 connection showed nicely continuous contours in the Post, but the GGI had the discontinuous contours at the periodic interface. Ansys support has just started to re-think about the issue seriously to look into more. It looks that something is wrong in the GGI interpolation in the Solver. My recommendation is that, for an accurate solution, try to use the 1:1 connection if possible.

Thank you for the update. However, that is what I would have expected once there is a clear understanding of how GGI works compared to a 1:1 discretization.

Here is an attempt to explain by looking at what happens when you discretize on one side of the periodic boundary,

- For a matching interface with exact discretization (not GGI) the discretized equations for a node at the interface corresponds to enforcing a "Dirichlet/value" condition between itself and the matching node from the other side (after rotation to account for vectors variables). There would be no approximation or enforcing of fluxes since they are never part of the formalism.

- For a non-matching interface, i.e. GGI, the discretized equations are obtained by discretizing fluxes (non-zero Neumman treatment) on either side and matching them (after rotation to account for vector equations) between one side, and the other side.

From the above, I do not see how both discretizations can produce the same solution, neither they can produce the same values at the nodes. If we look at the mean value theorem (fro the GGI situation), the node represents a value within the control volume and since there are two control volumes, there is no guarantee those values will be the same on the interior on both sides control volumes. Even if the mesh is refined such the control volumes are nearly zero, there are two independent values and nothing that enforces to be identical to its matching pair, and that is independent of the interpolation used.

I do not recall where is explained, but it is well known fact that whenever a matching interface is possible we should use it since the discretization error is minimal compared to the GGI discretization error.

Hope the above helps,

Hi Opaque,
Thanks for your reply helping our understanding !
This morning I was informed by Ansys support that they reproduced my claim at their side, and asked this issue for clear explanation to Ansys CFX development team. I will keep you guys posted.

My bottom line is that since the 1:1 mesh connection case is not so common in our CFD lives, Ansys needs to provide an improved solution on this discontinuous nodal value issue (which will affect the whole solution accuracy). At least in the Post the discontinuity should disappear.

The Post looks working OK.

Though I understand your concern with the discontinuities in the post-processor, I would ignore the visual stuff first and focus on the solution quality instead.

Now that you have a matching interface setup working, and hopefully able to refine the mesh for it as well, I would run the case using the 1:1 discretization, and the GGI discretization and compare solutions with relevant engineering quantities computed in the ANSYS CFX solver, say: pressure drop, performance, pressure ratio, drag, heat transfer, etc..

Once such behavior differences are established and quantified, we can conclude (not speculate) if the discontinuity in the post-processor is relevant to the solver calculations upstream, or it is only relevant to the post-processing calculations downstream.

I follow your line of thought that the discontinuity is a symptom of something odd, the question is how much impact it has and where.

My 2 cents,

As I mentioned, I ran both cases at the 1:1 matching mesh. I found each solution of the 1:1 and the GGI is different in mass flow pressure, temperature and velocity, etc. though the magnitude might be ignored depending on how accurate solution you shoot for.

Another odd thing is the discontinuity contour comes up much bigger in total pressure, in particular, and Ansys support also identified it.

so Ansys CFX 17 is out. Here are the release notes.

Unfortunately R17 has the same issue, friend.
Ansys development team is now struggling to fix it.