View Issue Details

IDProjectCategoryView StatusLast Update
0001771OpenFOAMBugpublic2015-10-22 10:29
Reporteruser1044Assigned Tohenry  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSCent OSOS Version6.4
Summary0001771: Parallel calculation of channel flow with the mapped inlet condition is violated.
DescriptionThe calculated mesh model has two cellZones, one cellZone is used to develop the channel flow continuously with the set of cyclic boundary conditions, the other cellZone is used to calculate an arbitrary flow field with the mapped inlet flow condition connected with the above channel.
The single-core calculation of the mesh model mentioned above with pimpleFoam is successful, but the parallel calculation of the same model is violated.
Please refer to the uploaded pdf file with some figures.
Steps To Reproduce1.Set the pressure gradient to the cellZone of ELEMENTS1 with cyclic boundary conditions in order to develop the channel flow as follows,
system/fvOptions
momentumSource
{
    type pressureGradientExplicitSource;
    active on;
    selectionMode cellZone;
    cellZone ELEMENTS1;
0/p,U
in_cyc
    {
        type cyclic;
    }
out_cyc
    {
        type cyclic;
    }
2.Set the mapped inlet condition of the other cellZone of ELEMENTS0 as follows,
constant/polyMesh/boundary
 MAPPED_INLET
    {
        type mappedPatch;
        inGroups 1(mappedPatch);
        sampleMode nearestCell;
        sampleRegion region0;
        samplePatch none;
        offsetMode uniform;
        offset (-1 0 0);
0/U
 MAPPED_INLET
    {
        type mapped;
        interpolationScheme cell;
        setAverage false;
        average (0 0 0);
        value uniform (0 0 0);
    }
3.Please download the case files compressed and splitted into tar.gz-* files.(cat constant.tar.gz-* > constant.tar.gz)
Additional InformationThe parallel calculation of the only cyclic cellZone with the same pressure gradient is successful.
Tagscyclic, decomposePar, fvOptions, mappedPatch, parallel, pressureGradientExplicitSource

Activities

user1044

2015-07-01 07:21

 

user1044

2015-07-01 07:27

 

user1044

2015-07-01 07:28

 

constant.tar.gz-aa (2,097,152 bytes)

user1044

2015-07-01 07:28

 

constant.tar.gz-ab (2,097,152 bytes)

user1044

2015-07-01 07:29

 

constant.tar.gz-ac (2,097,152 bytes)

user1044

2015-07-01 07:29

 

constant.tar.gz-ad (2,097,152 bytes)

user1044

2015-07-01 07:30

 

constant.tar.gz-ae (2,097,152 bytes)

user1044

2015-07-01 07:31

 

constant.tar.gz-af (2,097,152 bytes)

user1044

2015-07-01 07:31

 

constant.tar.gz-ag (2,097,152 bytes)

user1044

2015-07-01 07:32

 

constant.tar.gz-ah (2,097,152 bytes)

user1044

2015-07-01 07:33

 

constant.tar.gz-ai (2,097,152 bytes)

user1044

2015-07-01 07:33

 

constant.tar.gz-aj (387,824 bytes)

user4

2015-07-01 09:25

  ~0005028

Can you switch on the debug flag for mappedPatchBase? It will print out all the found locations:

            Info<< " " << sampleI << " coord:"<< samples[sampleI]
                << " found on processor:" << procI
                << " in local cell/face/point:" << localI
                << " with location:" << nearest[sampleI].first().rawPoint()
                << endl;

Can you check for a few that they are correct?

user1044

2015-07-01 09:45

  ~0005029

Unfortunately,I've not used any kind of debug flags of OpenFOAM, but If you tell me how to use it or show me the article on website, I won't hesitate to check the details.

user4

2015-07-01 09:49

  ~0005030

In your system/controlDict add

DebugSwitches
{
    mappedPatchBase 1;
}

(or add them to the section in the global etc/controlDict in the installation directory)

user1044

2015-07-01 10:35

  ~0005031

Last edited: 2015-07-01 10:43

I confirmed the correction of the mapping relation in the log file and MAPPED_INLET_mapped.obj, which say, for example, the point(-7 0.73 4.08) on MAPPED_INLET of ELEMENTS0 is mapped by the point(-7.91667 0.73 4.08) in ELEMENTS1 nearest to the offset point(-8 0.73 4.08).(I think) As you can see the correct velocity distribution of the parallel calculation result in the figure of the uploaded pdf, the mapping seems to have no problem. Remarkablly, we should pay attention to the corrupt pressure distribution, why are the reference pressure between cellZone:ELEMENTS0 and cellZone:ELEMENTS1 separated?
Conscientiously, I'll upload the log file and MAPPED_INLET_mapped.obj.
Thank you.

user1044

2015-07-01 10:36

 

log.tar.gz (96,753 bytes)

user1044

2015-07-15 03:20

 

nodeNo_ELEMENT0+ELEMENT1.png (182,527 bytes)   
nodeNo_ELEMENT0+ELEMENT1.png (182,527 bytes)   

user1044

2015-07-15 03:20

 

user1044

2015-07-15 03:22

 

user1044

2015-07-15 03:23

 

user1044

2015-07-15 03:41

  ~0005087

I doubted whether the decomposition of the separated calculation domain with the mapped interface is correct. I've uploaded some figures of cellDist of decomposePar in this time. I'd like you to pay attentions to the decomposition of the mapped interface, fig:nodeNo_ELEMENT0_inlet_side_mappedBC.png. Is this correct as the boundary condition of each decomposed partition... I wonder if the decomposePar utility can not be adapted to such separated domains into two part.
Conscientiously, I also tried to decompose those interfaces into only processor0 with topoSet, the cellDist figures of which are archived into cellDist_topoSet_coupled_for_interface.8.zip.

user1044

2015-07-22 01:21

  ~0005118

Last edited: 2015-07-22 04:51

Does anyone have any progress?
I tried to execute the parallel computation of the same model with simpleFoam, and then it could be executed correctly. I'm suspecting whether the boundary condition of p to be used in pEqn.H of pimpleFoam, fixedFluxressureFvPatchScalarField work correctly with the collaboration of the mappedFixedValue patch and cyclic patch in parallel computation. Anyway, we have to pay quite much attention to the broken pressure distribution rather than the velocity distribution.

user1044

2015-07-22 05:25

  ~0005119

Last edited: 2015-07-22 11:08

In order to simplify this problem, that is, exclude the relation of mappedPatch with this problem, I changed the boundary condition of the mappedPatch to that of fixedValue patch, which is usually used in this kind of channel flow. Expectedly, its parallel computation has bursted in the same way. It might be true the specification of the pimpleFoam solver is not available to calculate those boundary condition of cyclic and fixedValue patches simultaneously, wasn't it?

user4

2015-07-23 14:39

  ~0005128

Your case is two separate domains. On the cyclic inlet block there is no fixed value boundary condition so the pressure is floating and slowly the solver will generate out-of-bounds numbers. Use e.g. a mappedFixedValue to map only the velocity or (bit more work) set a reference pressure in the inlet block.

user1044

2015-07-23 22:15

  ~0005131

Last edited: 2015-07-24 05:37

Dear Dr mattijs,
I'm not so familiar with OpenFOAM yet, so I understood pRefCell for PIMPLE in fvSolution recently, but I tried the both positions of the inlet and cyclic block, and then unfortunately, similar diverged results were gotten... As I showed in comment:0005119, even if I did not use the mappedFixedValue for U BC of inlet block, that is, I used the fixedValue for U BC of inlet block, the parallel calculation did not work correctly(, the single calculation did work correctly). Note that, as you can see if you check 0/p in the uploaded system-0-bounary.tar.gz, the boundary condition for p is zeroGradient from the begining.
I apologize for my poor English.

user1044

2015-07-24 09:36

  ~0005134

Last edited: 2015-07-31 11:19

According to mattijs's note, I checked how the pRefCell and pRefValue are gotten and set in pimpleFoam solver, and then I have found the getter function Foam::setRefCell in findRefCell.C and the setter function Foam::fvMatrix<Type>::setReference in fvMatrix.C. I feel the setRefCell function correct, but the setReference strange..
<fvMatrix.C>
518: source()[celli] += diag()[celli]*value;
519: diag()[celli] += diag()[celli];

It is positive the diag() is a public member function inherited from lduMatrix, but the source() is negative.
http://openfoam.github.io/Documentation-dev/html/a00850.html

Then, what is the member function of source()? It is implimented in fvMatrix.H as Field<Type>& source(){return source_} and const Field<Type>& source() const{return source_} to access to a private data of source_, that is, a reference-only function?, I feel. It should be as follows,

518: source_[celli] += diag()[celli]*value;

am I not correct? The both sentences are exactly the same?

The above expressions, source()[celli] or source_[celli], either will do.

user1044

2015-07-31 11:38

  ~0005150

Last edited: 2015-07-31 11:46

This problem has been solved and I'm supposed to have found its causes. The mattijs's note:[0005128] is very important, that is, the reference p in the cyclic block is still floating. As you can see in L869:GeometricField.C, the pRefVaule in system/fvSolution become disable, when a kind of fixedValue BC is applied to that of p in the downstream block.
http://openfoam.github.io/Documentation-dev/html/a07558_source.html#l00860

So, in order to force pRefValue set in the cyclic block, I changed createFields.H and pEqn.H, as follows,

<createFields.H>
setRefCell(p, mesh.solutionDict().subDict("PIMPLE"), pRefCell, pRefValue, true);

<pEqn.H>
pEqn.setReference(pRefCell, pRefValue, true);

Addition to it, as you can see in L49:findRefCell.C, the pRefCell setting is supposed to be available for only Pstream::master(), that is, processor0 and verbose to set the pRefValue in the parallel computations (which partition does include the reference cell).
http://openfoam.github.io/Documentation-dev/html/a04647_source.html#l00031

On the other hand, it is supposed to be convenient to directly set it by pRefPoint in system/fvSolution, as you can see the returnReduce function of parallel processes in L85:findRefCell.C.

Now, we should follow the below to set the reference pressure of cyclic block in the case of two separate (independent?) domains.

1,<createFields.H>
setRefCell(p, mesh.solutionDict().subDict("PIMPLE"), pRefCell, pRefValue, true);

2.<pEqn.H>
pEqn.setReference(pRefCell, pRefValue, true);

3.<system/fvSolution>
    pRefPoint (-18.5 0 0);
    pRefValue 0;

Issue History

Date Modified Username Field Change
2015-07-01 07:21 user1044 New Issue
2015-07-01 07:21 user1044 File Added: violated_parallel_calc_with_mapped_inlet.pdf
2015-07-01 07:27 user1044 Tag Attached: fvOptions
2015-07-01 07:27 user1044 Tag Attached: parallel
2015-07-01 07:27 user1044 Tag Attached: cyclic
2015-07-01 07:27 user1044 Tag Attached: mappedPatch
2015-07-01 07:27 user1044 Tag Attached: pressureGradientExplicitSource
2015-07-01 07:27 user1044 File Added: system-0-bounary.tar.gz
2015-07-01 07:28 user1044 File Added: constant.tar.gz-aa
2015-07-01 07:28 user1044 File Added: constant.tar.gz-ab
2015-07-01 07:29 user1044 File Added: constant.tar.gz-ac
2015-07-01 07:29 user1044 File Added: constant.tar.gz-ad
2015-07-01 07:30 user1044 File Added: constant.tar.gz-ae
2015-07-01 07:31 user1044 File Added: constant.tar.gz-af
2015-07-01 07:31 user1044 File Added: constant.tar.gz-ag
2015-07-01 07:32 user1044 File Added: constant.tar.gz-ah
2015-07-01 07:33 user1044 File Added: constant.tar.gz-ai
2015-07-01 07:33 user1044 File Added: constant.tar.gz-aj
2015-07-01 09:25 user4 Note Added: 0005028
2015-07-01 09:45 user1044 Note Added: 0005029
2015-07-01 09:49 user4 Note Added: 0005030
2015-07-01 10:35 user1044 Note Added: 0005031
2015-07-01 10:36 user1044 File Added: log.tar.gz
2015-07-01 10:37 user1044 Note Edited: 0005031
2015-07-01 10:43 user1044 Note Edited: 0005031
2015-07-15 03:20 user1044 File Added: nodeNo_ELEMENT0+ELEMENT1.png
2015-07-15 03:20 user1044 File Added: nodeNo_ELEMENT0_inlet_side_mappedBC.png
2015-07-15 03:22 user1044 File Added: cellDist_ELEMENT0+ELEMTN1.zip
2015-07-15 03:23 user1044 File Added: cellDist_topoSet_coupled_for_interface.8.zip
2015-07-15 03:23 user1044 Tag Attached: decomposePar
2015-07-15 03:41 user1044 Note Added: 0005087
2015-07-22 01:21 user1044 Note Added: 0005118
2015-07-22 04:51 user1044 Note Edited: 0005118
2015-07-22 05:25 user1044 Note Added: 0005119
2015-07-22 11:08 user1044 Note Edited: 0005119
2015-07-23 14:39 user4 Note Added: 0005128
2015-07-23 22:15 user1044 Note Added: 0005131
2015-07-24 05:37 user1044 Note Edited: 0005131
2015-07-24 09:36 user1044 Note Added: 0005134
2015-07-24 09:38 user1044 Note Edited: 0005134
2015-07-24 09:39 user1044 Note Edited: 0005134
2015-07-24 09:40 user1044 Note Edited: 0005134
2015-07-24 09:52 user1044 Note Edited: 0005134
2015-07-24 09:53 user1044 Note Edited: 0005134
2015-07-24 11:26 user1044 Note Edited: 0005134
2015-07-26 10:52 user1044 Note Edited: 0005134
2015-07-31 11:19 user1044 Note Edited: 0005134
2015-07-31 11:38 user1044 Note Added: 0005150
2015-07-31 11:46 user1044 Note Edited: 0005150
2015-10-22 10:29 henry Status new => resolved
2015-10-22 10:29 henry Resolution open => fixed
2015-10-22 10:29 henry Assigned To => henry