I think I have sorted out this one as well, but we need serious testing. It was to do with a collision on global patch update, because processor patches were not done in time.
Hrv |
Hi Hrv,
If we can help in the testing, please let us know. |
Well, sorry to post bits of code like this, but the library is rather in pieces over here and I don't want to deal with 3 pieces of half finished development work. Here's what you do:
foamsrc edit fields/PointPatchFields/derived/global/GlobalPointPatchField.C Go to the bottom in the function updateInterfaceMatrix ( const scalarField& psiInternal, scalarField& result, const lduMatrix& m, const scalarField& coeffs, const direction, const Pstream::commsTypes commsType ) const and look for a bit that says: tmp<Field<scalar> > trpf = reduceExtractPoint<scalar>(localMult); and then say: // Reduce/extract the result and enforce over all processors // Requires global sync points to flush buffers before gather-scatter // communications. Reconsider. HJ, 29/Mar/2011 if (Pstream::defaultCommsType == Pstream::nonBlocking) { IPstream::waitRequests(); OPstream::waitRequests(); } tmp<Field<scalar> > trpf = reduceExtractPoint<scalar>(localMult); Field<scalar>& rpf = trpf(); // Get addressing const labelList& addr = globalPointPatch_.meshPoints(); forAll (addr, i) { result[addr[i]] += rpf[i]; } } Tell me what you see, Hrv |
Hrv,
I tried your changes, but I get a wrong mesh deformation at the same timestep. This negative volume cells are now on a different place, but also near a processor boundary. Code:
Time = 0.1 |
@Hrv: Is it correct that the tetDecompositionMotionSolver is also not working with ggi type boundary conditions? Because they are missing in src/OpenFOAM/fields/PointPatchFields/constraint/ ?
@flowris: Nice that this is working for you. But for me the wingMotion2D_pimpleDyMFoam test case is crashing if I switch over to commsType nonBlocking, also with this new patch for GlobalPointPatchField. I've compiled the complete src in order to make sure all templates are instantiated. Did you make sure you are using commsType nonBlocking? Code:
/*---------------------------------------------------------------------------*\ |
Deepblue,
When my commsType is blocking, the tutorial works, when it is nonBlocking I get the same error as you. |
1 Attachment(s)
Hello,
Another example of a problem with moving meshes in parallel. Maybe this can help us understand the problem better. A foil is moving with angularOscillatingVelocity. The processor boundaries are vertical and meet the moving wall: that is where the distorted cells are born. |
Has anybody found a solution yet? I found that in parallel run, the file motionU or pointMotionU gets degenerated in later time steps on the boundaries. I often find stuff like this:
Code:
outflow Code:
outflow |
Parallel problem has been fixed: normal service resumes.
In your case you have zero faces in patch which explains the format: empty list. Hrv |
Quote:
I met the same problems several months ago for many times, and I found its very annoying for some bodies with certain shape of cross-sections, and later I went to rbf motion which has a more straightforward theory basis in my opinion, and it works well in both serial and parallel. Though I still have the question of laplacian smoothing and rbf morphing, which one is more efficient, more accurate or in general better... Hope Hrv can shed some lights on this :) |
1 Attachment(s)
Dear forum,
I still have the same problem where a processor boundary meets a ggi. The picture shows two simulations of the same case: - left is a parallel run on four processors, of which the boundaries cross the circle vertically and horizontally - right is a run on one processor The difference is clear: the velocity is disturbed on the meeting point of the processor boundary and ggi (red ellipsises). Is there something to do about this inconvenience? |
Now I am really losing it: this problem remains if I decompose like in the figure: processor boundaries do not meet ggi.
However, the run on one processor worked well! Any suggestions welcome and much appreciated. |
1 Attachment(s)
Here is the figure:
|
MesquiteMotionSolver compiling problems
1 Attachment(s)
Hi everybody,
i would like to use the mequiteMotionSolver, but I'm having the problem when I compile. Please find it in the attached file. Could you help me please? I miss the file "Mesquite_all_headers.hpp". Could someone tell me where i can find it? Thank you Stefano |
> I miss the file "Mesquite_all_headers.hpp". Could someone tell me where i can find it?
Your ThirdParty package mesquite-2.1.2 is probably not installed properly or did not compile. Look at the log for the ThirdParty/AllMake.stage3 script. Martin |
Quote:
Hi, I am a new user. I am having problem in parallel runs with the laplaceFaceDecomposition (I guess) in the mesh motion. Could you tell me please how to set the commsType equal to scheduled or blocking, and where (which file/line?) Thanks |
Quote:
|
All times are GMT -4. The time now is 11:06. |