[HakikiCanakkaleli]

I attached syntactically updated version of the tool, which could be compiled with OF1612+.

Without warranty of any kind, of course. :]

PS: In contrast to 'postChannel's collapsing fields onto a line, 'postSpanwiseAverage' returns volScalarFields of the size of the entire computational grid. Yet, each slice of computational domain's fields in the homogeneous direction is the same. Then, therefore, it is your responsibility to sample the fields onto whatever shape you want.

[agustinvo]

Hello

how does it work, this tool? I remember that there was one around the forum that provides you the nodes values, not the cell ones.

For the moment, what I do is to add in my control dict some surfaces definition, and then I average them using Python. Maybe it would be easier with PyFOAM, but I have no idea about it.

[HakikiCanakkaleli]

Your question is ambiguous to me, I'm afraid. What do you mean by 'how does it work, this tool?': you want to know how to use the tool or how the tool performs its assigned task?

[benqing]

Originally Posted by syavash

Nice job Gregory! But I think your code may ignore some cells when trying to match x and y coordinates. I have applied your routine to my case, a 3-D channel homogeneous is z direction.
I could get a nice smooth field of velocity, but when noting the legend bar, I could see that the velocity range is half of that which should be!!
Actually, I have developed a similar utility/code for Ansys Fluent and it also suffers from the same issue.
Due to writing precision of the grid generator tool (Gambit and ICEM CFD in my case), not the entire cells aligned in z direction have THE EXACT similar x and y coordinates. So, it is normal that the code ignores some cells and their contributions to the velocity field are neglected.
For fixing this problem, I introduced a tolerance factor in my case which somewhat improved span-wise averaging.
Can you do the same in your routine?

P.S.: Is it possible to include pressure field as well??

Regards,
Syavash

Hello Syavash
I met the same question ,when used Gregory's utility,but "velocity range is half of that which should be!!",did you slove this problem?

Regards,
benqing

[syavash]

Originally Posted by benqing

Hello Syavash
I met the same question ,when used Gregory's utility,but "velocity range is half of that which should be!!",did you slove this problem?

Regards,
benqing

Hi Benqing,

Did you use postSpanwiseAverage tool? I found it very helpful.

Regards,
Syavash

[benqing]

Originally Posted by syavash

Hi Benqing,

Did you use postSpanwiseAverage tool? I found it very helpful.

Regards,
Syavash

I get it ,thank you!

Regard,
Benqing

[arnaupont]

Hi everybody,

I think that this tool can be useful for those who are interested in this post.
https://github.com/arnaupv/avgCyclicDir (version 0.9.0).

Main features:
* OpenFoam v1706.
* Cyclic direction is automatically detected.
* It averages all *Mean files (accepts any kind of field).
* A mesh with a unique control volume in the cyclic direction is created. So, sampling tools can be used without problems).
* Fields are saved in postPorcessing/avgCyclicDir/

Main shortcomings:
* Only one cyclic direction is currently allowed.
* Patches are not included (set to 0 by default).
* Sequential (not parallelized).
* The mesh must be structured in the cyclic direction.

As it can be seen in the GitHub repository, the tool is underdevelopment but the results are pretty good! I will highly appreciate your comments and help for addressing the current shortcomings.

I hope it helps!

Arnau

[whhjken1]

Hi Arnau,

The avgCyclicDir utility that you developed is just what I need in postProcessing LES results of a turbulent pipe flow. However, there are some errors when I compiled your code, which I believe is due to the syntactics because my OpenFOAM is version 4.0. So I was wondering if you could test other versions of OpenFOAM and make relevant modifications to your codes. Thanks a lot.

Han

[HPE]

IMHO,

The new OpenFOAM utilities such as:

columnAverage

patchEdgeSet

might be used for spanwise averaging channel-like flow statistics.

[Bazinga]

Originally Posted by HPE

IMHO,

The new OpenFOAM utilities such as:

columnAverage

patchEdgeSet

might be used for spanwise averaging channel-like flow statistics.

Yes, thank you!

The other user-provided tools did not work for me (of6) but the columnAverage function executed by of1906 for of6 cases works like a charm.

