Add wall functions

[petebachant]

I saw on the projects tab that there is a wall functions implementation 80% complete, but stalled. I was looking to help out a little on this project. What's left to be done?

[talbring]

Hi Pete,

we appreciate your help on that. I just updated the branch feature_Wall_Functions to be up-to-date with develop. The main routines dealing with the wall functions are in solver_direct_mean.cpp and solver_direct_turbulent.cpp. Maybe @economon can tell you what exactly is missing there.

Tim

[juanjosealonso]

Pete, Tim, I have had a long standing interest in getting this working and would be happy to help. The (partial) implementation that is there is already 3-4 years old, so it will have to be updated, but we can discuss some of the details of the implementation and how it can be done both more efficiently and for both compressible formulations and adaptive wall functions. We can start a thread separately (jjalonso@stanford.edu<mailto:jjalonso@stanford.edu>) and perhaps have a telecon to kick things off. My availability for this improves after the next 2 weeks. Best, Juan On Jun 7, 2017, at 1:19 PM, Tim Albring <notifications@github.com<mailto:notifications@github.com>> wrote: Hi Pete, we appreciate your help on that. I just updated the branch feature_Wall_Functions<https://github.com/su2code/SU2/tree/feature_Wall_Functions> to be up-to-date with develop. The main routines dealing with the wall functions are in solver_direct_mean.cpp<https://github.com/su2code/SU2/blob/feature_Wall_Functions/SU2_CFD/src/solver_direct_mean.cpp#L16612> and solver_direct_turbulent.cpp<https://github.com/su2code/SU2/blob/feature_Wall_Functions/SU2_CFD/src/solver_direct_turbulent.cpp#L2569>. Maybe @economon<https://github.com/economon> can tell you what exactly is missing there. Tim — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#399 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpSxOvHCOSUFKDoizjyvrHbgyXgZ-vVks5sBwW8gaJpZM4NvG6w>.

[petebachant]

We might as well keep the discussion going up here on GitHub in case anyone else wants to jump in. @talbring, @economon any information on what's left to be done would be very helpful!

[EduardoMolina]

Hi all, I am also very interested in this topic. Please let me know. Best Eduardo

…

On 7 Jun 2017, at 18:59, Pete Bachant ***@***.***> wrote: We might as well keep the discussion going up here on GitHub in case anyone else wants to jump in. @talbring <https://github.com/talbring>, @economon <https://github.com/economon> any information on what's left to be done would be very helpful! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#399 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJVmCWNF7ouj2f2rIchhEKj1mqK4A3iVks5sB0eKgaJpZM4NvG6w>.

[economon]

Hi all,

Yes, it would be wonderful to get this feature completed. I had started this a couple of years ago, but never quite got around to finishing (too many fun things to work on!). I was following this paper, which should be a straightforward implementation for us, as FUN3D has a very similar structure:

Jan-Renee Carlson, Veer Vatsa, and Jeffery A. White. "Node-Centered Wall Function Models for the Unstructured FLow Code Fun3D", 22nd AIAA Computational Fluid Dynamics Conference, AIAA AVIATION Forum, AIAA 2015-2758, https://doi.org/10.2514/6.2015-2758

The key changes can be found in the following locations:

• CNSSolver::Compute_Wall_Functions_Mean() routine in solver_direct_mean.cpp - computes and stores an updated wall shear stress based on the chosen wall model
• CTurbSASolver::Compute_Wall_Functions() routine in solver_direct_turbulent.cpp - computes the eddy visc/nu tilde needed near the wall based on the model
• CNumerics::GetViscousProjFlux() in numerics_structure.cpp - computes the viscous flux between two nodes and will make an adjustment near the wall when the model is active
• CNumerics::GetViscousProjJacs() in numerics_structure.cpp - this part isn’t quite finished yet (something similar to the previous bullet).

Let's keep the discussion going,
Tom

[juanjosealonso]

