View Issue Details

IDProjectCategoryView StatusLast Update
0000474OpenFOAMBugpublic2012-03-22 12:09
Reporteruser45Assigned Touser21 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformLinuxOSOpenSuseOS Version11.1
Summary0000474: iddesDelta in of v2.1.0
DescriptionI noticed that there is difference of difining IDDESDelta between OF v1.7.1 and v2.1.0.

Firstly, In V2.1.0, the faceToFaceMax (hwn in Shur et al, 2008) is defined as the wall normal component, (n), of the distance between the reference face centre (faceCentre[cFaces[0]]) and each face centre of the cell (faceCentreTwo). I think that this is only valid when the 'faceCentre' is the closest (or furthest) point from the wall among the other face centres . This is case (a) in the 1st page of the attachment.
Squares represent individual cells. n is the wall normal direction, black dot is the 'faceCentre[cFaces[0]]'. Unfortunately, case (b) happens in my channel mesh. So the 'faceCentre' is only a half of as it should be. I haven't tested with other meshes but case (b) does happen.

Secondly, hmax in 'maxDeltaxyz.C'. As far as I understood, the hmax has to be doubled as it did in 'IDDESDelta,C' from OF v1.7.1.

So when I tested the SpalartAllmarasIDDES in the channel flow (Re_tau=2000), I did get reasonable results with OF v1.7.1 but the results from v2.1.0 deviated from the DNS data. I attached the mean velocity profiles of the iddes channel flow in the 2nd page. I also tested corrected IDDES, i.e. simply doubled the hmax and hwn (faceToFacenMax), and it (see, v210_corrected) showed the same result as those with v1.7.1.
(resolutions of the channel flow are x+=200, y_min+=2, z+=100 in the stream, wall-normal and span directions. central difference scheme is used for the convection term.)

To sum up, is there any intention of the halved hwn (faceToFacenMax) in 'IDDESDelta.C' and hmax in 'maxDeltaxyz.C' (in v2.1.0) ? Or are these bug?
Regards
Yusik
TagsNo tags attached.

Activities

user45

2012-03-20 22:31

 

faceToFacenMax.pdf (70,164 bytes)

user21

2012-03-21 09:59

  ~0001157

I can not find the difference between 1.7.x and 2.1.x, this might be due that you're using 1.7.1 and not 1.7.x.

In case of polyhedral meshes it is easier to calculate the distance between the face centres and the cell centre. In the particular case of hexa you can just use the coeff for maxDeltaxyz to get the max(h) from face to face on the cell:

maxhxhyhzDeltaCoeffs
{
    deltaCoeff 2;
}

The same with IDDESDeltaCoeffs, you can use deltaCoeff_

IDDESDeltaCoeffs
{
     deltaCoeff 1;
     cw 0.15;
}

Regards

user45

2012-03-21 17:31

  ~0001159

hmax can be achieved by using
maxDeltaxyzCoeffs
{
    deltaCoeff 2;
}
in hex mesh.
But faceToFacenMax (hwn) is calculated by the face centre differences. Then
Is it possible that case (b) (in the attachment of the first report) can happen in hexa mesh? as I said in my channel mesh case,

faceCentre = mesh().faceCentres()[cFaces[0]];

is not the closest (or furthest) face like in case (b). Meaning faceToFacenMax is half of hwn in my channel (hexa) mesh. So do I need to doubled the faceToFacenMax as well? (case (b) happens all the cells in my case).

Correct me if I am wrong.
Thanks

user21

2012-03-22 10:59

  ~0001162

There was a bug. Now it should be fixed.
Thanks

Issue History

Date Modified Username Field Change
2012-03-20 22:31 user45 New Issue
2012-03-20 22:31 user45 File Added: faceToFacenMax.pdf
2012-03-21 09:59 user21 Note Added: 0001157
2012-03-21 17:31 user45 Note Added: 0001159
2012-03-22 10:59 user21 Note Added: 0001162
2012-03-22 12:08 user21 Assigned To => user21
2012-03-22 12:08 user21 Status new => assigned
2012-03-22 12:09 user21 Status assigned => resolved
2012-03-22 12:09 user21 Resolution open => fixed