CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Post-Processing

forces / forceCoeffs on Multiple Patches

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

Like Tree2Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 9, 2014, 04:22
Question forces / forceCoeffs on Multiple Patches
  #1
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 9
seb_210 is on a distinguished road
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
seb_210 is offline   Reply With Quote

Old   September 11, 2014, 14:54
Default
  #2
Member
 
D L
Join Date: Jun 2012
Posts: 44
Rep Power: 11
DLuo is on a distinguished road
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.
DLuo is offline   Reply With Quote

Old   September 12, 2014, 04:14
Default
  #3
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 9
seb_210 is on a distinguished road
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.
seb_210 is offline   Reply With Quote

Old   September 16, 2014, 11:59
Default
  #4
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 9
seb_210 is on a distinguished road
Anybody else ?

Thanks

Seb
seb_210 is offline   Reply With Quote

Old   September 16, 2014, 13:26
Default
  #5
Member
 
D L
Join Date: Jun 2012
Posts: 44
Rep Power: 11
DLuo is on a distinguished road
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.
Attached Files
File Type: zip forceCoeffs.zip (1.1 KB, 217 views)
DLuo is offline   Reply With Quote

Old   September 17, 2014, 04:17
Default
  #6
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 9
seb_210 is on a distinguished road
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
seb_210 is offline   Reply With Quote

Old   September 17, 2014, 13:39
Default
  #7
Member
 
D L
Join Date: Jun 2012
Posts: 44
Rep Power: 11
DLuo is on a distinguished road
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
DLuo is offline   Reply With Quote

Old   September 18, 2014, 05:55
Default
  #8
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 9
seb_210 is on a distinguished road
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
Attached Images
File Type: jpg paraFoam patch.jpg (32.3 KB, 202 views)
Attached Files
File Type: zip files.zip (5.2 KB, 28 views)
seb_210 is offline   Reply With Quote

Old   September 19, 2014, 00:33
Default
  #9
Member
 
D L
Join Date: Jun 2012
Posts: 44
Rep Power: 11
DLuo is on a distinguished road
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.
DLuo is offline   Reply With Quote

Old   September 21, 2014, 13:15
Default
  #10
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,965
Blog Entries: 45
Rep Power: 126
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
__________________
wyldckat is offline   Reply With Quote

Old   February 22, 2017, 09:43
Default
  #11
Member
 
subhankar
Join Date: May 2016
Posts: 35
Rep Power: 7
SUBHANKAR is on a distinguished road
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
SUBHANKAR is offline   Reply With Quote

Old   February 22, 2017, 15:05
Default Sample ForceCoeffs
  #12
Member
 
D L
Join Date: Jun 2012
Posts: 44
Rep Power: 11
DLuo is on a distinguished road
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
}
Particularly note the entry for Patches, it's the prefix in quotation marks with a .* at the end. This is the old way (OF2.X) way of doing things but it should still be valid in OF3.X You may want to try to dig in the motorBike tutorial to see how they're specifying groups since the tutorial actually uses

Code:
 patches     ( motorBikeGroup );
DLuo is offline   Reply With Quote

Old   February 27, 2017, 01:32
Default
  #13
Member
 
subhankar
Join Date: May 2016
Posts: 35
Rep Power: 7
SUBHANKAR is on a distinguished road
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
SUBHANKAR is offline   Reply With Quote

Old   February 27, 2017, 11:28
Default
  #14
Member
 
D L
Join Date: Jun 2012
Posts: 44
Rep Power: 11
DLuo is on a distinguished road
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.
DLuo is offline   Reply With Quote

Old   February 28, 2017, 02:01
Default
  #15
j91
New Member
 
Join Date: Jan 2017
Posts: 4
Rep Power: 7
j91 is on a distinguished road
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)
j91 is offline   Reply With Quote

Old   March 3, 2017, 01:13
Default
  #16
Member
 
subhankar
Join Date: May 2016
Posts: 35
Rep Power: 7
SUBHANKAR is on a distinguished road
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
Attached Images
File Type: jpg Screenshot from 2017-02-22 17-17-49.jpg (193.2 KB, 84 views)
File Type: jpg Screenshot from 2017-02-22 17-17-55.jpg (163.1 KB, 58 views)
SUBHANKAR is offline   Reply With Quote

Old   September 23, 2018, 05:33
Default
  #17
Member
 
Ramana
Join Date: Jul 2017
Location: India
Posts: 58
Rep Power: 6
svramana is on a distinguished road
Hi DLuo,
This help me too. Thank you very much.

Quote:
Originally Posted by DLuo View Post

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.
svramana is offline   Reply With Quote

Old   May 24, 2021, 18:11
Default more questions about forceCoeffs with multiple patches
  #18
Senior Member
 
Alan w
Join Date: Feb 2021
Posts: 148
Rep Power: 3
boffin5 is on a distinguished road
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?
Attached Images
File Type: png ahmedbody.png (35.3 KB, 5 views)
boffin5 is offline   Reply With Quote

Old   May 25, 2021, 17:22
Default
  #19
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 439
Rep Power: 17
Yann is on a distinguished road
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
Yann is offline   Reply With Quote

Old   May 27, 2021, 11:54
Default forceCoeffs question
  #20
Senior Member
 
Alan w
Join Date: Feb 2021
Posts: 148
Rep Power: 3
boffin5 is on a distinguished road
Thank You Yann,
Another logjam broken! I remain indebted to you!
Alan w
Yann likes this.
boffin5 is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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 Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to set periodic boundary conditions Ganesh FLUENT 15 November 18, 2020 06:09
Foam::error::PrintStack almir OpenFOAM Running, Solving & CFD 90 October 3, 2019 07:01
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


All times are GMT -4. The time now is 00:49.