Thanks Tom. And, as mentioned before, let’s have a bit of a discussion as to which wall functions formulations would make most sense to implement. I am pretty sure that we can create a generic implementation that can then be used for standard wall functions, but also for adaptive wall functions (see Medic, G., Kalitzin, G., et al., “Adaptive Wall Functions with Applications”, 2006), and even compressible/incompressible formulations. The adaptive wall function trick is quite useful as it makes the wall function implementation more robust to the varying y+ of the first cell of the surface of the geometry and lessens the burden during the grid generation stage. Formulations for S-A and k-w/SST are available. If anyone else is interested in participating, please let us know. Best, Juan On Jun 8, 2017, at 5:11 PM, Thomas D. Economon <notifications@github.com<mailto:notifications@github.com>> wrote: Hi all, Yes, it would be wonderful to get this feature completed. I had started this a couple of years ago, but never quite got around to finishing (too many fun things to work on!). I was following this paper, which should be a straightforward implementation for us, as FUN3D has a very similar structure: Jan-Renee Carlson, Veer Vatsa, and Jeffery A. White. "Node-Centered Wall Function Models for the Unstructured FLow Code Fun3D", 22nd AIAA Computational Fluid Dynamics Conference, AIAA AVIATION Forum, AIAA 2015-2758, https://doi.org/10.2514/6.2015-2758 The key changes can be found in the following locations: * CNSSolver::Compute_Wall_Functions_Mean() routine in solver_direct_mean.cpp - computes and stores an updated wall shear stress based on the chosen wall model * CTurbSASolver::Compute_Wall_Functions() routine in solver_direct_turbulent.cpp - computes the eddy visc/nu tilde needed near the wall based on the model * CNumerics::GetViscousProjFlux() in numerics_structure.cpp - computes the viscous flux between two nodes and will make an adjustment near the wall when the model is active * CNumerics::GetViscousProjJacs() in numerics_structure.cpp - this part isn’t quite finished yet (something similar to the previous bullet). Let's keep the discussion going, Tom — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#399 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpSxEMtW6EqpjBFJOTo8mRqxMFvvf4uks5sCI2zgaJpZM4NvG6w>.

[vdweide]

Juan, all,

The adaptive wall function formulation as described in the paper of Medic et al. has two serious issues. First, the convergence stalls after three orders of magnitude or so and second it only works with an upwind discretization of the inviscid fluxes. For some reason JST type of schemes gave rather poor results. In order to have a reliable implementation, both issues need to be addressed. Unfortunately, we never did.

Edwin

[erangit]

Hi all May I just add to Edwin comment: some of you have seen the tests that I made with SUmb (structured mesh code) using the adaptive WF: Results using the JST scheme were definitely off, while upwind +WF converged reasonably to wall-resolved results. Naturally this conclusion is strongly coupled with the specific discretization and implementation so it might not apply to a SU2 implementation. I suggest to keep working on the Carlson formulation (due to FUN3D-SU2 similarities mentioned above) and hopefully extend it to adaptive WF as a second step. I'll be happy to be on board of his effort. Best regards, Eran

…

On Fri, Jun 9, 2017 at 7:49 AM, Edwin van der Weide < ***@***.***> wrote: Juan, all, The adaptive wall function formulation as described in the paper of Medic et al. has two serious issues. First, the convergence stalls after three orders of magnitude or so and second it only works with an upwind discretization of the inviscid fluxes. For some reason JST type of schemes gave rather poor results. In order to have a reliable implementation, both issues need to be addressed. Unfortunately, we never did. Edwin — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#399 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APKNmwNgNVmXDYW_tqtQzvpDvxGe4OeLks5sCM7ugaJpZM4NvG6w> .

[petebachant]

Any ideas on a good test case(s) to ensure the implementation is correct? Maybe the RANS flat plate case at one Re that puts us in the wall-resolved regime, one with y+ ~10, and one with y+ ~ 50? I haven't taken a look at that particular case--just wondering if it might work.

[vdweide]

How do you specify that wall functions have to be used? Is there a general boolean flag, e.g. UseWallFunctions, or is it organized per marker? Is there an example of a cfg file how this is done? The reason for asking is that for WM-LES for the high order solver we need the same info and it would make sense to do the specification identically, if possible.

[economon]

@petebachant: the paper that I linked earlier on this thread had some fairly simple examples similar to the one you propose.. different flat plates and so on with varying y^+. You can likely reuse the grid(s) in the TestCases repo.

