Volume Average for magnitude U
Hi,
I am using simpleFunctionObject to average some fields in volume. I can do this for simple filelds like T. for instance I add the following code into controlDict file: Quote:
How can I do that? any suggestions? |
Quote:
Code:
functions An alternative would be to construct a separate field: Code:
functions |
Hi Bernhard and thanks for your useful answer. there is problem I have while running my case. When I use your second code in controlDict File, I get the following error message in openFOAM:
Quote:
Quote:
|
Sorry. I should have said that I wrote the examples without testing them:
Quote:
ls $FOAM_USER_LIBBIN/libswakFunctionObjects.so if it really exists. Quote:
valueType internalField; BTW: this is generally applicable for working with OpenFOAM: if it is complaining about a missing entry then add that entry (in this case valueType) and then use the "banana trick": http://openfoamwiki.net/index.php/Op...de/Use_bananas |
Quote:
Quote:
|
Quote:
Quote:
|
1 Attachment(s)
Quote:
I have attached the log file of recompilation. |
Quote:
Also go to Libraries/Allwmake and in the first line replace /bin/sh with /bin/bash |
Quote:
Bernhard is there any way to define a new volume to calculate averages in this specified volume? |
Quote:
Specification of zones and set is either done in the mesh generator or with the topoSet (or the setSet)-utility. But the usage of those has nothing to do with swak4Foam (except that swak provides topoSources based on expressions) |
Quote:
|
Quote:
|
Quote:
|
Hey,
I am sorry to bring this up again, but I experience problems with the described way of calculating the average mag(U) over a plane. I have a simple pipe (flow is 12m/s with air, laminar, no turb model yet) and added the following to my controlDict: Code:
functions Code:
# Source : sampledSurface sampledSurface What did I do wrong here? I thought my lines to the control dict would just create a field mag(U) out of the calculated U vector field and then place a slice through it and calculate an average. Is it possible that the SWAK-code leaves out cells with a mag(U) value of 0 for some reason? My mesh is pretty rough, so a high percentage of the cells actually has the wall boundary condition of U = (0 0 0). I found out that my average values for pressure seem to be perfectly fine (SWAK sampling and manual paraView pp lead to the exact same numbers)! So its only a mag(U) thing here... |
Quote:
What you can do to check is: - set autowrite for magU to true and check it in Paraview - emulate the area-weighted average in with a swakExpression on the same sampledSurface (I think the expression would be "mag(U)*area()/sum(area())" with an accumulation sum) |
Hey,
Great thanks for your quick reply! I checked the magU field, slicing and integrating it in a paraView leads to 12.05 m/s, so the field data actually seems to be ok! The problem seems to be the sampled Surface (as you suggested). But is it a user fault or a bug? I tested the same function object in different cases, the results for velocity were always a bit higher than expected and they differ from those obtained in paraView up to 20%. The results from paraView always seem more accurate to me (considering my expectations/boundary etc). As it is working out for the pressure field perfectly, I would say the sampled Surface is defined and adressed correctly, there must be something in the way this deals with the mag(U) field. Because I am only a user (and student), I lack the knowledge to understand the problem. I try to make use of your second advice but i struggle with the code. I put an update here asap. # "keyword weightField is undefined" , lets see if I can find out where I have to initialise this one # okay, i think i figured out the place for the code #okay i was wrong! |
Quote:
If the problem is in the sampledSurface-code then it will affect swak too. If it is in the faceSource-code ... not Quote:
Code:
createPlane Clearer? |
Big thanks,
with this code I can observe the mag(U) value on a self defined plane for each time step! Wonderful! This was very helpful. Unluckily the behaviour is the same like the other function object Greetings, Simon |
So I tried with your work around as well:
Code:
# Time sum With every timestep the difference between the actual field values and the processed average becomes bigger. I use Ubuntu 12.04, OF 210 and compiled SWAK 1 month ago so it should be up to date i guess, although I dont know exactly how can i verify this. |
Quote:
If you feel like giving back it would be nice if you consider adding this as a little recipie on the openfoamwiki.net (either on the swak-page or linked from it) Quote:
- check if the area of the surface is as expected (calculate "area()" with an accumulation "sum" on the surface). But that would be too easy - use the sample-utilitiy to write VTKs of the surface and check in Paraview whether the values there are the same as the ones you get when cutting the volume data in paraview |
All times are GMT -4. The time now is 09:51. |