CFD Online Discussion Forums - decomposePar for custom solvers and boundary conditions

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)

- - decomposePar for custom solvers and boundary conditions (https://www.cfd-online.com/Forums/openfoam-programming-development/161893-decomposepar-custom-solvers-boundary-conditions.html)

decomposePar for custom solvers and boundary conditions

dear foamers,

I am grateful that you are interested in parallel computing and the decomposePar utility. I now encounter 2 problems when parallelizing mySlover:

(1) the custom boundary conditions. In the 0 or latestTime directory, one of the patch is as follows (before decomposePar):

Code:

myPatchName

{

    type    myBC;  // does decomposePar know myBC after its compilation?

    phi      phi;

    rho      rho;

    volumeFlux 100;

    value   nonuniform List<vector> 2((0.6 -0.7 0) (0.1 -0.2 0));

}

after decomposePar, in processor0 directory it becomes:

Code:

myPatchName

{

    type    myBC;  

    phi      phi;

    rho      rho;

    volumeFlux 0; // myPatch is indeed in the computational domain of processor0. why becomes 0???

    value   nonuniform List<vector> 2((0.6 -0.7 0) (0.1 -0.2 0));

}

in other processor* directories that do not contain this patch, give:

Code:

{

    type    myBC;  

    phi      phi;

    rho      rho;

    volumeFlux 0; // myPatch is not in this computational domain

    value   nonuniform 0(); // myPatch is not in this computational domain

}

after some time steps, in processor0 directory it gives:

Code:

myPatchName

{

    type    myBC;  

    phi      phi;

    rho      rho;

    volumeFlux 99.5; // this is normal

    value   nonuniform List<vector> 2((0.4 -0.5 0) (0.4 -0.5 0));

}

however after reconstuctPar, in the corresponding time folder gives:

Code:

myPatchName

{

    type    myBC;  

    phi      phi;

    rho      rho;

    volumeFlux 0;  // why 0??? shouldn't it be 99.5???

    value   nonuniform List<vector> 2((0.4 -0.5 0) (0.4 -0.5 0)); // this is normal

}

why the decomposePar and reconstructPar could not give right volumeFlux values? or i do something wrong? the current results mean that I must check the volumeFlux and the value in different directories. Is this normal or I've missed something?

(2) as you may have known, the above is for the 2D case. while mySolver is the one that coupling 1D and 2D computation. So should I only make the 2D computing parallelizable or both the 1D and 2D? and if possible, how could i make the implementation?

I am very appreciated if someone understands my problem and kindly gives some hints. and also, feel free to remedy my mistakes.
thanks a lot!

/karelke

Quick answers:

For the first issue, without seeing the source code, the best I can do is suggest that you take a better look at OpenFOAM's own boundary conditions for ideas on how these variables are handled in the constructors and in the "write" method. In addition, see this post for more ideas: http://www.cfd-online.com/Forums/ope...tml#post567594 - post #8

For the second issue, I can't figure out what you're asking from your description :( Please provide more details.

Quote:

Originally Posted by wyldckat (Post 571128)

thanks very much for your reply and I am really sorry for the unclarified problem.

for the first issue, myBC is attached.
for the second one, i mean that the 1D solver is totally user-developed. its framework is not exactly confirm to the OF convention, especially for the 1D mesh and solution schemes. so I feel quit difficult to make my coupled solver parallelizable. besides, I think that the 1D calculation is not very time-consuming. so is it possible to only parallel computing the 2D problem? and how this will effect the 1D solution?
hope i've made that clear. thanks for your attention.

Quick answers:

Quote:

Originally Posted by cfdopenfoam (Post 571133)

for the first issue, myBC is attached.

You have this constructor that is incorrect:

Code:

timeVaryingVolumeFluxInletDPUWFvPatchVectorField::

timeVaryingVolumeFluxInletDPUWFvPatchVectorField

(

    const fvPatch& p,

    const DimensionedField<vector, volMesh>& iF,

    const dictionary& dict

)

:

    fixedValueFvPatchField<vector>(p, iF, dict),

    timeDataFileName_(fileName(dict.lookup("timeDataFileName")).expand()),

    timeDataPtr_(NULL),

    volumeFlux_(0),

    phiName_("phi"),

    rhoName_("rho")

{

    if (dict.found("phi"))

    {

        dict.lookup("phi") >> phiName_;

    }



    if (dict.found("rho"))

    {

        dict.lookup("rho") >> rhoName_;

    }    

}

It should be:

Code:

timeVaryingVolumeFluxInletDPUWFvPatchVectorField::

timeVaryingVolumeFluxInletDPUWFvPatchVectorField

(

    const fvPatch& p,

    const DimensionedField<vector, volMesh>& iF,

    const dictionary& dict

)

:

    fixedValueFvPatchField<vector>(p, iF, dict),

    timeDataFileName_(fileName(dict.lookup("timeDataFileName")).expand()),

    timeDataPtr_(NULL),

    volumeFlux_(readScalar(dict.lookup("volumeFlux"))),

    phiName_("phi"),

    rhoName_("rho")

{

    if (dict.found("phi"))

    {

        dict.lookup("phi") >> phiName_;

    }



    if (dict.found("rho"))

    {

        dict.lookup("rho") >> rhoName_;

    }    

}

Although I'm not 100% certain that this will fix the problem...

Quote:

Originally Posted by cfdopenfoam (Post 571133)

for the second one, i mean that the 1D solver is totally user-developed. its framework is not exactly confirm to the OF convention, especially for the 1D mesh and solution schemes. so I feel quit difficult to make my coupled solver parallelizable. besides, I think that the 1D calculation is not very time-consuming. so is it possible to only parallel computing the 2D problem? and how this will effect the 1D solution?
hope i've made that clear.

Ah, OK, now I understand what you mean.
OpenFOAM relies in using the boundary condition "empty" for neutralizing a direction. Therefore, if you have a 1D problem, then your mesh should only be 1 cell of width over 2 directions and on those directions you should use the "empty" boundary condition.
As for the equations, you should define them the same way as OpenFOAM does for other solvers.

As for coupling... it depends on the type of coupling you're trying to do. For example, "chtMultiRegionFoam" is a complex solver that serves as an example on how OpenFOAM and handle coupling between semi-independent mesh regions. But there is also the coupling that can be done at the matrix solver level: http://www.openfoam.org/version2.2.0/matrix-solvers.php

Quote:

Originally Posted by wyldckat (Post 571139)

Quick answers:

You have this constructor that is incorrect:

thanks very much! your directions exactly fix the problem. but i wrote as:

Code:

timeVaryingVolumeFluxInletDPUWFvPatchVectorField::

timeVaryingVolumeFluxInletDPUWFvPatchVectorField

(

    const fvPatch& p,

    const DimensionedField<vector, volMesh>& iF,

    const dictionary& dict

)

:

    fixedValueFvPatchField<vector>(p, iF, dict),

    timeDataFileName_(fileName(dict.lookup("timeDataFileName")).expand()),

    timeDataPtr_(NULL),

    volumeFlux_(0),

    phiName_("phi"),

    rhoName_("rho")

{

    if (dict.found("volumeFlux"))

    {

        dict.lookup("volumeFlux") >> volumeFlux_; // these fix the problem

    }



    if (dict.found("phi"))

    {

        dict.lookup("phi") >> phiName_;

    }



    if (dict.found("rho"))

    {

        dict.lookup("rho") >> rhoName_;

    }    

}

thank you for your valuable time and now what confuses me is another coding problem.
it seems that the setFields utility could make it. but is there more tips about this tool or other ways to do that? there is only one region in the tutorial interFoam.
thanks for your help and i hope i do not make personal foul.:)