[seb_210]

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]

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]

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]

Anybody else ?

Thanks

Seb

[DLuo]

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]

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

[DLuo]

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]

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]

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]

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]

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]

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.

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

 patches     ( motorBikeGroup );

[SUBHANKAR]

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]

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]

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]

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]

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

Originally Posted by DLuo

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]

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]

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:

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]

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