CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (https://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   forces / forceCoeffs on Multiple Patches (https://www.cfd-online.com/Forums/openfoam-post-processing/141482-forces-forcecoeffs-multiple-patches.html)

seb_210 September 9, 2014 04:22

forces / forceCoeffs on Multiple Patches
 
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

DLuo September 11, 2014 14:54

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.

seb_210 September 12, 2014 04:14

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

seb_210 September 16, 2014 11:59

Anybody else ? :D

Thanks

Seb

DLuo September 16, 2014 13:26

1 Attachment(s)
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.

seb_210 September 17, 2014 04:17

Allright,

I tried your files and I still get the same result. :confused:
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

DLuo September 17, 2014 13:39

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

seb_210 September 18, 2014 05:55

2 Attachment(s)
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

DLuo September 19, 2014 00:33

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.

wyldckat September 21, 2014 13:15

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

SUBHANKAR February 22, 2017 09:43

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

DLuo February 22, 2017 15:05

Sample ForceCoeffs
 
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 );

SUBHANKAR February 27, 2017 01:32

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

DLuo February 27, 2017 11:28

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.

j91 February 28, 2017 02:01

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)

SUBHANKAR March 3, 2017 01:13

2 Attachment(s)
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

svramana September 23, 2018 05:33

Hi DLuo,
This help me too. Thank you very much.

Quote:

Originally Posted by DLuo (Post 638119)

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.


boffin5 May 24, 2021 18:11

more questions about forceCoeffs with multiple patches
 
1 Attachment(s)
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?

Yann May 25, 2021 17:22

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

boffin5 May 27, 2021 11:54

forceCoeffs question
 
Thank You Yann,
Another logjam broken! I remain indebted to you!
Alan w


All times are GMT -4. The time now is 13:47.