CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Post-Processing

Difference in calculating div(U*U) swak4FOAM vs. OpenFOAM codedFunctionObject

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By gschaider
  • 1 Post By gschaider

Reply
 
LinkBack Thread Tools Display Modes
Old   September 29, 2013, 06:49
Default Difference in calculating div(U*U) swak4FOAM vs. OpenFOAM codedFunctionObject
  #1
New Member
 
Join Date: Jul 2012
Posts: 4
Rep Power: 4
polo is on a distinguished road
Dear all,

OpenFoam Version: 2.2.1 (newest Release) and 2.2.x
swak4FOAM Version 0.2.4 Install from this post #8 Swak4FOAM 0.2.3 / OF2.2.x installation error

the zip Archive ...

swak is working the way it should I think, I can calculate all fields I want, but the following problem I have:

I calculate div(U*U) via the new codedFunctionObject in OpenFOAM and the same I do with swak, but the Results are different!? I don't know why??

I split the Problem and what I can figure out is, that the div operation seems to be make the difference...

so calculate U*U via codedFunctionObject gives the same values as swak
also mag(U*U), grad(U*U), curl(U*U) gives same values for both calculation methods.

BUT if i do div(U*U) and what I want finally to do div(div(U*U)) the values are different between codedFunctionObject and swak?

Have anybody an explanation? What could be the Problem? I've read the swak Reference guide and also the README, but I can't figure out what I do wrong?

One other question, is swak searching for div Scheme in fvScheme?? I'm not absolutly sure but I recognize that if I calculate div(U*U) via codedFunctionObject and have in my fvScheme div(U*U) Gauss linear; it changed if I place there div(U*U) Gauss cubic;

Finally question: which values should I trust? values (field) I get from codedFunctionObject or from swak?

this is my swak expression

Code:
DivdivUU
           {
                type expressionField;
                outputControl   timeStep; // timeStep or outputTime
                outputInterval 1;
                fieldName DivdivUU_swak;

                expression "div(div(U*U))";
                autowrite  true;

           }
Thanks for your assistance!

Best Regrads!

Ps: I prefere to use swak, because its easier for me in use!
polo is offline   Reply With Quote

Old   September 29, 2013, 18:19
Default
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by polo View Post
Dear all,

OpenFoam Version: 2.2.1 (newest Release) and 2.2.x
swak4FOAM Version 0.2.4 Install from this post #8 Swak4FOAM 0.2.3 / OF2.2.x installation error

the zip Archive ...

swak is working the way it should I think, I can calculate all fields I want, but the following problem I have:

I calculate div(U*U) via the new codedFunctionObject in OpenFOAM and the same I do with swak, but the Results are different!? I don't know why??

I split the Problem and what I can figure out is, that the div operation seems to be make the difference...

so calculate U*U via codedFunctionObject gives the same values as swak
also mag(U*U), grad(U*U), curl(U*U) gives same values for both calculation methods.

BUT if i do div(U*U) and what I want finally to do div(div(U*U)) the values are different between codedFunctionObject and swak?

Have anybody an explanation? What could be the Problem? I've read the swak Reference guide and also the README, but I can't figure out what I do wrong?

One other question, is swak searching for div Scheme in fvScheme?? I'm not absolutly sure but I recognize that if I calculate div(U*U) via codedFunctionObject and have in my fvScheme div(U*U) Gauss linear; it changed if I place there div(U*U) Gauss cubic;

Finally question: which values should I trust? values (field) I get from codedFunctionObject or from swak?

this is my swak expression

Code:
DivdivUU
           {
                type expressionField;
                outputControl   timeStep; // timeStep or outputTime
                outputInterval 1;
                fieldName DivdivUU_swak;

                expression "div(div(U*U))";
                autowrite  true;

           }
Thanks for your assistance!

Best Regrads!

