[nmikhailov]

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

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

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;
}
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]

Originally Posted by nmikhailov

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

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

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;
}
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]

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]

Originally Posted by nmikhailov

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]

Originally Posted by gschaider

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!