CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)
-   -   [swak4Foam] funkySetFields: problem with processor boundary (https://www.cfd-online.com/Forums/openfoam-community-contributions/153007-funkysetfields-problem-processor-boundary.html)

nmikhailov May 14, 2015 17:40

funkySetFields: problem with processor boundary
 
Hi FOAMers!

I use funkySetFields (swakVersion: 0.3.1) for the decomposed case. Internal fields are set remarkably. But I am disturbed by the following problem with processor boundaries. For example, one can consider shockTube case:

for x \in [-5;0) T=348.432, p=1e5, U=0

for x \in [0;5] T=278.746, p=1e4, U=0

Mesh decomposition is done for 4 subdomains:
proc0: [-5;-2.5]
proc1: [-2.5;0]
proc2: [0;2.5]
proc3: [2.5;5]

funkySetFieldsDict contains

expressions
(
leftT
{
field T;
expression "348.432";
condition "pos().x<0";
keepPatches true;
}
rightT
{
field T;
expression "278.746";
condition "pos().x>=0";
keepPatches true;
}
leftP
{
field p;
expression "100000";
condition "pos().x<0";
keepPatches true;
}
rightP
{
field p;
expression "10000";
condition "pos().x>=0";
keepPatches true;
}
);

Run funkySetFields in parallel:
mpirun -np 4 funkySetFields -time 0 -parallel

The execution is successful. There are no warnings and errors.

So, we analyze result now. To start, processor0/0/T:

FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object T;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 0 1 0 0 0];

internalField uniform 348.432;

boundaryField
{
sides
{
type zeroGradient;
}
empty
{
type empty;
}
procBoundary0to1
{
type processor;
value uniform 278.746; :confused:
}
}

But T is still 348.432 in subdomain 1...

Similar, processor0/0/P:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [1 -1 -2 0 0 0 0];

internalField uniform 100000;

boundaryField
{
sides
{
type zeroGradient;
}
empty
{
type empty;
}
procBoundary0to1
{
type processor;
value uniform 10000; :confused:
}
}

P.procBoundary0to1 must be 100000.

Further, processor1/0/T:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object T;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 0 1 0 0 0];

internalField nonuniform List<scalar> 3(348.432 348.432 278.746);

boundaryField
{
sides
{
type zeroGradient;
}
empty
{
type empty;
}
procBoundary1to0
{
type processor;
value uniform 278.746; :confused:
}
procBoundary1to2
{
type processor;
value uniform 278.746;
}
}
T.procBoundary1to0 must be 348.432.

I hope, the problem is explained.

Does somebody know how to solve this problem ?

gschaider May 25, 2015 18:33

Quote:

Originally Posted by nmikhailov (Post 546367)
Hi FOAMers!

I use funkySetFields (swakVersion: 0.3.1) for the decomposed case. Internal fields are set remarkably. But I am disturbed by the following problem with processor boundaries. For example, one can consider shockTube case:

for x \in [-5;0) T=348.432, p=1e5, U=0

for x \in [0;5] T=278.746, p=1e4, U=0

Mesh decomposition is done for 4 subdomains:
proc0: [-5;-2.5]
proc1: [-2.5;0]
proc2: [0;2.5]
proc3: [2.5;5]

funkySetFieldsDict contains

expressions
(
leftT
{
field T;
expression "348.432";
condition "pos().x<0";
keepPatches true;
}
rightT
{
field T;
expression "278.746";
condition "pos().x>=0";
keepPatches true;
}
leftP
{
field p;
expression "100000";
condition "pos().x<0";
keepPatches true;
}
rightP
{
field p;
expression "10000";
condition "pos().x>=0";
keepPatches true;
}
);

Run funkySetFields in parallel:
mpirun -np 4 funkySetFields -time 0 -parallel

The execution is successful. There are no warnings and errors.

So, we analyze result now. To start, processor0/0/T:

FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object T;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 0 1 0 0 0];

internalField uniform 348.432;

boundaryField
{
sides
{
type zeroGradient;
}
empty
{
type empty;
}
procBoundary0to1
{
type processor;
value uniform 278.746; :confused:
}
}

But T is still 348.432 in subdomain 1...

Similar, processor0/0/P:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [1 -1 -2 0 0 0 0];

internalField uniform 100000;

boundaryField
{
sides
{
type zeroGradient;
}
empty
{
type empty;
}
procBoundary0to1
{
type processor;
value uniform 10000; :confused:
}
}

P.procBoundary0to1 must be 100000.

Further, processor1/0/T:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object T;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 0 1 0 0 0];

internalField nonuniform List<scalar> 3(348.432 348.432 278.746);

boundaryField
{
sides
{
type zeroGradient;
}
empty
{
type empty;
}
procBoundary1to0
{
type processor;
value uniform 278.746; :confused:
}
procBoundary1to2
{
type processor;
value uniform 278.746;
}
}
T.procBoundary1to0 must be 348.432.

I hope, the problem is explained.

Does somebody know how to solve this problem ?

Hm. The problem seems to be that after manipulating the internalField correctBoundaryConditions has to be called to propagate it to the the other processors. Seems that funkySetFields doesn't do that. Seems that this is as well a bug (in your case) as a feature (as this might make it fail if a boundary condition needs other fields and these fields are not there)

nmikhailov May 25, 2015 22:17

Thank you for the advice Bernhard!
At the moment I have added calls correctBoundaryConditions for required fields in "createFields" of the solver I am using. I have maked the comparison of solutions for two variants:
1. ...-> funkySetFields -> decomposePar->...
and
2. ..-> decomposePar -> funkySetFields ->...
Solutions are equal now!

gschaider May 26, 2015 10:13

Quote:

Originally Posted by nmikhailov (Post 547623)
Thank you for the advice Bernhard!
At the moment I have added calls correctBoundaryConditions for required fields in "createFields" of the solver I am using. I have maked the comparison of solutions for two variants:
1. ...-> funkySetFields -> decomposePar->...
and
2. ..-> decomposePar -> funkySetFields ->...
Solutions are equal now!

OK. I'll add an option to do that to FSF. But I won't do it automatically for the reasons given above

nmikhailov May 26, 2015 10:48

Quote:

Originally Posted by gschaider (Post 547706)
OK. I'll add an option to do that to FSF. But I won't do it automatically for the reasons given above

It's a good idea! Thank you Bernhard!


All times are GMT -4. The time now is 11:40.