Ps: I prefere to use swak, because its easier for me in use!
Could you tell me HOW the div-fields differ? swak uses the standard fvc::div-function (so it picks up the scheme to use from fvSchemes - but you could check that with the banana-trick).
immortality likes this.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   September 30, 2013, 02:15
Default
  #3
New Member
 
Join Date: Jul 2012
Posts: 4
Rep Power: 4
polo is on a distinguished road
Dear Bernhard,

thanks for your fast reply! Here are some screenshots taken from paraview!

swak_vs_codedFunctionObject1_cubic.jpg

swak_vs_codedFunctionObject2_cubic.jpg

swak_vs_codedFunctionObject2.jpg

swak_vs_codedFunctionObject1.jpg

For one timestep I used fvScheme default Gauss linear and for the next timestep I used default Gauss cubic, so I think rhe schemes should be the same for codedFunctionObject and for swak.

So you see Tensor U*U has the same range for the codedFunctionObject and for swak, so I think up to this calculation step everything is okay.

But divUU_coded and divUU_swak are different apart from the fourth value in the ranges!

Do you have any idea why? If you need more information let me know!

Thanks!

Regards!

Ps: I've make an additional Test (see in the pictures), LaplaceP (fvc::laplacian(p)) has the same ranges for the codedFunctionObject and for swak! But I wonder because in my fvSchemes there stands:

laplacianSchemes
{
default Gauss linear limited corrected 0.333; --> I think this is used by swak? or?
laplacian(p) Gauss linear corrected; --> and this is used by coded function object
}
polo is offline   Reply With Quote

Old   September 30, 2013, 07:53
Default
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by polo View Post
Dear Bernhard,

thanks for your fast reply! Here are some screenshots taken from paraview!

Attachment 25691

Attachment 25692

Attachment 25693

Attachment 25694

For one timestep I used fvScheme default Gauss linear and for the next timestep I used default Gauss cubic, so I think rhe schemes should be the same for codedFunctionObject and for swak.

So you see Tensor U*U has the same range for the codedFunctionObject and for swak, so I think up to this calculation step everything is okay.

But divUU_coded and divUU_swak are different apart from the fourth value in the ranges!

Do you have any idea why? If you need more information let me know!

Thanks!

Regards!

Ps: I've make an additional Test (see in the pictures), LaplaceP (fvc::laplacian(p)) has the same ranges for the codedFunctionObject and for swak! But I wonder because in my fvSchemes there stands:

laplacianSchemes
{
default Gauss linear limited corrected 0.333; --> I think this is used by swak? or?
laplacian(p) Gauss linear corrected; --> and this is used by coded function object
}
OK. The divergences are the same order of magnitude so swak can't be completely wrong. Could you have a look WHERE they differ (either by using the Paraview calculator or with funkySetFields). My guess is that this is happening near boundaries as for technical reasons swak replaces these with zeroGradients (which can make a difference for the divergence)

To find out which discretization is actually used: replace default with something arbitrary (usually banana) and see with which key it fails.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   October 1, 2013, 03:19
Default
  #5
New Member
 
Join Date: Jul 2012
Posts: 4
Rep Power: 4
polo is on a distinguished road
Thanks for your answer and sorry for my late reply!

Yes it is not completly different, but I want to understand what makes the difference, because the fields we are using for a then later ongoing calculation!

I looked into the files that are written out by the codedFunctionObject and by swak and here you see the differences:

codedFunctionObject File tensUU


