[anne]

Hello,

I write you again about the same topic,
sorry to insist but I really need to know if there is any function that
can be applied for computing the average in
an honogeneous direction.
I know the postChannel uitlity bt what I need
is to aplly an average only to one homogeneous direction.

I have tried the average function but the way I used it returns me
a scalar value that corresponds to the
global average over all the pints of the my domain.



I take advantage also to ask if the avarage function used in the dynamicSmagorinsky
also operates a global average or only in the
homogeneous directions.

Please could you give this information and help me
to do this task,

Thanks


anne

[villet]

Anne, have you already found an answer to your problem?

I've been working on the dynamic closure for variable-density LES solver combined with presumed-PDF model (Pierce & Moin). The global average gives only one value for the dynamic coefficients (subgrid turbulent stress, scalar flux etc.) in the whole domain.

The problem is that my implementation with the global averaging gives negative values for the dynamic coefficients. Partially it is caused by the different model where k (and two dynamic coefficients) are not computed like in OpenFOAM dynSmagorinsky.

Anyway, I would like to test the homogeneous average before trying the localized version. Averaging the dynamic coefficients in the homogeneous direction is easy in structured grid codes, but how could it be done in OpenFOAM?

[maka]

To my knowledge, averaging a field in homogeneous directions at run time is not implemented. This is because the implementation of such feature need to work in parallel.

Best regard,
Maka.

[villet]

Thanks Maka for your answer! I was thinking more about the averaging and since I don't have any homogeneous directions in my cases, I should concentrate on localized models.

[fcollonv]

Hello,

I created a post-processor that could compute the average to one homogeneous direction. I can provide it if you're still interested. However, there is a two main restrictions : first as it's a post-processor, it uses only the output data and secondly, it works only on structured grid.

Best regards,

Fred

[cfdmarkus]

Hi Fred,

I am very interested in your tool to compute the homogeneous average in one direction. I would highly appreciate if you could provide me with the source code. Could you post the files here on the forum or send it directly to me mw405@soton.ac.uk ?

Thanks a lot
Markus

[fcollonv]

Hi Markus,

Please find attached with this post the code source of the post-processor (AverageHomogeneousDirection.zip) and a test case (testWallMean.zip). The source code contains a README file for more details but if you have some questions or suggestions, don't hesitate to contact me.

Frederic

PS : the test case is a simple 3D model that contains an artificial volScalarField called 'value'. This field is set by hand like that you could easily verify how the post-processor works. But if you could test it on others artificial case, that'll be nice.

[sega]

I really would like to test your tool, but I need some further information, because I didn't get the meaning of the input parameters.

I'm currently investigating the velocity field in a square duct, which means I have four walls enclosing the flow with cyclic in- and outflow bc's.

Your README reads:

startPoint : First point near the wall that defines the first studied elevation
and the first value of the field near the wall
normalWall : (optional) define the direction normal to the wall (0=x, 1=y
(default), 2=z)
elevation : (optional) define the direction normal to the studied profile (0=x,1=y, 2=z (default))

I'm not sure what is meant by "studied elevation" and "first value of the field near the wall".

And what about the normalWall direction?
Well, it's optional but what happens if there are four different walls with different normal directions, with two of their normals facing in oposite x,y or z-direction?

[fcollonv]

Sorry, it's true that I forget to explain the context of my work.

So I study the thermal boundary layer. Here is a example of the result :
explain.jpg

My goal is to obtain the evolution of temperature and velocity in the x direction for different values of z and y is the homogeneous direction.

The results are some profiles like those one : profile.jpg

In fact, the post-processor compute the profiles of specified field for each cells above the cell containing the startpoint (this cell is included too). So in my example, as there is 40 cells in the z-direction. The results will be 40 profiles. If you choose the start point at z = 10 cm (and not z = 0 cm as it is on the drawing), only 20 cells are above the startpoint in the z-direction. So the results will be 20 profiles.
In my case if the startpoint have a x-component non equal to zero, the resulting profiles will be non complete because it compute the point only in the positive direction from the startpoint.
That could be usefull for the square tube. Because of the symetry, maybe you want only from the wall to the peak center. So you could put the startpoint in the middle of the square. Like that, the output will be some profiles from the center to the top wall and each profile begin with the peak value.

If you want more precision or if you want me test your case, don't hesitate to ask.

Frederic

[fs82]

Hello Frederic,

I tested your averaging tool, but I get a segmentation fault. I have a flow around a cylinder with a periodic boundary in spanwise direction. And for postprocessing I need to average the periodic direction. I am not really sure what you mean by structured grid, so may be this is the reason for the failure of your tool in my case.

Grettings,
Fabian

[fcollonv]

Hello Fabian,

I wrote the code for hexahedron cells. So the trouble is certainly linked with the fact that your homogeneous direction is not a straight line but an arc.
For the error, I received that error during the code debugging. Most of the time, it was due to an incorrect index (for example the index was greater than the size of the array). But that could come from an incompatibility with the version that you use (I use the version 1.5).

The error occurs certainly in the function extractLineCell (line 224 to 329 in wallIndex.C) or in xi (line 331 to 360 in wallIndex.C).
Also as I never use a cylinder, I don't know how OpenFOAM manage the coordinates. Does OpenFOAM use equations in cylindric coordinates or still the x,y,z?

Best regards,

Frederic

[fs82]

Hello Frederic,

