BUG: extra nu term in kEpsilonPhitF's normalised wall-normal fluctuating velocity scale

Related to https://develop.openfoam.com/Community/Documentation/issues/94 @chi

changed due date to January 31, 2020

changed milestone to %v2006

added bug label

Though, ironically, this may also explain why we have obtained verification results better than those in the original paper for the same cases. Curious.

As suspected, including nu term thereat:

• provides higher resemblance particularly for the peak skin friction predictions in comparison to the benchmark datasets for the considered test cases,
• does not alter any pressure-related predictions (e.g. pressure coef).

The implementation of kEpsilonPhitF model was thoroughly verified by means of the following canonical flows: the smooth-wall plane channel flows (Reτ = 180,395,590, 800,5186; Re = 80 × 10^6, zero-pressure gradient turbulent flat plate, two-dimensional backward-facing step, two dimensional hill in a channel, and a DriverAer case.

Considering above, I will only provide an optional boolean to incorporate nu in Eq. 17 of the reference paper, with the default behaviour including the nu term.

If I understand correctly, by default the nu term is included in Eq. 17? Yet if this term is included there, the equation for

F

(18) needs to be adjusted accordingly otherwise the transformation given in (16) is not done properly and therefore the boundary condition

F

(at wall)=0 does not work anymore. With air flows the impact is maybe not that big but considering a fluid with higher molecular viscosity can cause stability issues.

To ensure backward-compatibility, we left the nu term included thereat by making it optional. Users can now turn it off or on as desired. As mentioned before, excluding nu leads to higher level of resemblance to the canonical benchmarks we have considered. I don't disagree with you regarding your remarks: you are right from the theoretical consistency. Yet practical perspective suggests otherwise, and we left the decision to the users by making the term optional.

If you disagree, please let me know. So that we can give a second thought on leaving nu included by default.

You probably mean, that by including

nu

the resemblance to the canonical benchmarks is better. Sure you are right the user can decide yet to be honest by default it would make sense to implement the model correctly. The idea of the

f

transformation was to improve the stability, if you have already a working simulation case set you could try switching the fluid to water or oil (there I would expect problems due to the increased viscosity) and see if the stability is still the same.

I completely agree with your line of reasoning. The only reason was to ensure backward-compatibility since the version including nu was released. I will update you after some internal discussion. Thank you.

mentioned in commit 6c12a2f9

mentioned in merge request !329 (merged)

mentioned in commit c234acf1

closed via merge request !329 (merged)

closed via commit c234acf1

mentioned in commit 835c392d