|
[Sponsors] |
Run-time postprocessing - incorrect flow rate through faceZone |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
October 3, 2013, 07:45 |
Run-time postprocessing - incorrect flow rate through faceZone
|
#1 |
Member
Daniel Pielmeier
Join Date: Apr 2012
Posts: 99
Rep Power: 14 |
Hello,
I try to post-process the flow rate through different faceZones. The solver is simpleFoam and the mesh consists of mostly hexaeders, difficult geometric areas are meshed with tetraeders. There is one inlet (turbulent flow profile created with groovyBC) which splits into two separate channels and combines again. This happens three times in total and afterwards there is an outlet (fixed pressure). geo1.jpggeo2.jpggeo3.jpg Above pictures show the geometry with the flow direction and the position of the faceZones for evaluating the flow rate. Due to the flow not approaching symmetrical before the split I expect a different flow rate in the splits. However the sum should always be the flow rate of the inlet. What I get now is correct sums for the splits 3+4 and 5+6 but the sum for the split 1+2 is only about 75% of the total flow rate. flow_rate.png From the picture above it is clearly visible that split 1+2 are misbehaving in some way as they should be both in the same range (3e-5) like the other four splits. I tried postprocessing with swakExpression (swak4foam) and OpenFOAM's fieldFunctionObjects but the results are the same. So I assume there must be something wrong with the mesh. I deleted parts of the mesh around the faceZones and remeshed them which gave me correct values for other splits but wrong ones which were correct before. The mesh was created by Hypermesh and exported to OpenFoam format. I had the same problems when exporting to fluent format first and converting the mesh using fluent3DMeshToFoam. I have no clue how to debug this. Maybe someone can give me a hint. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Transient simulation not converging | skabilan | OpenFOAM Running, Solving & CFD | 14 | December 16, 2019 23:12 |
High Courant Number @ icoFoam | Artex85 | OpenFOAM Running, Solving & CFD | 11 | February 16, 2017 13:40 |
dynamic Mesh is faster than MRF???? | sharonyue | OpenFOAM Running, Solving & CFD | 14 | August 26, 2013 07:47 |
same geometry,structured and unstructured mesh,different behaviour. | sharonyue | OpenFOAM Running, Solving & CFD | 13 | January 2, 2013 22:40 |
Velocity of flow v time | MitsubishiEvo6 | FLUENT | 0 | August 30, 2012 23:51 |