View Issue Details

IDProjectCategoryView StatusLast Update
0001788OpenFOAM[All Projects] Bugpublic2015-07-24 17:02
Reporteruser720Assigned Tohenry 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformUnixOSOtherOS Version(please specify)
Product Version 
Fixed in Version 
Summary0001788: SRFSimpleFoam uses Urel for turbulence model
DescriptionSRFSimpleFoam seems to use Urel for the turbulence model. Turbulence models like k-w-SST use a production term that is based on the gradient in the velocity. If modeling a quiescent flow using a rotating frame of reference, then the turbulence model will see a production based on the gradient in Urel = d(wr)/dr = w (omega), whereas in reality, there's no turbulence production.
Steps To ReproduceRun the SRFSimpleFoam tutorial case "mixer" with zero velocity for Urel and SRFVelocity BC for the innerWall.

    inlet
    {
        type SRFVelocity;
        inletValue uniform ( 0 0 0);
        relative no;
        value uniform ( 0 0 0 );
    }
    innerWall
    {
        type SRFVelocity;
        inletValue uniform ( 0 0 0 );
        relative no;
        value uniform ( 0 0 0 );
    }
TagsNo tags attached.

Activities

user720

2015-07-16 16:04

 

z0p1_k.jpg (75,034 bytes)
z0p1_k.jpg (75,034 bytes)

henry

2015-07-19 19:07

manager   ~0005101

Thanks for the bug-report. I have corrected this issue in both SRFSimpleFoam and SRFPimpleFoam in OpenFOAM-dev:

commit 162b6979165c7b0d8775c397311df7f778199f5b

Could you test this and let me know if it operates as you expect and then I will make the same changes to OpenFOAM-2.4.x

user720

2015-07-21 12:28

  ~0005109

Thanks. This doesn't work yet..looks like there's more to be done. The velocity passed into the turbulence->divDevReff is still Urel. Unfortunuately, if you change it to U, it doesn't go well with the rest of the equation as one can't add an fvMatrix of U with an fvMatrix of Urel. Any ideas?

henry

2015-07-21 12:39

manager   ~0005110

The argument to turbulence->divDevReff MUST be Urel as it MUST generated the stress for the Urel equation. What I have changed is the velocity provided to the turbulence model constructor which is then used to calculate the production term which should resolve the issue you raised in this bug-report.

user720

2015-07-21 13:16

  ~0005111

Thanks. This issue is resolved then. I'll file a different one for that issue.

henry

2015-07-23 23:24

manager   ~0005133

I have run various tests on this case and in order to get good convergence with zero velocity I needed to change the initialization and some of the boundary conditions. Also the errors for upwind are very large causing significant velocity; to resolve this I changed to linearUpwind. With these changes the quiescent flow is maintained and turbulence is not generated following the change to the turbulence model constructor already discussed.

In principle the divDevReff term should also be changed but the error from the use of Urel is VERY small unless there are steep gradients in the turbulence viscosity field so unless it can be demonstrated that a change to this term is necessesary I will leave it as it is.

user720

2015-07-24 15:42

  ~0005135

Last edited: 2015-07-24 15:43

View 2 revisions

Thanks. You're right. Unless, there are steep gradients in nuEff, the divDevReff term shouldn't be a big deal. I propose a higher order correction if it becomes necessary. One could declare a velocity field omegaCrossR that contains -SRF->U() and add this to the UrelEqn.

+ fvc::laplacian(turbulence->nuEff(), omegaCrossR) + fvc::div(turbulence->nuEff()*dev(T(fvc::grad(omegaCrossR))))

henry

2015-07-24 16:06

manager   ~0005136

I have also considered such an option but this simple form is only applicable to turbulence viscosity based models. To be general the correction would need to be built into the turbulence model hierarchy and specialized according to how the stress is evaluated. This in turn requires the turbulence models to know about the motion of the frame. We will consider such a generalization in the future.

Issue History

Date Modified Username Field Change
2015-07-16 16:04 user720 New Issue
2015-07-16 16:04 user720 File Added: z0p1_k.jpg
2015-07-19 19:07 henry Note Added: 0005101
2015-07-21 12:28 user720 Note Added: 0005109
2015-07-21 12:39 henry Note Added: 0005110
2015-07-21 13:16 user720 Note Added: 0005111
2015-07-23 23:24 henry Note Added: 0005133
2015-07-24 15:42 user720 Note Added: 0005135
2015-07-24 15:43 user720 Note Edited: 0005135 View Revisions
2015-07-24 16:06 henry Note Added: 0005136
2015-07-24 17:02 henry Status new => resolved
2015-07-24 17:02 henry Resolution open => fixed
2015-07-24 17:02 henry Assigned To => henry