@vdweide: it was very simple in this first implementation. It checks for a single boolean for whether or not to apply wall functions (WALL_FUNCTIONS= YES or NO,

SU2/SU2_CFD/src/solver_direct_mean.cpp

Line 15339 in 43b8a40

if (config->GetWall_Functions() && config->GetExtIter() > 0)

), and then assumes they should be applied to all no-slip walls (heat flux or isothermal,

SU2/SU2_CFD/src/solver_direct_mean.cpp

Line 16653 in 43b8a40

if ((config->GetMarker_All_KindBC(iMarker) == HEAT_FLUX) ||

). This could of course be made more specific for individual markers using a config structure like MARKER_MONITORING to list them, or by making a dedicated BC type for it potentially.

[juanjosealonso]

All, Regarding the wall function specification, if we are going to settle on a standard way that could work for both the FV and DG-FEM solvers, it might be good to think about some modifiers that can later allow for a generality of approaches. We can make a distinction between wall functions and wall models, but this is subject to discussion…in essence both are performing similar duties, but people should express their opinions. With that said, how about a boolean such as USE_WALL_FUNCTIONS / USE_WALL_MODEL (YES or NO) with an optional argument WALL_FUNCTION_TYPE / WALL_MODEL_TYPE that can taken one of many pre-specified values that can be added as these options are developed and tested? Certainly options like STANDARD_WALL_FUNCTION, ADAPTIVE_WALL_FUNCTION, SCALABLE_WALL_FUNCTION, compressible and incompressible versions, and even EQUILIBRIUM_WALL_MODEL and NONEQUILIBRIUM_WALL_MODEL are things that are likely to be in the code in the near future. Thoughts? Juan On Sep 5, 2017, at 2:27 PM, Thomas D. Economon <notifications@github.com<mailto:notifications@github.com>> wrote: @petebachant<https://github.com/petebachant>: the paper that I linked earlier on this thread had some fairly simple examples similar to the one you propose.. different flat plates and so on with varying y^+. You can likely reuse the grid(s) in the TestCases repo. @vdweide<https://github.com/vdweide>: it was very simple in this first implementation. It checks for a single boolean for whether or not to apply wall functions (WALL_FUNCTIONS= YES or NO, https://github.com/su2code/SU2/blob/43b8a4015c4b09b01d78e4243d32011c663c2b70/SU2_CFD/src/solver_direct_mean.cpp#L15339), and then assumes they should be applied to all no-slip walls (heat flux or isothermal, https://github.com/su2code/SU2/blob/43b8a4015c4b09b01d78e4243d32011c663c2b70/SU2_CFD/src/solver_direct_mean.cpp#L16653). This could of course be made more specific for individual markers using a config structure like MARKER_MONITORING to list them, or by making a dedicated BC type for it potentially. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#399 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpSxJUhyEBSuSzHV1a7BZM_Frxbtb5sks5sfbzUgaJpZM4NvG6w>.

[vdweide]

Juan,

I think that having the flexibility to apply wall functions on only a subset of the viscous wall boundaries would be useful. E.g., if you are interested in a wing, you can apply integration to the wall there, but apply wall functions on the fuselage. My preference would be to have a dedicated BC type for that, i.e. Tom's second suggestion.

Apart from this, we can have the different wall model types as a single input parameter, i.e. you apply the same wall model type for all viscous boundaries. Or would you like to have the flexibility to specify this as well per individual marker?

Edwin

[juanjosealonso]

Edwin, I think it is a good idea to be able to have some level of control over the application of the wall functions on a marker-by-marker basis: as you say, it would be fairly common to have a wing marker where integration to the wall makes sense and a fuselage marker where wall functions (or even an inviscid BC) is the right thing to do. So let’s indeed do something like what Tom suggests (in the spirit of MARKER_MONITORING) so that one can control which markers get wall functions applied. If a list of markers is not specified in the config file, the default behavior should be that all no-slip walls get wall function BCs. If a list of markers is specified, then those and only those markers listed get wall function Bfs (with the others getting integration to the wall treatment). Now, what you point out in the second half of your message is the ultimate in flexibility: not only specifying wall functions in a subset of the no-slip wall markers, but also allowing for different kinds of wall functions to be used in those markers. I imagine that this would be a seldom used capability…but someone out there might have the need. I guess it does not seem to me that the coding of the most flexible logic is that much more complicated, so we may as well do that. If you guys think it is too complicated, the advertised options in the config file can allow some simpler behavior. My two cents, Juan On Sep 5, 2017, at 9:58 PM, Edwin van der Weide <notifications@github.com<mailto:notifications@github.com>> wrote: Juan, I think that having the flexibility to apply wall functions on only a subset of the viscous wall boundaries would be useful. E.g., if you are interested in a wing, you can apply integration to the wall there, but apply wall functions on the fuselage. My preference would be to have a dedicated BC type for that, i.e. Tom's second suggestion. Apart from this, we can have the different wall model types as a single input parameter, i.e. you apply the same wall model type for all viscous boundaries. Or would you like to have the flexibility to specify this as well per individual marker? Edwin — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#399 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpSxOEhKLW_U0n9PDoz5m6cJoCScV3_ks5sfiZdgaJpZM4NvG6w>.