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

Dear all,

OpenFoam Version: 2.2.1 (newest Release) and 2.2.x
swak4FOAM Version 0.2.4 Install from this post #8 http://www.cfd-online.com/Forums/openfoam-installation/118194-swak4foam-0-2-3-of2-2-x-installation-error.html#post434217

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

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).

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.

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.

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 ;-)

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.

It will be in the README (when it is changed)