|
2015-07-01 07:21
|
|
|
2015-07-01 07:27
|
|
|
2015-07-01 07:28
|
|
|
2015-07-01 07:28
|
|
|
2015-07-01 07:29
|
|
|
2015-07-01 07:29
|
|
|
2015-07-01 07:30
|
|
|
2015-07-01 07:31
|
|
|
2015-07-01 07:31
|
|
|
2015-07-01 07:32
|
|
|
2015-07-01 07:33
|
|
|
2015-07-01 07:33
|
|
|
|
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? |
|
|
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. |
|
|
In your system/controlDict add DebugSwitches { mappedPatchBase 1; } (or add them to the section in the global etc/controlDict in the installation directory) |
|
|
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. |
|
2015-07-01 10:36
|
|
|
2015-07-15 03:20
|
nodeNo_ELEMENT0+ELEMENT1.png (182,527 bytes) |
|
2015-07-15 03:20
|
nodeNo_ELEMENT0_inlet_side_mappedBC.png (108,383 bytes) |
|
2015-07-15 03:22
|
|
|
2015-07-15 03:23
|
|
|
|
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. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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; |
- Anonymous
