|
[Sponsors] |
September 20, 2012, 04:53 |
Fluent Integration Numerics
|
#1 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Dear All,
I try to understand the integration numerics of Fluent and have two problems right now: I) Theory Guide 20.3.3 explains the evaluation of gradients at the cell centers. In Navier-Stokes integration procedures, gradients of different values are needed on the cell faces. Does it mean, you will choose the way Fluent calculates the gradients (such as velocity) in the cell centers at "Solution methods -> gradient" and then use a certain method specified by let's say "Spatial Discretization -> Momentum" methods to interpolate these cell center values to the faces? II) I am stuck at another point, maybe someome can help me: Ferziger and Peric explain the integration by using different levels: a) Cell face integration is approximated by a certain summation over points that are related to that surface. b) The values at these points are approximated by an evaluation of relevant cell centered values. If I unterstand this correctly, point a) is explained in "Theory Guide -> 20.2", which means, that Fluent's surface integration is always the same: A surface integral is approximated by the sum of all cell face values times the corresponding surface. Point b) is explained in "Theory Guide -> 20.3.1", so how to obtain the face values from the cell center values. Ok, but: Ferziger and Peric say, that Fluent's way of calculating a) is always second order accurate. If we use a first-order scheme for b) the resulting scheme will be 1st order accurate, ok. But why would we use a scheme for b) that has a higher accuracy than 2nd. ? Since a) is only 2nd order accurate the resulting scheme can never be better, independent of what we use for b). |
|
September 20, 2012, 15:10 |
|
#2 |
Senior Member
|
I) In Fluent you can choose how cell centered gradients are calculated (Least-Squares, Green-Gauss cell based, Green-Gauss node based). These gradients are used with a deferred correction approach (evaluated explicitly, put into the source terms under adeguate form and updated with the iterations) to improve over the 1st order evaluation of face-centered values.
These face centered values are the convective and diffusive flux. However, you can't choose how to improve the discretization of the diffusive flux (which is always 2nd order central), only of the convective flux (for which you have several available schemes). II) Using your terminology, no scheme for (b) which has order higher than 2 is available in Fluent; so there are no contradictions. |
|
September 20, 2012, 16:27 |
|
#3 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Hi, thank you for your explanation!!!
I) I don't know "deferred correction approach", but I think I will find something in google. The "Momentum" method is just for the convective part and I don't have any choice for the diffusive part. Is it that, what you are saying? II) I thought (just from the name - without reading the details), that "3rd order MUSCL" is indeed 3rd order. Wouldn't that be the type (b) scheme, I read about? |
|
September 20, 2012, 16:57 |
|
#4 |
Senior Member
|
I) Yes
II) The original MUSCL scheme is second order accurate: B. Van Leer: Toward the Ultimate Conservative Difference Scheme. IV. A Second Order Sequel to Godunov’s Method, Journal of Computational Physics, 1979 I don't see how this could become 3rd order for an unstructured code. Indeed no details are provided in the Fluent manual. However, even if it was, there is no way to check it in Fluent because, as you said, all the other spatial approximations are only 2nd order. |
|
September 21, 2012, 15:46 |
|
#5 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Thank you very much, maestro!
I really appreciate your help. Sometimes the Fluent manual doesn't really help to get these details... |
|
November 27, 2012, 08:55 |
|
#6 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Again in this old thread, but with similar scope:
1) The face values are needed for the a) convection terms and b) the Green-Gauss gradient evaluation. Now, why does Fluent use different ways for calculation? 2) Also: The Green-Gauss node-based gradient evaluation averages nodal values to compute the face values. Thus, nodal values are known in this case. They could be used to enhance the computation of the surface integrals (such as the convection terms). Right now the surface integrals are just approximated by face values times area. This could be done with higher accuarcy by using the nodal values. Any ideas? |
|
November 27, 2012, 12:13 |
|
#7 |
Senior Member
|
Dear Rodriguez:
1) There are two reasons for this difference (in my opinion). The first one is that the concept of the gradient is generally different from that of the convection term, hence upwind discretizations would not be well suited for the gradient. However, even considering centered discretizations (like for the central scheme in fluent), higher order terms would involve the gradient itself leading to an implicit gradient relation. While there is no reason to not consider it (Code_Saturne actually uses it), it is impractical for a solver like Fluent (especially because only first order accuracy is required for the gradient in order to achieve the second order accuracy for the face value). 2) Again, you have two answers here (still in my opinion). The first one is that, again, all the remaining terms are still discretized with second order accuracy and a better integration of the fluxes alone is not giving you any better answer (also, those node values are still no better than second order accuracy... didn't do the math, but there are chances that you can't overcome that accuracy barrier). The second is that all these higher order terms are treated in Fluent by the so called deferred-correction approach. So, not only you have to update them at every inner iteration (at least, in theory, Fluent should), which is more costly, but their actual explicit treatment is not necessarily trouble-free. |
|
November 27, 2012, 14:22 |
|
#8 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Thank you - again - for your response. I will have to think about that!
__________________
The skeleton ran out of shampoo in the shower. |
|
February 19, 2013, 08:43 |
|
#9 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Dear Paolo,
I tryed to find some more information about the diffusion term discretization. Actually, Fluent manual only says that "central-differencing" is used, but not how. As far as I understand it, there are two common ways for the diffusive flux: a) (as explained in the Ferziger/Peric book) The direct connection of the two cell centers does not cross the boundary in its center. To get the derivative at the cell center (face value=), one needs to connect two different points inside each cell. The value at these two points is estimated by cell center value plus some correction via the gradient at the center. b) Using the cross-diffusion approach. Since we need the gradient at the boundary in normal direction, the direct gradient is calculated and then the cross-diffusion term is subtracted. BTW: If it is a), where are the gradients at the cell centers taken from? Are these the ones I chose under "Solution methods -> gradient"?
__________________
The skeleton ran out of shampoo in the shower. |
|
February 21, 2013, 05:58 |
|
#10 |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Independent of my previous post I am wondering this: How does Fluent calculate the convective fluxes at the cell faces? I mean, we need to know "Phi*rho*velocity" at the cell faces and Fluent help only holds forth about the "Phi" but not about the "rho*velocity". Does anyone know this? Does it use the same value as it uses for the continuity equation?
__________________
The skeleton ran out of shampoo in the shower. |
|
February 21, 2013, 07:17 |
|
#11 |
Senior Member
|
Dear Rodriguez,
as far as concerns the first question, Fluent uses an approach based on implicit evaluation for first neighbor terms plus an explicit non-orthgonal correction (treated by a deferred correction approach). This correction is based on the gradients in the cells sharing a given face, which i guess are computed with the method specified in the Fluent options. For what concerns the mass flux, yes, Fluent (every code as far as i know) has to use a continuity based mass flux (one which satisfy the continuity equation). I don't know exactly how it is computed, but it should be based on a 1/2 average among sharing cells for the face. |
|
February 21, 2013, 07:35 |
|
#12 | |
Senior Member
Philipp
Join Date: Jun 2011
Location: Germany
Posts: 1,297
Rep Power: 27 |
Quote:
Fluent help says, that this (50%-weighting) leads to checker-boarding and that some other weighting based on the momentum equation is used...
__________________
The skeleton ran out of shampoo in the shower. |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Two questions on Fluent UDF | Steven | Fluent UDF and Scheme Programming | 7 | March 23, 2018 04:22 |
heat transfer with RANS wall function, over a flat plate (validation with fluent) | bruce | OpenFOAM Running, Solving & CFD | 6 | January 20, 2017 07:22 |
Fluent VS CFX | Far | CFX | 0 | November 12, 2011 13:26 |
Fluent 6.3 32bit vs Fluent 12.0 64bit | ibex7 | FLUENT | 7 | April 18, 2011 03:44 |
Fluent 12.0 is worst then Fluent 6.2 | herntan | FLUENT | 5 | December 14, 2009 03:57 |