[lr103476]

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

[gschaider]

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

[lr103476]

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

[hjasak]

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

[lr103476]

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

[hjasak]

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