# LiftDrag utility question

 Register Blogs Members List Search Today's Posts Mark Forums Read

 July 11, 2006, 13:57 Excerpt from ~/OpenFOAM/OpenFO #1 Senior Member   Srinath Madhavan (a.k.a pUl|) Join Date: Mar 2009 Location: Edmonton, AB, Canada Posts: 703 Rep Power: 13 Excerpt from ~/OpenFOAM/OpenFOAM-1.3/src/postProcessing/incompressible/liftDrag/liftDrag.C : scalar qRef = 0.5*magSqr(Uinf); scalar Fref = qRef*Aref; vector pressureCoeff = pressureForce/Fref; vector viscousCoeff = viscousForce/Fref; return (pressureCoeff + viscousCoeff) - flowDirection*(flowDirection & (pressureCoeff + viscousCoeff)); Can somone kindly point out what the return statement is doing in the last line. Specifically, what is being subtracted? Thanks.

 July 13, 2006, 08:16 It is returning the lift part #2 Senior Member   Eugene de Villiers Join Date: Mar 2009 Posts: 725 Rep Power: 13 It is returning the lift part of the force coefficient. i.e. (pressureCoeff + viscousCoeff) = total force coefficient vector flowDirection*(flowDirection & (pressureCoeff + viscousCoeff)) = the part of the force coefficient in the direction of the flow.

 July 13, 2006, 09:01 Thanks a lot Eugene! #3 Senior Member   Srinath Madhavan (a.k.a pUl|) Join Date: Mar 2009 Location: Edmonton, AB, Canada Posts: 703 Rep Power: 13 Thanks a lot Eugene!

 July 28, 2006, 12:11 For a 2D case, it appears that #4 Senior Member   Srinath Madhavan (a.k.a pUl|) Join Date: Mar 2009 Location: Edmonton, AB, Canada Posts: 703 Rep Power: 13 For a 2D case, it appears that the liftDrag/OpenFOAM routines use the third number specified in the latter part of the vertices section[1] in the blockMeshDict file, as the depth (which is used in the calculation of projected area, hence the diomensionless force coefficients). Changing this number, say by an order of magnitude, changes the lift/drag coefficients etc. by the same order. Someone please correct me if I am wrong. [1] For instance the number 0.1 in the following example: bla bla bla... convertToMeters 1; vertices ( (0 0 0) (1.16 0 0) (1.17 0 0) (1.515 0 0) (0 0.015 0) (1.16 0.015 0) (1.17 0.015 0) (1.515 0.015 0) (0 0.025 0) (1.16 0.025 0) (1.17 0.025 0) (1.515 0.025 0) (0 0.04 0) (1.16 0.04 0) (1.17 0.04 0) (1.515 0.04 0) (0 0 0.1) (1.16 0 0.1) (1.17 0 0.1) (1.515 0 0.1) (0 0.015 0.1) (1.16 0.015 0.1) (1.17 0.015 0.1) (1.515 0.015 0.1) (0 0.025 0.1) (1.16 0.025 0.1) (1.17 0.025 0.1) (1.515 0.025 0.1) (0 0.04 0.1) (1.16 0.04 0.1) (1.17 0.04 0.1) (1.515 0.04 0.1) );

 October 3, 2007, 18:02 Despite being a very old threa #5 Senior Member   Srinath Madhavan (a.k.a pUl|) Join Date: Mar 2009 Location: Edmonton, AB, Canada Posts: 703 Rep Power: 13 Despite being a very old thread, I wish to add an important observation especially for all those trying out 2D cases and using the liftDrag utility and/or its derivatives that were posted in this forum. As mentioned above, the distance in the third direction is used to estimate the force coefficients, in particular the force on the wall patch itself. As a result even if you specify a constant projected area (say unity) when finally calculating Cd/Cl etc., the pressure used to calculate the force will be multiplied by the area of the patch as Foam sees it. For instance, if you consider a square obstacle with dimensions D x D x L in a channel, then for a 2D case, you might create the blockMeshDict file as shown above (i.e. L = 0.1). In this case, the liftDrag calculation will assume that the area that needs to be multiplied by the pressure to get the force is D times L. Ideally then, for a 2D case, one wants L to be unity. This needs to be reflected in the blockMeshDict. Aside notes for the checkMesh utility maintainer: You may want to consider adding an extra check for the 2D case. If I use a unit length in the third direction and the typical grid size in the other two directions is very small compared to unity, then checkMesh reports that 1 Mesh check (very high aspect ratio) failed due to a high aspect ratio. For a 2D case, the grid sizes in the third direction should be neglected when checkMesh estimates the aspect ratio. [madhavan@jinshi ~]\$ checkMesh . franke_et_al_re_40 /*---------------------------------------------------------------------------*\ | ========= | | | \ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \ / O peration | Version: 1.4.1 | | \ / A nd | Web: http://www.openfoam.org | | \/ M anipulation | | \*---------------------------------------------------------------------------*/ Exec : checkMesh . franke_et_al_re_40 Date : Oct 03 2007 Time : 14:22:32 Host : jinshi PID : 26061 Root : /home/madhavan Case : franke_et_al_re_40 Nprocs : 1 Create time Create polyMesh for time = constant Time = constant Mesh stats points: 3064640 edges: 7656160 faces: 6121120 internal faces: 3056480 cells: 1529600 boundary patches: 5 point zones: 0 face zones: 0 cell zones: 0 Number of cells of each type: hexahedra: 1529600 prisms: 0 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 0 polyhedra: 0 Checking topology... Boundary definition OK. Point usage OK. Upper triangular ordering OK. Topological cell zip-up check OK. Face vertices OK. Face-face connectivity OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces ... Patch Faces Points Surface ChannelWalls 3200 6404 ok (not multiply connected) ObstacleWalls 320 640 ok (not multiply connected) vinlet 960 1922 ok (not multiply connected) poutlet 960 1922 ok (not multiply connected) frontAndBack 3059200 3064640 ok (not multiply connected) Checking geometry... Domain bounding box: (-0.0125 -0.015 0) (0.03750000000000001 0.015 1) Boundary openness (3.509809764395274e-17 -2.895593055626086e-15 1.174630898377996e-17) OK. ***High aspect ratio cells found, Max aspect ratio: 32000.0000000204, number of cells 1529600 <

 October 4, 2007, 02:39 I really do not agree with thi #6 Senior Member   Hrvoje Jasak Join Date: Mar 2009 Location: London, England Posts: 1,783 Rep Power: 22 I really do not agree with this: if it were so, it would be trivial to fix the width of all OpenFOAM meshes in 2-D to unit width and be done with it. The issue stems from the way I calculate cell volume and face area, by decomposition into triangles and pyramids. In extremely stretched cells, this will accumulate the round-off errors, sometimes in a nasty way, which will mess up the accuracy in the rest of the code. Therefore, you are much better creating the mesh such that the cells in the third direction look decent (avoiding the discretisation error in surface and volume calculation) and then using a POCKET CALCULATOR to divide the forces by the width. Hrv __________________ Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk

 October 4, 2007, 02:52 Thanks for the recommendation #7 Senior Member   Srinath Madhavan (a.k.a pUl|) Join Date: Mar 2009 Location: Edmonton, AB, Canada Posts: 703 Rep Power: 13 Thanks for the recommendation Dr. Jasak. I was unaware of these other issues. So to sum up, the idea is to create a 2D geometry with a decent width in the third direction (i.e. acceptable aspect ratio). I am presently comparing the pressure and viscous drag coefficient predictions with a paper. I will report the results soon.

 October 4, 2007, 10:25 For 3-D surfaces, high aspect #8 Member   Doug Baldwin Join Date: Mar 2009 Posts: 53 Rep Power: 9 For 3-D surfaces, high aspect ratio cells seem inevitable when y-plus is 1 or 2, unless the wall is discritized into an unreasonably large number of very tiny pieces. My high aspect ratio cells at the wall have low skew. This appears to me to not be a problem because the OF results match wind tunnel data. I'm new to this community, so could be missing something obvious.

 March 28, 2008, 11:55 Hi to all, i am calculating #9 New Member   Fabian Korn Join Date: Mar 2009 Location: Heilbronn, Germany Posts: 21 Rep Power: 9 Hi to all, i am calculating a 3D cylinder case and try to calculate the drag coefficient. The CD/Cl tool seems to work in a 2D case, but i get a negative result for my 3D case. I sue a dynSmagotinsky at Re around 200. If i divide Cd by my depth i am close to the result i want to have, but i get the same result for Re=200 and Re=500 what is absolutly not reasenable. Can anybody help me, i have no idea what to do. Fabian

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post hoochie OpenFOAM Post-Processing 29 September 19, 2014 03:38 kumar2 OpenFOAM Post-Processing 11 August 11, 2010 03:52 shaun OpenFOAM Running, Solving & CFD 9 September 16, 2008 05:36 cfdphil OpenFOAM Running, Solving & CFD 2 December 5, 2007 06:49 guggi OpenFOAM Running, Solving & CFD 1 August 2, 2006 12:36

All times are GMT -4. The time now is 14:03.