|
[Sponsors] |
May 3, 2006, 11:31 |
Hello,
A set up a case conc
|
#1 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
Hello,
A set up a case concerning an o-type mesh to solve the flow around a moving wing. The following two links show this mesh: http://www.aero.lr.tudelft.nl/~frank...wing_omesh.jpg http://www.aero.lr.tudelft.nl/~frank...omesh_zoom.jpg (Using firefox I cant put my pictures in the post.) The BC of the left half of the outer boundary is 'inlet' and the right half is put to 'outlet'. I already simulated a moving cylinder using the movingFlapFvMesh routine, which was adapted to contain harmonic motion. The o-type set-up is chosen since I also used this mesh for Fluent simulations, so I like to compare the results. The solver I used for the moving cylinder worked perfectly, although the timesteps needed to be very very small. But in this case of the o-type mesh containing a moving wing I get a 'segmentation fault'. I already figured out that the problem occurs in the mesh.move() routine. As far as I know all other solver settings are correct, since I put them equal to my working moving cylinder case. What are typical reasons for a segmentation error? Are the tetrahedral cells near the outer boundary causing any troubles? Thanks and regards, Frank
__________________
Frank Bos |
|
May 3, 2006, 14:40 |
Hi Frank.
At first: I don't
|
#2 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Hi Frank.
At first: I don't really know much about moving meshes, so I can't help you with your concrete problem. @segmentation fault: this usually occurs when a program trys to access memory outside its bounds (see http://en.wikipedia.org/wiki/Segmentation_Fault). In OpenFOAM this usually occurs when a List<> or similar is accessed with an index outside of the allocated domain. To find out where this occurs make a separate copy of the OF-sources, recompile them with the swich WM_COMPILE_OPTION set to Debug (just uncomment the right lines in the bashrc/cshrc files). This makes OF run slower, but accesses to List<> etc are checked for ranges and the program aborts if you access outside of a range (plus you get a stack trace). This won't solve your problem, but it will help you find out where it occurs. For recompiling OpenFOAM look at Martin's How-To at http://openfoamwiki.net/index.php/Howto_compile_O penFOAM If you want stack traces with line-numbers and source-files try to apply the patch described in http://www.cfd-online.com/OpenFOAM_D...tml?1145526782
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
May 4, 2006, 03:19 |
All right, I did that. It took
|
#3 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
All right, I did that. It took a long time to compile OpenFOAM but it works again. Then I compiled my solver again.
Using that solver, which has moving meshes according to the movingFlapFvMesh class, the following output is generated. Before debugging the last statement was replaced with the segmentation fault. =========================================+++ =========================================+++ Create time Create mesh Selecting movingFvMesh movingFlapFvMesh Selection motion solver: laplace Selection motion diffusion: quadratic Performing a moving mesh calculation: x-amplitude: 1.337 x-frequency: 0.25 y-amplitude: 0 y-frequency: 0.25 theta-amplitude: 0.5 theta-frequency: 0.25 Reading transportProperties Reading field p Reading field U Reading/calculating face flux field phi Mean and max Courant Numbers = 0 0.000152572 Starting time loop Mean and max Courant Numbers = 0 0.305144 deltaT = 0.1 Time = 0.1 --> FOAM FATAL ERROR : index -1 out of range 0 ... 3 From function UList<t>::checkIndex(const label) in file /home/frankl/OpenFOAM/OpenFOAM-1.2/src/OpenFOAM/lnInclude/UListI.H at line 107. FOAM aborting Aborted =========================================+++ =========================================+++ So the problem has something to do with UListl.H, but what I could do with this information is not yet clear to me. Thanks anyways, Frank
__________________
Frank Bos |
|
May 4, 2006, 03:26 |
This looks very dubious and is
|
#4 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
This looks very dubious and is probably somewhere in the moving flap class (where did you pick it up?).
Unfortunately, what is required is a trace-back of the error. For the moment, try running it in gdb and do where + post it here if you'd like comments. Ideally, I would like the debug version of trace-back (it porvides line numbers etc) but if you haven't got this ready, let's try the optimized trace-back first. Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
May 4, 2006, 07:35 |
Problem solved. I made a very
|
#5 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
Problem solved. I made a very stupid mistake. For my cylinder simulation I manipulated the kinematics in movingFvFlapMesh.C and changed the movingPatchID to the name of the cylinder wall.
movingPatchID = boundaryMesh().findPatchID("cyl_wall"); A few days ago I wanted to use the same solver for a moving wing, which name was "wing_wall".....All right, I changed the patch name and everything works OK, for now.... Btw, I found that OpenFOAM is approximately twice as fast compared to Fluent during an iteration. But OpenFOAM needs about more than twice the number of timesteps, due to the Courant restriction. Are there any plans to develop a second order fully implicit time scheme? Frank
__________________
Frank Bos |
|
May 4, 2006, 07:51 |
This is a second-order fully i
|
#6 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
This is a second-order fully implicit scheme. If you wish to recover the time-step behaviour of Fluent, all you need to do is to set up the same discretisation (especially convection).
Additionally, Fluent uses transient SIMPLE for its transient runs by default, which is more time-step tolerant (whereas icoFoam/turbFoam uses PISO). If you wish to try it out, there's a few implementations about (Dr. Hakan Nilsson of Chalmers Uni and I played around with it a while back). However, you will also get some of the increased cost because of the different algorithm. Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Technical] Segmentation fault in map | msg30 | OpenFOAM Meshing & Mesh Conversion | 6 | March 27, 2008 11:49 |
Segmentation fault | billy | OpenFOAM Installation | 20 | April 23, 2007 23:57 |
segmentation fault | Sheila | Siemens | 8 | October 9, 2005 06:40 |
segmentation fault | natesan | Siemens | 4 | January 12, 2004 09:51 |
Segmentation Fault | Prateep Chatterjee | FLUENT | 1 | May 29, 2000 11:47 |