Skip to content

Conversation

@koodlyakshay
Copy link
Member

@koodlyakshay koodlyakshay commented Feb 14, 2020

Proposed Changes

This PR is about the implementation of a rough wall boundary condition for SA and SST models. A given realistic roughness distribution must be first converted to an "equivalent sand grain roughness" height and specified as an input.

For the SA turbulence model, the roughness boundary condition is based on:

Aupoix, B. and Spalart, P. R., "Extensions of the Spalart-Allmaras Turbulence Model to Account for Wall Roughness," International Journal of Heat and Fluid Flow, Vol. 24, 2003, pp. 454-462.

Very briefly, the new model assumes there is a "virtual wall" located on top of the roughness elements and thus the distance to nearest wall is modified for all points based on the specified sand grain roughness. Additionally, the boundary condition at the wall is now not set to zero but a mixed condition (robin BC) is applied allowing for a non-zero eddy viscosity at the wall. More information is also available here

For the SST model, the roughness boundary condition is based on:

Wilcox, D.C Turbulence Modeling for CFD., 1998 and 2006, DWC Industries

There are two suggestions (first in the 2nd edition and a corrected version in the 3rd edition). I have implemented the latest one and commented the old one. There have been numerous papers about some limitations of these models themselves however. The modification consists of changing the omega boundary condition at the wall to a different value based on local quantities.

This PR introduces two extra config options - one to specify whether a wall is rough or not and another to specify the sand grain roughness height for each of them.

WALL_TYPE = SMOOTH/ROUGH
WALL_ROUGHNESS = <array of doubles>

By default all walls are smooth. If neither option is present in the config file, smooth walls are assumed everywhere. However, if there are multiple walls some rough, some smooth, they need to be listed (similar to INLET TYPE) in the order they appear in the MARKER_HEATFLUX definition. I have attached some examples here.

  1. Flatplate
    Here is the input file turb_flatplate_v7_cfg.txt,

The meshes can be found in TestCases/rans/flatplate or the NASA TMR database. Here are the results with both SA and SST
yplus_vs_uplus_sa_comparison

Here I am plotting the non-dimensionalised velocity u^+ against y^+. The clean results give fairly good agreement and we can see some over prediction in velocity shifts. This was also reported elsewhere

yplus_vs_uplus_sst_comparison

The same plot for SST. The results are not quite as good as SA in general, but I expected that considering some limitations reported in the literature (ex a min y^+ ~ 0.01 and so on).

Here is a comparison against experimental data by Blanchard (1977)
blanchard_compariosn

Once again, the SA roughness model does fairly well as opposed to the SST.

  1. Airfoils

If only a part of the wall is rough, as is the case on airfoils with corrosion for ex, we can split the marker definition as follows:

MARKER_HEATFLUX= (wall1, hf1, wall2, hf2 ...)
WALL_TYPE= SMOOTH,ROUGH,...
WALL_ROUGHNESS= 0.0, k1...

In case there is even a single rough wall, the WALL_TYPE option must specified for all the markers and WALL_ROUGHNESS set to 0.0 for smooth walls and the desired value for rough walls.
Sample input file for airfoil with smooth and rough walls. The airfoil used here is the NACA 622215 and I can send the mesh and experimental data in case anyone is interested.

Additional notes

Modification of wall distance computation required some changes to the ADT routines and subsequently to some FEM stuff as well. To modify the wall distance with roughness, I needed to know which marker was the closest wall and add the corresponding roughness. However, I wasn't sure how to properly do this in MPI. My solution was to pass the marker roughness information to the ADT class itself. This meant I had to add a dummy argument whenever the corresponding ADT classes were called elsewhere. Just to clarify, the modification is only in CADTElem class constructor and ComputeWallDistance routines. I hope this will not be a problem. I made this as a draft PR in case there are some issues with this. Also, if there are any issues with how the config file is changed, I can update that as well. I haven't modified the config_template for this yet.

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.

  • I am submitting my contribution to the develop branch.
  • My contribution generates no new compiler warnings (try with the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags).
  • My contribution is commented and consistent with SU2 style.
  • 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.

@pr-triage pr-triage bot added the PR: draft label Feb 14, 2020
@koodlyakshay koodlyakshay marked this pull request as ready for review February 26, 2020 10:44
@pcarruscag
Copy link
Member

Let me know if you need any help merging with develop @koodlyakshay, I had a quick look and it seems to be mostly a matter of copy pasting the new numerics options you added into the split files introduced in #861.

Copy link
Member

@pcarruscag pcarruscag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few comments based on aforementioned quick scroll through.

@koodlyakshay
Copy link
Member Author

Thanks for the comments @pcarruscag. I fixed them. I will work on merging with develop soon.

Copy link
Member

@talbring talbring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @koodlyakshay ! I just have some small comments below.

Copy link
Member

@pcarruscag pcarruscag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few more comments here and there as I dive into the nitty-gritty stuff.

@koodlyakshay
Copy link
Member Author

@pcarruscag thanks for the comments. I have fixed most of them I think.

In general, I think the PR is ready to be reviewed. I will think of a decent test case and add it soon.

Copy link
Member

@pcarruscag pcarruscag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM, just please have a look at the 4 variables that are possibly not being de-allocated (deleted) and revert travis.yml.


inline void CBaseMPIWrapper::Allgatherv(void *sendbuf, int sendcnt, Datatype sendtype,
void *recvbuf, int recvcnt, int *displs, Datatype recvtype, Comm comm){
void *recvbuf, int *recvcnt, int *displs, Datatype recvtype, Comm comm){
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the problem, the signature was incorrect, I've had some issues (weird segfaults) in the past with AD and allgatherv by the way... not because of this problem, and maybe it was my fault... But anyway just something to keep in the back of your mind if it causes you problems too.

@koodlyakshay
Copy link
Member Author

Thanks for the fix @pcarruscag.

@koodlyakshay
Copy link
Member Author

Can I merge this one?

@koodlyakshay koodlyakshay merged commit 1d8058e into develop Aug 3, 2020
@koodlyakshay koodlyakshay deleted the feature_roughwall branch August 3, 2020 10:26
@Lucas-Lucatelli
Copy link

Hello everyone. I ran simulations with the file “turb_flatplate_v7_cfg.txt”, but the results obtained do not converge with those presented in Blanchard's Figure of numerical results and experiments. I also ran simulations with different values of speed and roughness, but the results did not converge either. Could you please help me? Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants