-
Notifications
You must be signed in to change notification settings - Fork 836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Inconsistencies and improvements to SST model #2329
base: develop
Are you sure you want to change the base?
Conversation
- Added production terms to SST
- Added user-defined production limiter constant for TKE
- Updated boundary conditions as in TMR page
Common/include/CConfig.hpp
Outdated
nPrandtl_Lam, /*!< \brief Number of species | ||
addDoubleOption("FREESTREAM_TURB2LAMVISCRATIO", TurbIntensityAndViscRatioFreeStream[1], 10.0); Prandtl number. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this intentionally commented, or...? If it is used, I guess this should go to line 872
nPrandtl_Lam, /*!< \brief Number of species | |
addDoubleOption("FREESTREAM_TURB2LAMVISCRATIO", TurbIntensityAndViscRatioFreeStream[1], 10.0); Prandtl number. */ | |
nPrandtl_Lam, /*!< \brief Number of species laminar Prandtl number. */ | |
addDoubleOption("FREESTREAM_TURB2LAMVISCRATIO", TurbIntensityAndViscRatioFreeStream[1], 10.0); /*!<\brief Freestream mu_turb to mu_lam viscosity ratio */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a wrong copy-paste from me. It should not be there in the first place.
Great contribution, Thanks @rois1995 ! |
If you are looking into robustness aspects too you should get in touch with @emaberman and @YairMO, seems like they have some good ideas and between the free time of 3 people a lot more can get done :) |
Hi, Regarding the cross-diffusion term (CD) that appears in Omega source term (residual). The SST model (1994/2003) is a high-Reynolds-number model. Namely, It can not predict correctly the sub-layer region (especially the correct profile of the TKE). Therefore, only a positive contribution is required. Moreover, since the SST model was design as a k-w and k-epsilon blending, the CD term "belongs" only to the k-epsilon "branch", that is why the CD term include the factor "1-F1". However, it may happen, that the factor "1-F1" is not a 100% safe guarantee. It may happen that "1-F1" is not zero in region where the CD term is negative (this happen due numerical errors). To avoid such a situation, it is a good idea to clip the CD term with zero. Otherwise, severe numerical robustness issues may rise. |
- Given option for cross diffusion limiting in W residual
Hi, The use of an Omega production limiter (about the cross-diffusion term) is correct for low-Reynolds-number (LRN) models (the approach described by Peng et al. is very naive; there are other more rigorous treatments). For high-Reynolds-number (HRN) models, the clipping should be zero, keeping the cross-diffusion term positive; thus, the current implementation is correct. Indeed, it is not exactly as it appears in Menter's original publication. The factor (1-F1) aimed to promise that the cross-diffusion term will be activated only outside the boundary layer, where it is positive (the cross-diffusion term switches its sign deep inside the boundary layer). This was also recognized by Peng et al. (first paragraph above Eq. 17). However, it may happen that the factor (1-F1)=1 where the cross-diffusion term is negative. Usually, it may happen at the wake, very near the airfoil trailing edge, where the upper and lower boundary layers merge. It is due to the imperfection of the F1 function. To summarize, the current implementation is correct, and it is perfect for HRN models. |
For the sake of clarity, "current implementation" refers to the current treatment of the production code |
What YairMO is saying, is that allowing negative cross diffusion values is incorrect for high Reynolds models and should not be an option, this is a fix used for low Reynolds models only |
Hi @YairMO, Hi @emaberman , thank you very much for your comments. I haven't found any suggestion in literature to clip to only positive values the cross-diffusion term in the w-equation. I understand that it might be more robust, but it is not the standard implementation of the SST model, which is the first thing that we need to achieve. Only then we can build on top of that to improve the robustness of SU2. Nevertheless, I tried the SWBLI test case and I compared the results across 6 different combinations: 1- develop branch, no changes When my branch is used, then the changes to the supersonic inlet BC are already in place. I haven't achieved convergence with 1, 2 and 3. More precisely, 1 diverged right away (after 30 iterations), while 2 and 3 gave "FGMRES - Orthogonalization Failed" after 900ish iterations. Here you can see the residuals for the different combinations. Unfortunately I will be busy with the AIAA Conference next week, thus I don't know how much I will be able to work on this. The next test case will be the 2D airfoil near-wake from TMR. |
Hi rois1995, First of all, enjoy your time in Las Vegas. Any paper that you are presenting? As for our discussion about the cross-diffusion term, I've emailed the "source" (Menter). I believe he will make it clear. |
I have tried running 7 consecutive and identical simulations with 4C10T and the residuals are not consistent. Moreover, Run 2 and 6 diverged respectively after 251 and 430 simulations. Here I am showing the residuals of the TKE (I know that NK does not apply to the turbulence solver but it is cleaner to visualize than the residual for the density) I also tried going back a few commits right before changing the Reynolds stress computation and the situation is even worse. Also tried with the develop branch and same non-consistency, even though every run here has diverged. Here i summarize the convergence of these runs, 1e4 iterations means that it has "converged":
|
Are you trying to reproduce these results https://su2code.github.io/vandv/swbli/? or using your own meshes? |
I am trying with the .geo file used to create the meshes in the V&V folder. However, I am trying with a finer mesh, with a mesh sizing factor of f = 3.9762. I also tried the develop branch and, even though it always diverges, also there the iterations done are different. I have updated the previous comment. With the coarser meshes I might have the same problems, but convergence is easier thus I think that I might need more trials. I'll start running some simulation with the 3rd level grid. |
Are you initializing from coarser results? I just checked that the L3 mesh still works fine in develop initialized from L2 results. |
Every simulation starts from zero. I also tried the third grid level and these are the results after seven runs Runs 2, 6 and 7 diverge at different iterations while Run 4 converges to the desired residual value (log(RMS(Res_rho)) < -11.5). Running on 4 cores and 10 threads is a problem in this case? Or has the same problems of using 40 cores? |
The ILU issue depends on number of cores regardless of MPI/OpenMP split. |
I tried a couple of things:
The peak in the residuals that you can see around 3k iterations is different for each run, and leads to slightly different residuals after 10k iterations.
I will try having a look into the atomic operations. |
There are two sources for those, |
I can try having a look into this, but I am not sure of how much help I can be. Just from a quick look at the code I can see that the CSYSVEC_PARFOR has a NOWAIT instuction, whereas the SU2_OMP_FOR_STAT doesn't, and these are used right before the atomicAdd call respectively in the CSysVector and in the CNewtonIntegration. But I doubt that's the main cause of large discrepancies when using NK. |
I think NK is just more sensitive because the linear system uses a nastier Jacobian matrix. |
Then it's kind of difficult to evaluate the improvements of this branch. When comparing with the develop branch, the simulations with NK at least do not straight up diverge. When not using the NK solver, the residuals kind of improve, mostly when OMP is not used. These are the results on the mesh level 3. There are some spikes in the residuals, which strangely enough coincide for rho and w but have opposite direction. When OMP is not used, the develop branch stalls the turbulence residuals, whereas this branch keep on decreasing them. However, changing the number of cores used, the develop branch improves, while this branch does not. The main differences between the develop and this branch are:
|
Having a better look into the comparison between this branch and the develop one for the simulation with 10C and 1T. When looking at the solution, the residuals actually improve with this branch everywhere except at the bottom symmetry BC. Don't really know why, I am checking all of the changes to check. And, even more, the Mach number seems to be wrong on the bottom symmetry, but not on the upper one. UPDATE: The correction to the Supersonic_Inlet_BC works just fine, but some how it screws up the Mach on the symmetry (and I do not why bu only at the bottom one). It might be related to #1851, thus I am looking into including the tke in the computation of the sound speed. |
I have started implementing the computation of the speed of sound with the tke. Just to be sure that I am following the right path, I have pushed some changes. With these changes the linear solver diverges after 39 inner iterations, don't really know why. Any support is welcome. |
@@ -124,7 +135,8 @@ FORCEINLINE CRoeVariables<nDim> roeAveragedVariables(Double gamma, | |||
roeAvg.velocity(iDim) = (R*V.j.velocity(iDim) + V.i.velocity(iDim)) * D; | |||
} | |||
roeAvg.enthalpy = (R*V.j.enthalpy() + V.i.enthalpy()) * D; | |||
roeAvg.speedSound = sqrt((gamma-1) * (roeAvg.enthalpy - 0.5*squaredNorm(roeAvg.velocity))); | |||
roeAvg.tke = (R*V.j.tke() + V.i.tke()) * D; | |||
roeAvg.speedSound = sqrt((gamma-1) * (roeAvg.enthalpy - 0.5*squaredNorm(roeAvg.velocity) - roeAvg.tke)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is enthalpy being computed with tke? If not and then you subtract tke here...
Also please control the scope of this PR, you have another 3 work in progress PRs that took time to review and now are just sitting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, the enthalpy is computed just as E-P/rho, thus the kinetic energy should not be involved here. Regarding the other WIPs, they all involve the SST model (except for the recent SA one, but that should be finished), thus I think they should wait for this branch first.
As of now the problem is that the supersonic inlet has the correct values of Mach number (5) but on the symmetry BC this does not occur. It seems that on the symmetry BC the problem is the same as it was for the supersonic inlet before, but I still have to find a way to fix this. Moreover, this only happens to the lower symmetry BC, whereas at the top one the Mach is correct. |
Maybe I'm mixing it up, but I remember there was an issue with the wrong treatment (I'm not sure exactly what it was, perhaps gradient treatment) at Symmetry BC. |
I will look into this, but what I found is that the velocity component normal to the bottom symmetry BC is non-zero in this branch. |
I think this was one of the problems mentioned |
Yeah but this does not happen on the results with the develop branch and I have pulled the latest develop commits into this branch, thus it might not be the cause but the consequence of something else. After the first iteration there is a vertical velocity at the bottom corner between the supersonic inlet and the symmetry BC. Maybe it can be related to #2285 |
Part of the problem was that I was considering the TKE in the computation of the boundary conditions but not inside the domain since I was using the modified version of the SST model. With this, the vertical velocity at the inlet is in the range of 10^-12. The problem on the bottom symmetry still remains though. I am trying on the coarser mesh and I et FGMRES divergence after more than 1.3k iterations. I don't know if I should also change all the boundary conditions code to take the TKE from the solver rather than from the config. I guess that it should be done. |
@@ -801,7 +804,8 @@ | |||
bool viscous = config->GetViscous(); | |||
bool gravity = config->GetGravityForce(); | |||
bool turbulent = (config->GetKind_Turb_Model() != TURB_MODEL::NONE); | |||
bool tkeNeeded = (turbulent && config->GetKind_Turb_Model() == TURB_MODEL::SST); | |||
bool tkeNeeded = (turbulent && config->GetKind_Turb_Model() == TURB_MODEL::SST && !(config->GetSSTParsedOptions().modified)); | |||
// bool tkeNeeded = (turbulent && config->GetKind_Turb_Model() == TURB_MODEL::SST); |
Check notice
Code scanning / CodeQL
Commented-out code Note
@@ -5137,7 +5175,8 @@ | |||
Density_e = GetFluidModel()->GetDensity(); | |||
StaticEnergy_e = GetFluidModel()->GetStaticEnergy(); | |||
Energy_e = StaticEnergy_e + 0.5 * Velocity2_e; | |||
if (tkeNeeded) Energy_e += GetTke_Inf(); | |||
// if (tkeNeeded) Energy_e += GetTke_Inf(); |
Check notice
Code scanning / CodeQL
Commented-out code Note
@@ -5164,7 +5203,8 @@ | |||
Density_e = GetFluidModel()->GetDensity(); | |||
StaticEnergy_e = GetFluidModel()->GetStaticEnergy(); | |||
Energy_e = StaticEnergy_e + 0.5 * Velocity2_e; | |||
if (tkeNeeded) Energy_e += GetTke_Inf(); | |||
// if (tkeNeeded) Energy_e += GetTke_Inf(); |
Check notice
Code scanning / CodeQL
Commented-out code Note
@@ -7258,7 +7302,8 @@ | |||
Velocity2 += Velocity[iDim]*Velocity[iDim]; | |||
} | |||
Energy = P_Exit/(Density*Gamma_Minus_One) + 0.5*Velocity2; | |||
if (tkeNeeded) Energy += GetTke_Inf(); | |||
// if (tkeNeeded) Energy += GetTke_Inf(); |
Check notice
Code scanning / CodeQL
Commented-out code Note
Proposed Changes
Hi everyone,
I have found some inconsistencies with respect to the literature on the implementation of the Menter's SST model. I would like to use this branch as test bench for any corrections/improvements made to the SST model.
Implementation errors found:
positive portion of the cross-diffusion term in Eq (A2)" pag. 1604. Moreover, a clipping has been introduced for large negative values of this term, as suggested in Peng, Shia-Hui, Peter Eliasson, and Lars Davidson. "Examination of the shear stress transport assumption with a low-Reynolds number k-omega model for aerodynamic flows." Eq 17.
Changes to SST model proposed:
I've seen the proposed changes to the lower limits of k and w in #2323 and I tried implementing it in my branch. However, if the implementation proposed in the respective PR is preferred then I will change mine.
Related Work
#2323 #1851
PR Checklist
Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.
pre-commit run --all
to format old commits.