boundaryField
{
wall
{
type calculated;
value uniform (0 0 0 0 0 0 0 0 0);
}
... every wall like the above wall uniform 0 0 0 ....

inlet
{
type calculated;
value nonuniform List<tensor>
13321
(
(0.176040747529 -0.000172424942491 3.30256905969e-05 -0.000172424942491 1.68883404611e-07 -3.23473564036e-08 3.30256905969e-05 -3.23473564036e-08 6.19570329431e-09)

outlet
{
type calculated;
value nonuniform List<tensor>
146138
(
(5.81950146638e-13 5.13713596236e-13 5.98065733989e-13 5.13713596236e-13 4.53478120905e-13 5.27939550782e-13 5.98065733989e-13 5.27939550782e-13 6.14627600386e-13)

swak File tensUU

inlet
{
type calculated;
value nonuniform List<tensor>
13321
(
(0.171631668422 -0.00585061097536 -0.00676827682281 -0.00585061097536 0.000199436672146 0.000230718229496 -0.00676827682281 0.000230718229496 0.000266906285835)

}
outlet
{
type calculated;
value nonuniform List<tensor>
146138
(
(5.81950146638e-13 5.13713596236e-13 5.98065733989e-13 5.13713596236e-13 4.53478120905e-13 5.27939550782e-13 5.98065733989e-13 5.27939550782e-13 6.14627600386e-13)

boundaryField
{
wall
{
type calculated;
value nonuniform List<tensor> 2
((0.0854811931117 -1.1105359974e-05 0.00014444790056 -1.1105359974e-05 1.44276203527e-09 -1.87660685914e-08 0.00014444790056 -1.87660685914e-08 2.44091070992e-07) (0.121202389929 -0.00101921324767 3.58167339671e-06 -0.00101921324767 8.57075215141e-06 -3.01189520844e-08 3.58167339671e-06 -3.01189520844e-08 1.05842668022e-10));
}
wall2
{
type calculated;
value nonuniform List<tensor>
79021
(
(4.23017014356 1.52521594321 -11.0792111256 1.52521594321 0.549926739227 -3.99468316251 -11.0792111256 -3.99468316251 29.017489841)

... every wall have values!

So the range from coded_tensUU and swak_tensUU in paraview are the same, but the difference are at the walls! The codedFunctionObject have there no values, but swak have there values, so thats why I think we have a difference in swak output of div(UU) and also in div(div(UU)).

I also visulize it in Paraview:

mag(divUU_coded-divUU_swak) and I can see in the boundray layer, so at the walls the differnce occurs.

So I think I can't use swak for writing out div(div(UU)) or do you know what I can change to have no values for tensUU at my walls?

Thanks in advance!

Regards
polo is offline   Reply With Quote

Old   October 1, 2013, 08:46
Default
  #6
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by polo View Post
Thanks for your answer and sorry for my late reply!

Yes it is not completly different, but I want to understand what makes the difference, because the fields we are using for a then later ongoing calculation!

I looked into the files that are written out by the codedFunctionObject and by swak and here you see the differences:

codedFunctionObject File tensUU


boundaryField
{
wall
{
type calculated;
value uniform (0 0 0 0 0 0 0 0 0);
}
... every wall like the above wall uniform 0 0 0 ....

inlet
{
type calculated;
value nonuniform List<tensor>
13321
(
(0.176040747529 -0.000172424942491 3.30256905969e-05 -0.000172424942491 1.68883404611e-07 -3.23473564036e-08 3.30256905969e-05 -3.23473564036e-08 6.19570329431e-09)

outlet
{
type calculated;
value nonuniform List<tensor>
146138
(
(5.81950146638e-13 5.13713596236e-13 5.98065733989e-13 5.13713596236e-13 4.53478120905e-13 5.27939550782e-13 5.98065733989e-13 5.27939550782e-13 6.14627600386e-13)

swak File tensUU

inlet
{
type calculated;
value nonuniform List<tensor>
13321
(
(0.171631668422 -0.00585061097536 -0.00676827682281 -0.00585061097536 0.000199436672146 0.000230718229496 -0.00676827682281 0.000230718229496 0.000266906285835)

}
outlet
{
type calculated;
value nonuniform List<tensor>
146138
(
(5.81950146638e-13 5.13713596236e-13 5.98065733989e-13 5.13713596236e-13 4.53478120905e-13 5.27939550782e-13 5.98065733989e-13 5.27939550782e-13 6.14627600386e-13)

boundaryField
{
wall
{
type calculated;
value nonuniform List<tensor> 2
((0.0854811931117 -1.1105359974e-05 0.00014444790056 -1.1105359974e-05 1.44276203527e-09 -1.87660685914e-08 0.00014444790056 -1.87660685914e-08 2.44091070992e-07) (0.121202389929 -0.00101921324767 3.58167339671e-06 -0.00101921324767 8.57075215141e-06 -3.01189520844e-08 3.58167339671e-06 -3.01189520844e-08 1.05842668022e-10));
}
wall2
{
type calculated;
value nonuniform List<tensor>
79021
(
(4.23017014356 1.52521594321 -11.0792111256 1.52521594321 0.549926739227 -3.99468316251 -11.0792111256 -3.99468316251 29.017489841)

... every wall have values!

So the range from coded_tensUU and swak_tensUU in paraview are the same, but the difference are at the walls! The codedFunctionObject have there no values, but swak have there values, so thats why I think we have a difference in swak output of div(UU) and also in div(div(UU)).

I also visulize it in Paraview:

mag(divUU_coded-divUU_swak) and I can see in the boundray layer, so at the walls the differnce occurs.

So I think I can't use swak for writing out div(div(UU)) or do you know what I can change to have no values for tensUU at my walls?

Thanks in advance!

Regards
Currently the swak-Field-parser sets the calculated walls to the value of the inner cells. The decision for this was
a. usually the field parser is only concerned with the inner values
b. that arrangement proved to be the most stable (propagating the calculated values on the walls caused all kinds of errors that were hard to understand for the user. Mostly division by zero. "But my field is bigger than 0 everywhere. Why?" "Because of your boundary conditions")

divergence is one of the few places where a) is not true.

Changing the behaviour of this (for instance making it user-selectable) means changing some stuff at the core (and especially testing that it doesn't introduce problems for things that are currently working) and I don't see myself currently doing it now. But I accept patches (if they don't break anything). Or you hope that it becomes a problem for me. Then I might fix it.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   October 1, 2013, 09:23
Default
  #7
New Member
 
Join Date: Jul 2012
Posts: 4
Rep Power: 4
polo is on a distinguished road
okay, no problem then for "div" I use the coded function object and for other fields I use swak ;-)

Thank you very much for your time and explanation!

Ps: Let me know when it becomes a problem for you ;-)
polo is offline   Reply With Quote

Old   October 1, 2013, 10:22
Default
  #8
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by polo View Post
okay, no problem then for "div" I use the coded function object and for other fields I use swak ;-)
Of course one could argue that "my" way is better because due to the "zeroGradient" you exclude the influence of the boundary on the divergence.

BTW: the problem in your case is not so much the div as the calculation of U*U (that is where the U=0 on the wall got lost).

BTW2: if you're interested in comparing different discretization schemes you can have a look the swakFvcSchemesFunctionPlugins which defines a number of functions where you can specify the field to take the divergence of AND specify the scheme to use.

Quote:
Originally Posted by polo View Post
Thank you very much for your time and explanation!

Ps: Let me know when it becomes a problem for you ;-)
It will be in the README (when it is changed)
polo likes this.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Calculating pressure coefficient in OpenFoam mecbe2002 OpenFOAM 20 August 19, 2013 12:14
Cross-compiling OpenFOAM 1.7.0 on Linux for Windows 32 and 64bits with Mingw-w64 wyldckat OpenFOAM Announcements from Other Sources 3 September 8, 2010 06:25
Velocity spots in openFoam results Valle OpenFOAM Running, Solving & CFD 4 August 19, 2009 05:53
Modified OpenFOAM Forum Structure and New Mailing-List pete Site News & Announcements 0 June 29, 2009 05:56
How to update polyPatchbs localPoints liu OpenFOAM Running, Solving & CFD 6 December 30, 2005 18:27


All times are GMT -4. The time now is 23:56.