-
Notifications
You must be signed in to change notification settings - Fork 918
k-omega SST 2D axisymmetric source terms #1195
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
Conversation
…e never needed alone)
|
|
||
| void CSourcePieceWise_TurbSST::ResidualAxisymmetric(su2double alfa_blended, su2double zeta){ | ||
|
|
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.
I would define this inline (in the hpp) and let the compiler have some fun trying to re-use some of the stuff that exists in the body of ComputeResidual.
Probably not massive performance gains but they are completely free in this case.
Otherwise everything looks very nice. Are you going to add the regression in this PR?
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.
Okay why not... I make it inline
I was going to add the case in another PR but as you prefer. I reckon there is not much risk in merging this in already since the current state of affairs is no more validated or tested for performance and strictly wrong as it is incomplete. From a little testing I can see only a small effect on the results but convergence seems to be improved
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.
Got it, I think it is always best to add it together with the code, while the reference results are fresh in your mind.
If you add it later you might find yourself having to debug again because of some change somewhere else.
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.
since the current state of affairs is no more validated or tested for performance and strictly wrong as it is incomplete.
It's cases like these (small changes) where unit tests are handy: https://su2code.github.io/docs_v7/Writing-Unit-Tests/
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.
Not sure about this but I don't really see the need for unit tests as this bit is structurally very straightforward code and its behaviour is tested in regression now anyway
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.
Regression tests detect change rather than correctness.
It is possibly that while fixing a bug a new one is introduced, regression values change, people check a few of them (it is boring work so no one tests all of them, especially if the residuals change very little), people update the regressions...
It has happened before, it will happen again.
With unit tests it is harder for that to happen, depending on the size of the "unit"...
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.
First sentence was wrong, text was edited.
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.
Alright I can see how that could happen but can't come up with a good unit test for this part. Keeping this in mind for the future though
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.
I agree with @pcarruscag. I brought up unit tests because "small changes that aren't complete" is a perfect use case for unit tests. Unit tests can be added to verify correctness before code is ready for a complete regression test.
| /*--- Add contribution to the jacobian for implicit time integration---*/ | ||
| Jacobian_i[0][0] += yinv*Volume*(sigma_k_i/zeta*TurbVar_Grad_i[0][1]-V_i[2]); | ||
| Jacobian_i[0][1] -= yinv*Volume*sigma_k_i*TurbVar_i[0]*TurbVar_Grad_i[0][1]/(zeta*zeta); | ||
| Jacobian_i[1][0] += yinv*Volume*sigma_k_i/zeta*TurbVar_Grad_i[1][1]; | ||
| Jacobian_i[1][1] -= yinv*Volume*(sigma_k_i*TurbVar_i[0]*TurbVar_Grad_i[1][1]/(zeta*zeta)+V_i[2]); |
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.
All the terms added to the normal SST Jacobian are negative to avoid imbalancing the diagonal dominance of the matrix.
Do you have a feel for how large the axi symmetric contributions might be compared with the normal ones? (I guess larger near the axis).
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.
They may have the same magnitude as the normal ones and may be negative or positive depending on the sign of the y velocity and the gradients. Yes the further from the axis the more the problem becomes just normal 2D. I will try different versions with nothing more added to the jacobian or only convection or only diffusion (or setting anything positive to zero perhaps but that seems no good idea).
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.
The "clamping things with min/max" to have the sign you want is very common.
We have a config option for "accurate flux Jacobians" that we use for other schemes, you can also base the decision to clamp or not on that option to make things more flexible.
pcarruscag
left a comment
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.
Aside those choices with the Jacobian all LGTM 👍
|
About the jacobian I could not find a situation where it made a difference (I tried a lot) so I commented it out. The residual itself does matter however. I added a test case which uses the same mesh as the NICFD nozzle tutorial. It is an axisymmetric transonic air nozzle without a shock. Pretty much any change to the axisymmetric flow or turbulence residuals would break it. i created a pull request on the test cases repo develop branch su2code/TestCases#59 but then I just went ahead and merged it into develop since there is no review policy |
|
Thank you for adding a regression. |
This implements the k-omega SST source terms for 2D axisymmetric problems in a new member function of the existing source term class (it would never be used independently of it so I did not create a new class).
The extra source terms are the difference between the equations in 2D cartesian and 3D cylindrical coordinates under an assumption of axisymmetry without swirl. They are almost the same as those for Wilcox's k-omega shown in this image (taken from http://eprints.gla.ac.uk/184394/1/184394.pdf).

Only the constants have been swapped for the blended ones and the changed definition of the eddy viscosity is taken into account (see menter1994.pdf). Cross diffusion is the same as in 2D when assuming there is no azimuth gradient.
Note that these source terms have the opposite sign (RHS) of the flow equations source terms (LHS) since the block is subtracted and not added.
Looking into creating an axisymmetric RANS test/regression case