|
[Sponsors] |
Moving mesh still crashes in parallel in 1.6-ext |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 19, 2011, 03:14 |
|
#21 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
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
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
April 19, 2011, 03:43 |
|
#22 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
Hi Hrv,
If we can help in the testing, please let us know. |
|
April 19, 2011, 03:47 |
|
#23 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
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
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
April 19, 2011, 05:24 |
|
#24 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
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 DICPCG: Solving for motionUx, Initial residual = 0.00616099, Final residual = 9.97219e-07, No Iterations 764 DICPCG: Solving for motionUy, Initial residual = 0.00156417, Final residual = 9.99231e-07, No Iterations 752 Initializing the GGI interpolator between master/shadow patches: outsideSlider/insideSlider volume continuity errors : volume = 0.999912, max error = 4.07623e-12, sum local = 7.1993e-15, global = -3.61117e-19 Point usage OK. Upper triangular ordering OK. Topological cell zip-up check OK. Face vertices OK. Face-face connectivity OK. Mesh topology OK. Boundary openness (-8.27072e-18 -2.6727e-17 4.99519e-21) Threshold = 1e-06 OK. ***High aspect ratio cells found, Max aspect ratio: 2.95689e+06, number of cells 1 Threshold = 1000 Minumum face area = 1.97234e-07. Maximum face area = 0.00423241. Face area magnitudes OK. ***Zero or negative cell volume detected. Minimum negative volume: -7.8123e-08, Number of negative volume cells: 1 Mesh non-orthogonality Max: 74.6801 average: 6.747 Threshold = 70 *Number of severely non-orthogonal faces: 1. Non-orthogonality check OK. ***Error in face pyramids: 5 faces are incorrectly oriented. Max skewness = 3.68306 OK. Failed 3 mesh geometry checks. Failed 1 mesh checks. ExecutionTime = 1597.47 s ClockTime = 1811 s |
|
April 19, 2011, 06:26 |
|
#25 |
Member
Oliver Borm
Join Date: Mar 2009
Posts: 60
Rep Power: 17 |
@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:
/*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM Extend Project: Open source CFD | | \\ / O peration | Version: 1.6-ext | | \\ / A nd | Web: www.extend-project.de | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Build : 1.6-ext-bb09cc293ce1 Exec : pimpleDyMFoam -parallel Date : Apr 19 2011 Time : 11:05:50 Host : PID : 23985 Case : run/wingMotion2D_pimpleDyMFoam nProcs : 3 Slaves : 2 ( .23986 .23987 ) Pstream initialized with: floatTransfer : 0 nProcsSimpleSum : 0 commsType : nonBlocking SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create dynamic mesh for time = 0 Selecting dynamicFvMesh dynamicMotionSolverFvMesh Selecting motion solver: displacementLaplacian Selecting motion diffusion: inverseDistance Reading field p Reading field U Reading/calculating face flux field phi Selecting incompressible transport model Newtonian Selecting turbulence model type RASModel Selecting RAS turbulence model kOmegaSST kOmegaSSTCoeffs { alphaK1 0.85034; alphaK2 1; alphaOmega1 0.5; alphaOmega2 0.85616; gamma1 0.5532; gamma2 0.4403; beta1 0.075; beta2 0.0828; betaStar 0.09; a1 0.31; c1 10; } Reading field rAU if present Starting time loop Courant Number mean: 0.01850880039 max: 0.6674178996 velocity magnitude: 150.3629636 deltaT = 1.133786848e-05 Time = 1.13379e-05 Restraint verticalSpring spring length 6.850694294e-07 force (-0.01179307663 -0.1230225691 -0) moment (0 0 0) Restraint axialSpring angle 2.75574809e-06 force (0 0 0) moment (0 0 0.1234580713) Constraint fixedLine1 error (1.308203253e-07 0 0) force (-16313.4538 -0 -0) moment (0 0 0) not converged Constraint fixedAxis1 angle 0 force (0 0 0) moment (-0 0 -0) converged Constraint fixedLine1 error (3.867253945e-08 0 0) force (-4822.512741 -0 -0) moment (0 0 0) not converged Constraint fixedAxis1 angle 0 force (0 0 0) moment (-0 0 -0) converged Constraint fixedLine1 error (1.143220907e-08 0 0) force (-1425.610386 -0 -0) moment (0 0 0) not converged Constraint fixedAxis1 angle 0 force (0 0 0) moment (-0 0 -0) converged Constraint fixedLine1 error (3.379540314e-09 0 0) force (-421.4327908 -0 -0) moment (0 0 0) not converged Constraint fixedAxis1 angle 0 force (0 0 0) moment (-0 0 -0) converged Constraint fixedLine1 error (9.990450689e-10 0 0) force (-124.5821361 -0 -0) moment (0 0 0) converged Constraint fixedAxis1 angle 0 force (0 0 0) moment (-0 0 -0) converged sixDoFRigidBodyMotion constraints converged in 5 iterations Constraint force: (-23107.59185 0 0) Constraint moment: (0 0 548.1037458) Centre of mass: (0.4974612746 -0.01671895744 0.125) Linear velocity: (-0.00571892281 5.85705643e-05 -9.566586771e-26) Angular velocity: (5.536981322e-21 -4.184256517e-22 -0.2416408738) DICPCG: Solving for cellDisplacementx, Initial residual = 1, Final residual = 0.07626110807, No Iterations 1 DICPCG: Solving for cellDisplacementy, Initial residual = 1, Final residual = 0.07423759739, No Iterations 1 pimpleDyMFoam: malloc.c:4631: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed. [:23986] *** Process received signal *** [:23986] Signal: Aborted (6) [:23986] Signal code: (-6) [:23986] [ 0] /lib/libc.so.6(+0x31610) [0x7fe9daa6d610] [:23986] [ 1] /lib/libc.so.6(gsignal+0x35) [0x7fe9daa6d5a5] [:23986] [ 2] /lib/libc.so.6(abort+0x174) [0x7fe9daa6e784] [:23986] [ 3] /lib/libc.so.6(+0x6f0c1) [0x7fe9daaab0c1] [:23986] [ 4] /lib/libc.so.6(+0x71d46) [0x7fe9daaadd46] [:23986] [ 5] /lib/libc.so.6(__libc_malloc+0x62) [0x7fe9daaaf91b] [:23986] [ 6] /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6(_Znwm+0x1d) [0x7fe9db2e001d] [:23986] [ 7] /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6(_Znam+0x9) [0x7fe9db2e0139] [:23986] [ 8] pimpleDyMFoam(_ZN4Foam4ListIdE7setSizeEi+0x35) [0x429a75] [:23986] [ 9] /OpenFOAM/OpenFOAM-1.6-ext/lib/linux64GccDPOpt/libfiniteVolume.so(_ZNK4Foam21volPointInterpolation11makeWeightsEv+0x12e) [0x7fe9dc6b4a5e] [:23986] [10] /OpenFOAM/OpenFOAM-1.6-ext/lib/linux64GccDPOpt/libfiniteVolume.so(_ZNK4Foam21volPointInterpolation10movePointsEv+0x9) [0x7fe9dc6b57f9] [:23986] [11] /OpenFOAM/OpenFOAM-1.6-ext/lib/linux64GccDPOpt/libOpenFOAM.so(_ZN4Foam8polyMesh10movePointsERKNS_5FieldINS_6VectorIdEEEE+0x7c7) [0x7fe9dba87347] [:23986] [12] /OpenFOAM/OpenFOAM-1.6-ext/lib/linux64GccDPOpt/libfiniteVolume.so(_ZN4Foam6fvMesh10movePointsERKNS_5FieldINS_6VectorIdEEEE+0x141) [0x7fe9dc315311] [:23986] [13] /OpenFOAM/OpenFOAM-1.6-ext/lib/linux64GccDPOpt/libdynamicFvMesh.so(_ZN4Foam25dynamicMotionSolverFvMesh6updateEv+0x48) [0x7fe9de915258] [:23986] [14] pimpleDyMFoam() [0x41772f] [:23986] [15] /lib/libc.so.6(__libc_start_main+0xec) [0x7fe9daa5ab4c] [:23986] [16] pimpleDyMFoam() [0x4153b9] [:23986] *** End of error message *** |
|
April 19, 2011, 07:37 |
|
#26 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
Deepblue,
When my commsType is blocking, the tutorial works, when it is nonBlocking I get the same error as you. |
|
April 20, 2011, 04:09 |
|
#27 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
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. |
|
June 7, 2011, 11:33 |
|
#28 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
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 { type fixedValue; value nonuniform 0(); } Code:
outflow { type fixedValue; value uniform (0 0 0); } |
|
June 7, 2011, 18:46 |
|
#29 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
Parallel problem has been fixed: normal service resumes.
In your case you have zero faces in patch which explains the format: empty list. Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk Last edited by hjasak; June 7, 2011 at 18:47. Reason: Stupid iPad spell checker |
|
June 8, 2011, 16:36 |
|
#30 | |
Senior Member
Daniel WEI (老魏)
Join Date: Mar 2009
Location: Beijing, China
Posts: 689
Blog Entries: 9
Rep Power: 21 |
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
__________________
~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China |
||
July 4, 2011, 04:15 |
|
#31 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
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? |
|
July 4, 2011, 11:40 |
|
#32 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
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. |
|
July 4, 2011, 11:41 |
|
#33 |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
Here is the figure:
|
|
July 13, 2012, 04:36 |
MesquiteMotionSolver compiling problems
|
#34 |
Member
Stefano
Join Date: Jul 2009
Posts: 36
Rep Power: 17 |
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 |
|
July 13, 2012, 08:01 |
|
#35 |
Senior Member
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22 |
> 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 |
|
October 17, 2012, 10:13 |
|
#36 | |
New Member
Join Date: Oct 2012
Posts: 17
Rep Power: 14 |
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 |
||
February 17, 2014, 09:35 |
|
#37 |
Member
Johan Lorentzon
Join Date: Mar 2009
Location: Lunds University, Sweden
Posts: 78
Rep Power: 23 |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
3D Hybrid Mesh Errors | DarrenC | ANSYS Meshing & Geometry | 11 | August 5, 2013 07:42 |
[Gmsh] 2D Mesh Generation Tutorial for GMSH | aeroslacker | OpenFOAM Meshing & Mesh Conversion | 12 | January 19, 2012 04:52 |
Create moving mesh without simulating (CFX) | spatialtime | ANSYS | 2 | July 22, 2010 11:30 |
salome, openfoam and moving mesh | prhlava | OpenFOAM Running, Solving & CFD | 8 | November 9, 2009 09:59 |
moving mesh in parallel mode | Karteek | Siemens | 4 | June 16, 2008 05:12 |