edit: i realized that it does indeed work for U and p. However, if I try to average fields such as Q or vorticitiy I get an error saying the fields are not found. Any idea how to fix this issue?

[whhjken1]

Originally Posted by whhjken1

Hi Arnau,

The avgCyclicDir utility that you developed is just what I need in postProcessing LES results of a turbulent pipe flow. However, there are some errors when I compiled your code, which I believe is due to the syntactics because my OpenFOAM is version 4.0. So I was wondering if you could test other versions of OpenFOAM and make relevant modifications to your codes. Thanks a lot.

Han

Hi Foamers,

Arnau has updated the original codes to other versions of OpenFOAM. I tested it using my LES results on the heat transfer of supercritical fluids in a circular pipe under OpenFOAM 4.x and 6, it works pretty well in these two versions. It is highly recommended to use this tool in postProcessing the spanwise averaging of flow or temperature field in cylinder coordinate.

Han

[HPE]

Originally Posted by Bazinga

edit: i realized that it does indeed work for U and p. However, if I try to average fields such as Q or vorticitiy I get an error saying the fields are not found. Any idea how to fix this issue?

Have you executed 'Q' or 'vorticity' function objects before executing 'columnAverage'?

[Bazinga]

Originally Posted by HPE

Have you executed 'Q' or 'vorticity' function objects before executing 'columnAverage'?

Yes. I can see them in e.g. Paraview. However, columnAverage pretends that it can not find them.

[HPE]

No, I meant this: in controlDict, did you execute the function objects in that order?

functions
{
    #include "vorticity"
    #include "columnAverage"
}

but not

functions
{
    #include "columnAverage"
    #include "vorticity"
}

[Bazinga]

I did not. IIRC I added Q and vorticity to the time directories by something like "pimpleFoam -postProcess -func Q" in the terminal. I'll check your approach and come back to this thread during the weekend.

Thanks for your help!

[Bazinga]

The suggestion above works for vorticity and Q.

There is only one more challenge: The columnAverage seems to average for each half of the span-wise direction, i.e., I get an averaged field till the half length of my cylinder, after which a second averaged field for the remaining half is shown. This happens for all values, also p, U etc.

Any ideas? I can upload my files in necessary of course.

[HPE]

Could you please upload your cases for the reproduction?

[Bazinga]

Sure, here it is

https://www.dropbox.com/sh/wnwqum10if415bs/AADAj-0HM77k2HyKgv_dvI8Ia?dl=0

Its like 1.2 GB. In the 33 time directory I zipped the results of the following command

pimpleFoam -postProcess -latestTime

You can also see a screenshot from Paraview where I am showing the pressure averaging.

Thanks for your help!

[HPE]

Curious.

On the other hand, `postProcess` utility does not contain `columnAverage` yet. If you execute `postProcess -list` command, you will see that `columnAverage` is not there. So it should not affect `columnAverage` results. Or did it?

Since you have the `columnAverage` fields, and I took a slice downstream of the cylinder, and you are right: There is an asymmetric pattern.

This utility AFAIK is experimental, and community supported. Would you mind to issue a ticket in the bug tracker: https://develop.openfoam.com/Develop...AM-plus/issues

EDIT: A minimal working example would be great.

EDIT-2: If this is not possible for you, I may pursue this issue in the medium term.

[Bazinga]

Originally Posted by HPE

Curious.

On the other hand, `postProcess` utility does not contain `columnAverage` yet. If you execute `postProcess -list` command, you will see that `columnAverage` is not there. So it should not affect `columnAverage` results. Or did it?

Since you have the `columnAverage` fields, and I took a slice downstream of the cylinder, and you are right: There is an asymmetric pattern.

This utility AFAIK is experimental, and community supported. Would you mind to issue a ticket in the bug tracker: https://develop.openfoam.com/Develop...AM-plus/issues

EDIT: A minimal working example would be great.

EDIT-2: If this is not possible for you, I may pursue this issue in the medium term.

Dear HPE,

Thanks for the help. I should find some time during the weekend and come back to this thread afterwards.