|
[Sponsors] |
September 9, 2014, 04:22 |
forces / forceCoeffs on Multiple Patches
|
#1 |
New Member
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 11 |
Hello everyone,
I am experiencing some trouble when outputting the forces and force coefficient in my simulations. I have a quite simple geometry (axis symetrical body) made of different patches called : geometrie_01 geometrie_02 ... geometrie_n. The thing is, when I try to output the forces or force coefficients on the whole body (which is what I'm interested in), OpenFoam returns them for one patch only, the one with the highest number. e.g. : when I write patches (geometrie_10 geometrie_02); in my controlDict file, the output is going to be the one of geometrie_10 only. I tried using the inGroups feature in snappyHexMesh but it doesn't seem to change anything. Has anyone already experienced that ? I browsed different posts talking about a similar problem but the solution was to give all the patches at once, separated with spaces, in the "patches" declaration in controlDict, which is what I do. The thing is, it doesn't work for me Any help/ideas would be appreciated Thanks in advance, Seb PS: I'm using OpenFoam 2.2.0 |
|
September 11, 2014, 14:54 |
|
#2 |
Member
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13 |
If you want the forces over all of the geometrie_NN patches you could just use a wildcard
patches ("geometrie_.*"); If you only want particular patches it might be best to rename them (found in polyMesh/boundary) so that you can group them together with wildcards in a meaningful way. |
|
September 12, 2014, 04:14 |
|
#3 |
New Member
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 11 |
Hello Andy,
Thanks for your reply I should have said it but patches ("geometrie_.*"); was the first thing I tried to use and it gives exactly the same result than if I give the highest numbered "geometrie_NN". Am I missing some parameter or the activation of anything which could fix this ? Seb Last edited by seb_210; September 12, 2014 at 09:58. |
|
September 16, 2014, 11:59 |
|
#4 |
New Member
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 11 |
Anybody else ?
Thanks Seb |
|
September 16, 2014, 13:26 |
|
#5 |
Member
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13 |
I just noticed that you mentioned you put your forceCoeffs function in your controlDict file. Is there any reason you can't use an include in your controlDict and then use dedicated forceCoeffs file?
I've attached an example below. You'll need to edit the forceCoeffs file. Anything in ALL CAPS will need info related to your case. Where it says AIRFOIL is where you would put "geometrie_.*". Be sure to have it as .* and not * This is what I generally use for some of my correlation work and things generally work quite well. Hope you have some luck with it. |
|
September 17, 2014, 04:17 |
|
#6 |
New Member
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 11 |
Allright,
I tried your files and I still get the same result. I definetely think the problem does not come from the functions dictionnary. Might it be related with my geometry input file (.stil file) or the boundary declaration (in fact the forces and coefficients are returned for the last patch given in /constant/polyMesh/boundary) ? Or anything else in the patch declaration ? I don't know ... This is becoming frustrating ^^ Thanks again for your help ! Really appreciated Seb |
|
September 17, 2014, 13:39 |
|
#7 |
Member
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13 |
Could you post the contents of you polyMesh/boundary file?
Are you running in parallel or serial? It sounds like you are also running a snappyHexMesh correct? If so then can you post one of the polyMesh boundary files from one of your processor directories? There are a couple issues at play here I think. 1. Where is it pulling in your patch names? That's why I'm trying to figure out your setup. 2. What are the patches that the solver sees. It could be that your other patches are somehow spelled differently or maybe don't even use "geometrie_" at all |
|
September 18, 2014, 05:55 |
|
#8 |
New Member
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 11 |
Here they are:
./system/snappyHexMesh ./constant/polyMesh/boundary and a screenshot showing the patches in paraFoam (which make me think they are all well defined as such) If you find anything wrong or incomplete, just tell me Thanks, Seb |
|
September 19, 2014, 00:33 |
|
#9 |
Member
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13 |
hmmm, you're right everything looks ok to me.
Have you tried outputting the forces for each individual patch and making sure that some of them aren't reporting 0 forces? I guess another quick test would be to use the "geometrie_.*" in your 0/ files as well to see if OF can pick up the wildcard when initializing your case. An example of how to do this would be the motorBike tutorial under incompressible/simpleFoam. I'll admit this is a bit of a headscratcher. |
|
September 21, 2014, 13:15 |
|
#10 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Greetings to all!
The one likely reason I can think of as to why this might not be working is that it could be a bug that was present in OpenFOAM 2.2.0 and that it might have been already been fixed since then. I have several OpenFOAM versions installed and I could check this for you, but I need a simple example case that demonstrates this issue. If you can share it, I can quickly test it several versions and even try to isolate the problem. Otherwise, I don't much free time (any more) to create such a case myself Best regards, Bruno
__________________
|
|
February 22, 2017, 09:43 |
|
#11 |
Member
subhankar
Join Date: May 2016
Posts: 36
Rep Power: 9 |
Hi all,
I am facing a similar problem. I have two bodies and have mentioned them under different patch names. Also i have described the same in the controldict file, but still I am getting one force coefficient.dat file and one Cl and Cd value. I need to calculate force coefficient on both bodies separately. I am using ubuntu 16.04, openFoam 3.0.1. Any form of suggestions is highly appreciated. regards Subhankar |
|
February 22, 2017, 15:05 |
Sample ForceCoeffs
|
#12 |
Member
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13 |
Hi Subhankar
Not exactly the same issue but here's a pointer to what you're looking for In your forceCoeffs file you should be able to put multiple force Monitors. I've copied the following straight out of the tutorial. A lot of it falls on your naming scheme. If you have 2 bodies, prepend a "geometry1-" and "geometry2-" to all the patches on the corresponding bodies. Then in your force monitor blocks in your forceCoeffs file you would put something like the following. Code:
forceCoeffs_geom1 { // type forceCoeffs; type forces; functionObjectLibs ( "libforces.so" ); outputControl timeStep; timeInterval 1; log yes; patches ( "geometry1.*" ); pName p; UName U; rhoName rhoInf; // Indicates incompressible log true; rhoInf 1; // Redundant for incompressible liftDir (0 0 1); dragDir (1 0 0); CofR (0.72 0 0); // Axle midpoint on ground pitchAxis (0 1 0); magUInf 20; lRef 1.42; // Wheelbase length Aref 0.75; // Estimated } forceCoeffs_geom2 { // type forceCoeffs; type forces; functionObjectLibs ( "libforces.so" ); outputControl timeStep; timeInterval 1; log yes; patches ( "geometry2.*" ); pName p; UName U; rhoName rhoInf; // Indicates incompressible log true; rhoInf 1; // Redundant for incompressible liftDir (0 0 1); dragDir (1 0 0); CofR (0.72 0 0); // Axle midpoint on ground pitchAxis (0 1 0); magUInf 20; lRef 1.42; // Wheelbase length Aref 0.75; // Estimated } Code:
patches ( motorBikeGroup ); |
|
February 27, 2017, 01:32 |
|
#13 |
Member
subhankar
Join Date: May 2016
Posts: 36
Rep Power: 9 |
Hi DLuo,
Thanks for replying. It helped. I have one more problem: . When i am zooming in and try to translate using the scroll button of my mouse a deformed mesh can be seen. there is no error in the the output of checkMesh command. I haven't encountered such problem before. I am attaching snapshots of pictures without and with the use of scroll button. Can you help regarding this? regards Subhankar |
|
February 27, 2017, 11:28 |
|
#14 |
Member
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13 |
Subhankar,
You didn't post any images. This is likely a post-processor software specific issue, you did not specify which post-processor you're using. Paraview? You're likely seeing a double-precision vs single-precision graphics issue. If you're zoomed way in, such that the difference between 1e-7 and 1e-8 is visible then a postProcessor that's showing single-precision graphics will illustrate the mesh edges incorrectly. This happens all the time in pre and post processors. Also be sure that your writePrecision is high enough in your controlDict otherwise, OF will also ruin the quality of your mesh during such routines as "renumberMesh". For further questions about viewing your solutions/mesh please post in the appropriate forum for your postProcessor. |
|
February 28, 2017, 02:01 |
|
#15 |
New Member
Join Date: Jan 2017
Posts: 4
Rep Power: 9 |
Assuming you're using paraview, here are some pictures of a random old mesh I had, with a few different conditions. (1) shows the mesh with all the cuts/slices using the 'crinkle' tickbox. (2) shows the same thing with 'crinkle' unticked. (3) shows the mesh while i'm in the process of panning or zooming etc.
From the sounds of it, when you pan around, the mesh looks like (3)? I'm pretty sure that's fine as long as it's just when you're moving the camera, it's just your postprocessor coping with the amount of data it's trying to process to show you the output while moving. Another possible simple reason the mesh might look screwed up when OpenFOAM tells you it's fine is forgetting to enable the 'crinkle' option, which renders the entirety of each cell intersected, instead of chopping through them. I assume most other postprocessors have similar issues & options available. 1) http://i.imgur.com/Em1WIOZ.png 2) http://i.imgur.com/c6ErHxY.png 3) http://i.imgur.com/6eirrWU.png (as an aside, also try to avoid making cuts/slices along the boundary between two layers of cells in a structured mesh) |
|
March 3, 2017, 01:13 |
|
#16 |
Member
subhankar
Join Date: May 2016
Posts: 36
Rep Power: 9 |
Hi,
Thanks again mate. And am sorry for not attaching images last time though i am pretty sure about attaching them. Yes i am using paraview. I will look into what you referred. regards |
|
September 23, 2018, 05:33 |
|
#17 | |
Member
Ramana
Join Date: Jul 2017
Location: India
Posts: 58
Rep Power: 8 |
Hi DLuo,
This help me too. Thank you very much. Quote:
|
||
May 24, 2021, 18:11 |
more questions about forceCoeffs with multiple patches
|
#18 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 260
Rep Power: 6 |
Hi, I am studying external aerodynamics and am following a youtube video, "CFD study workflow - Ahmed". In this one, part 3, I follow the author in splitting the body (picture attached) into 3 pieces (SHMnose, SHMmid & SHMsupports) to allow better control of meshing in snappyHexMeshdict.
In part 4, he goes back to a single body for the simulation (not sure why), but I want to continue with 3 pieces. In the forceCoeffs file, I show the 3 bodies as follows: patches (SHMnose); rho rhoInf; rhoInf 1; liftDir (0 0 1); dragDir (1 0 0); CofR (0.72 0 0); pitchAxis (0 1 0); magUinf 20; lRef 1.42; ARef 0.75; patches (SHMmid); (same data) patches (SHMsupports); (same data) This runs, showing numbers for the force coefficients as it goes, but it seems to me that lRef and Aref, the characteristic dimensions, should be tailored to each patch, and I'm not sure how to sensibly do it. So I thought I would create another body, SHMsurface-volume.stl, which is the integration of the 3 separate bodies, and use it in the forceCoeffs file. This should give more believable numbers for the force coefficients. The problem is, this body is not included in the snappyHexmeshDict file, and when I run the simulation, it only gives zeroes for the force coeefficients. i have tried various ways to edit the forceCoeffs file to show a single body, with SHMsurface-volume.stl in constant/trisurface: patches (SHMsurface-volume); or patches (SHMsurface-volume.stl); or patches ("SHMsurface-volume.stl"); But in each of these approaches, the simulation only gives zeroes for the force coefficients. There must be a way to do this properly; can anyone give me a clue as to what it is? |
|
May 25, 2021, 17:22 |
|
#19 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,066
Rep Power: 26 |
Hello Alan,
As the name suggests, the "patches" parameter can take several patches. You just have to list there all the patches your need to compute the proper force coefficients. Something like this: Code:
patches (SHMnose SHMmid SHMsupports); rho rhoInf; rhoInf 1; liftDir (0 0 1); dragDir (1 0 0); CofR (0.72 0 0); pitchAxis (0 1 0); magUinf 20; lRef 1.42; ARef 0.75; Cheers, Yann |
|
May 27, 2021, 11:54 |
forceCoeffs question
|
#20 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 260
Rep Power: 6 |
Thank You Yann,
Another logjam broken! I remain indebted to you! Alan w |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Foam::error::PrintStack | almir | OpenFOAM Running, Solving & CFD | 91 | December 21, 2022 04:50 |
how to set periodic boundary conditions | Ganesh | FLUENT | 15 | November 18, 2020 06:09 |
Forces on multiple patches in InterDyMFoam | Claudio | OpenFOAM Post-Processing | 5 | October 20, 2016 12:46 |
Regarding periodic BC in ICEM generated grid | Tarak | OpenFOAM | 32 | April 30, 2013 14:46 |
Forces printout for multiple patches | ozzythewise | OpenFOAM Pre-Processing | 3 | March 7, 2012 12:59 |