SU2
SU2 copied to clipboard
su2code
[WIP] Implementation of Simplified LM Transition model
Proposed Changes
Hi everyone! I am starting to implement the Simplified version of the Langtry-Menter transition model following the work in https://doi.org/10.2514/6.2012-672. More updates will follow.
Related Work
This follows the implementation of the LM model as #1751.
- [X] I am submitting my contribution to the develop branch.
- [ ] My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
- [ ] My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
- [ ] I have added a test case that demonstrates my contribution, if necessary.
- [ ] I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.
Technically, this model has only one equation, the one for intermittency. Most of the functions are the same as the original LM model. Should I consider the Simplified model (SLM) as an option for the LM model to avoid duplicates? This is how I started, but I am open to discussions and suggestions.
I have a question: for each point in the mesh I am trying to compute the dot product between the velocity vector and the normal to the wall of the nearest point on the wall. How do I access such information? I've found that in the CPoint class I have the ClosestWall_Elem variable which stores the index of the closest element on a wall. However, when I try to assess the information with a number of cores greater than 2, it crashes. Moreover, to recover the normal of the element I perform a mean of the normals on the nodes of that element. Is there a structure that has the normals saved for each element of the primal grid? The part that I am referring to is from line 208 in CTransLMSolver.cpp .
See what is done at the bottom of CGeometry.cpp in CGeometry::ComputeWallDistance. You need to communicate the normals you need first.
I have a question: for each point in the mesh I am trying to compute the dot product between the velocity vector and the normal to the wall of the nearest point on the wall. How do I access such information? I've found that in the CPoint class I have the ClosestWall_Elem variable which stores the index of the closest element on a wall. However, when I try to assess the information with a number of cores greater than 2, it crashes. Moreover, to recover the normal of the element I perform a mean of the normals on the nodes of that element. Is there a structure that has the normals saved for each element of the primal grid? The part that I am referring to is from line 208 in CTransLMSolver.cpp .
There is the geometry toolbox for dot product and normal: https://github.com/su2code/SU2/blob/master/Common/include/toolboxes/geometry_toolbox.hpp just look in the code for examples, in vscode you can search for GeometryToolbox::DotProduct or GeometryToolbox::Norm
I have a question: for each point in the mesh I am trying to compute the dot product between the velocity vector and the normal to the wall of the nearest point on the wall. How do I access such information? I've found that in the CPoint class I have the ClosestWall_Elem variable which stores the index of the closest element on a wall. However, when I try to assess the information with a number of cores greater than 2, it crashes. Moreover, to recover the normal of the element I perform a mean of the normals on the nodes of that element. Is there a structure that has the normals saved for each element of the primal grid? The part that I am referring to is from line 208 in CTransLMSolver.cpp .
There is the geometry toolbox for dot product and normal: https://github.com/su2code/SU2/blob/master/Common/include/toolboxes/geometry_toolbox.hpp just look in the code for examples, in vscode you can search for GeometryToolbox::DotProduct or GeometryToolbox::Norm
The problem is more related to the finding of the wall-normal for a point within the volume mesh, not to the computations that it will be involved in.
The solution I suggested didn’t work?
I still have to check if the implementation is correct but with more than two cores the code breaks. However, I found out that the wall-normal of a volume point can be computed as the normalized gradient of the wall-distance. Does this sound correct to you?
However, there is a problem: I am using the aux variables to compute these gradients, but to compute dot(n, U) I first need n, thus I cannot compute them simultaneously. Since these computations are performed in the Preprocessing of the solvers, I was thinking to compute the normal within the FLOW_SOL preprocessing and the dot(n, U) in the TRANS_SOL preprocessing since the flow solver comes before the trans solver. Is this right?
It's not correct. You need to follow the pattern from CGeometry::ComputeWallDistance First you collect all the normals that are local to the rank Then you collect the normals across all ranks (using the NDFlatner), then you access this information by (ClosestRank, ClosestMarker, ClosestVertex) You cannot access the local information directly because ClosestMarker and ClosestVertex may refer to a different rank.
I managed to implement the computation of grad(n*U)*n, but at the moment it is located into CTransLMSolver::PreProcessing. It seems to work with a structured mesh on a flat plate. Currently, I am testing with a 2D profile too. However, being into the PreProcessing of the transition solver, the normals are computed at each iteration, thus it is not computationally efficient if non-deforming meshes are used. I am looking into where to put it such that it is computed just if the mesh is updated (and at the first iteration of course).
Plus, I have added a whole lot of variables to the output, but they will be removed in the final version. They are just used as debug.
Do what we do with wall roughness and do it in the same place (computewalldistance and store in CPoint)
Ok, I think I managed to add it to the ComputeWallDistance function. I tested it on a 2D cylinder and it works just fine. However, when I use it on a profile with a sharp trailing edge it gives me strange results on the region behind the TE.
Cylinder:
Profile:
I guess it is intrinsic within the computation of the wall distances.
My guess is that the closest element for those regions is somewhere on the trailing edge and the normals there change very quickly.
Yeah, I do not think that it is solvable. Plus, I do not think that it will affect the solution either.
I am sorry for leaving this hanging. I am currently back on working on it.
These are the results on the Eppler E367 case with the new SLM model implemented and with three different correlation functions.
Using the L2Roe scheme
Using the Roe scheme
I will update the branch to the last develop commit and proceed from there.
EDIT: I think this one is too far behind with respect to the develop. Should I create another branch, make the changes there and then remove this one?
@rois1995 I'd just merge it with develop and have a look at the conflicts in vscode. It's probably just some lines that have moved around.
The problem is that I am behind more than 1100 commits. I have already created another branch starting from the current develop and I am running the test cases from the paper in the description. I may be able to merge the new branch into this one and then I'll be on par with the develop, right?