I investigated your source code and localized the error exactly at the position you have written above. I am 99% sure that the second extractLineCell function produced strange values in cellsList. But if I understand your code right, the cylinder case should be no problem. I still have kartesian coordinates (x,y,z) and there is no arc in my homogenous direction. I want to average over the spanwise direction of the cylinder. So I do not really understand why there is a problem ... but I have to say, I am not very familiar with the C++ language. So I dont understand the extractLineCell function in detail. Also there should be no incompatibility with the OpenFoam Version, because I use 1.5 too.

[fcollonv]

Hello,

I created a new function from scratch allowing to compute the average in a homogeneous direction.
The sampledPlane is used as basic plane to cut the domain but instead of returning the value on the plane, the average is projected on the plane.

So how it's working, you define the plane normal to the homogeneous direction at the begin of your domain and the end of this one(for example if the homogeneous direction is Z and Z varies from 0.0 to 0.1, you define the plane by :
basePoint (0 0 0);
normalVector (0 0 1);
endOfDomain 0.1;
)
Then the function extract using the class uniformSet a line from each face of the plane in the homogeneous direction. The value of the face is set with the average of the field on this line.

Finally the plane is written on the wishing format.

Advantages in comparison with the previous tool :
- easier
- a single surface is output, so easier to post-treat after
- works with all geometry
- two ways of using :
* as a functionObject during the runTime
* as a post-processor using the utility "sample"

Limits :
- developed under 1.6, not tested under 1.5
- trouble if the number of points uses to calculate the average is too low, boundary interpolation could introduce errors

More help in the archive file as well as an example of the controlDict and one of the sampleDict

Don't hesitate to test it and send me your comments.

Best regards,

Frederic

[fs82]

Hello Frederic,

thx a lot that you try to fix my problem. After spending two days of work on this topic, I decided to use tecplot. I now sample the same line for different z-positions and average this with tecplot. This works quite good and is reliable. I need the averages just for comparison to an article and to adjust my OpenFoam setting for the cylinder les. But I want to test OpenFoam 1.6 in a while, so I will test your scipt with the new version of OpenFoam.

kind regards,

Fabian

[cfdmarkus]

Hi Frederic,

thanks for providing this great tool to everyone. I have tested it with OF1.6 and it seems to work for the channelFOAM tutorial case.

However, I was hoping you could help me to clarify two things:
First, does the parameter nPoints correspond to the number of grid point in the homogeneous direction, or is it an arbitrary number?
Secondly, at the moment I get the averaged 2d surface. Do you know if it is possible to use the sample utility to extract data along a line from this 2d surface?

Best regards
Markus

[fcollonv]

Hello Markus,

Originally Posted by cfdmarkus

First, does the parameter nPoints correspond to the number of grid point in the homogeneous direction, or is it an arbitrary number?

The uniformSet is using to extract lines in the homogeneous direction. The constructor of that function is :
uniformSet
( const word & name, // name of the object
const polyMesh & mesh, // mesh
meshSearch & searchEngine, // mesh search engine
const word & axis, // direction of the line
const point & start, // start point
const point & end, // end point
const label nPoints // number of points extract from the mesh by
// this object
)
The nPoints parameter used in the dictionary is equal to the nPoints parameter of the uniformSet constructor. So as the average is computed from the value of the fields at the points extracted by uniformSet, nPoints has to be at least equal to the number of grip points. From my tests, a bigger number seems even better (not too big because you can generate a floating point error).

Originally Posted by cfdmarkus

Secondly, at the moment I get the averaged 2d surface. Do you know if it is possible to use the sample utility to extract data along a line from this 2d surface?

I don't think so. For my case, I use the .vtk output format for the surfaces. Then I extract lines with paraview:
1. open the .vtk file
2. Filters -> Data Analysis -> Plot Over Line
3. Define the line that you want to extract
4. File -> Save Data (CSV File is nice if you plan to use Excel or Matlab)


If you have others questions or want some precision, don't hesitate to ask.

Best regards,

Frederic

[cfdmarkus]

Hi Frederic,

I have successfully employed your sampledAveragePlane function in the past.
However, for the case I am work on at the moment, I cannot get it to work ( tandem cylinder configuration).

After evaluating the average in some points in the flow field, the sample utility stops responing since the sampledAveragePlane function cannot extract the line in the homogeneous direction. I have debugged the code and found that the problem occurs at this line:

// Extract the line in the homogeneous direction
uniformSet line("homogeneousLine", mesh(), searchEngine, axis_, points()[pointI], endPt, nPoints_);

Do you have any ideas why the above command may fail in my case?
Any suggestions are appreciated since I am stuck here!

Best regards
Markus

[markusrehm]

Hello Frederic,

I tested you tool and it works fine. Thank you very much.
But I still did not achieve what I really need. I want to post-process the average of a variable at a plane with probeLocations or something else. So I want time versus average-X. Do you know if I can use your tool in the probesDict - up to now I can only probe points.

That is a part of my probesDict:

// Fields to be probed. runTime modifiable!
fields
(
AR
);

// Locations to be probed. runTime modifiable!
probeLocations
(
(0.001 0.001 0.0)
(2.88 0.001 0.0)

);



Regards, Markus.

[Pepi]

Hello Frederic,

I was wondering if your solver works with OF 1.5.x. I did something wrong while installing it on OF 1.6.

Thanks,
Pedro

[Pepi]

Hello Frederic,

I was wondering if you could provide me with some help. I am trying to the function you created but I don't really know the changes I should do in the Make/files directory.

Any help will be truly appreciated.

Pedro