|
[Sponsors] |
viewFactorsGen produces incorrect view factors in a very thin gap |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
Formulation
The problem I am going to talk about was examined in the thread chtMultiRegionSimpleFoam: Thermal Conduction + Surface-To-Surface Radiation in a quite broader context. This thread is all about one particular aspect of the problem - the way utility viewFactorsGen works. A sketch of the simulation domain: ![]() Simple heat conduction equation is solved in all regions. In addition, thermal radiation is modeled in the central region cellZone_2, with the radiation model being viewFactor (some sources refer to it as surface-to-surface radiation). Well, consider 3 cases distinguished from another only by the width of the central region (cellZone_2 in the picture): 1 mm, 10 mm, and 100 mm. The units are unimportant here; it’s the order of magnitude that is really relevant to the problem. Characteristic size of mesh cells is 10 mm for all the cases in question. Results Region width 1 mm ViewFactorsGen output: Code:
F00: 0 F01: 24.05267 F10: 21.62112 F11: 0.01200849 ![]() Region width 10 mm ViewFactorsGen output: Code:
F00: 0 F01: 1.01395 F10: 0.8505047 F11: 0.1242975 ![]() Region width 100 mm ViewFactorsGen output: Code:
F00: 0 F01: 1.001733 F10: 0.2489729 F11: 0.7506583 ![]() As you can see, in case 1 (region width 1 mm) view factors are totally wrong. The error is enormous! The results in case 2 are tolerable but there are some faces with values as low as 0.74 (not good at all). The last case (100 mm) looks OK! The question is Why? Last edited by wyldckat; February 21, 2016 at 16:09. Reason: repaired link |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
Quick question: Can you provide the test case(s) that you've used for reproducing these results?
I ask this because if we use Google with following search string: Code:
site:openfoam.org/mantisbt "viewFactorsGen" Therefore, if you can provide these test cases, along with these details that you've provided, than it's also probably best to report this on the bug tracker: http://www.openfoam.org/bugs
__________________
|
|
![]() |
![]() |
![]() |
![]() |
#3 | |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
Quote:
The simulation case can be downloaded from: https://drive.google.com/file/d/0Bz9...ew?usp=sharing "mesh" folder contains 3 sub-folders with mesh files. Run in terminal: Code:
star4ToFoam -ascii -solids mesh/001mm/star // mesh/001mm/star or mesh/010mm/star or mesh/100mm/star splitMeshRegions -cellZonesOnly -overwrite Code:
faceAgglomerate -region cellZone_2 -dict constant/viewFactorsDict > log.faceAgglomerate.$i 2>&1 viewFactorsGen -region cellZone_2 > log.viewFactorsGen.$i 2>&1 |
||
![]() |
![]() |
![]() |
![]() |
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
Hi Sergei,
Many thanks for the cases and the details on how to use them! And for reporting this on the bug tracker! Hopefully I'll be studying this week the ins and outs of Radiation in OpenFOAM at work and hopefully I'll start getting a better notion of what's going on here. I already have a feeling that the issue is related to the view factors being designed to work with a uniform mesh, but I still need to double-check if this is the case in the code itself. For example, it's possible that the view factors are currently designed to be calculated before generating the boundary layer mesh. Best regards, Bruno
__________________
|
|
![]() |
![]() |
![]() |
![]() |
#5 | |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
Quote:
It would be really nice of you If you could resolve the issue. Looking forward to hearing from you on the progress. |
||
![]() |
![]() |
![]() |
![]() |
#6 |
Senior Member
Derek Mitchell
Join Date: Mar 2014
Location: UK, Reading
Posts: 172
Rep Power: 13 ![]() |
Has anything moved forward on this one. My application has 10mm fluid between plates with heat sources (honey bee comb) and ran into similar errors
__________________
A CHEERING BAND OF FRIENDLY ELVES CARRY THE CONQUERING ADVENTURER OFF INTO THE SUNSET |
|
![]() |
![]() |
![]() |
![]() |
#7 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
Hi, Derek. The algorithm incorporated into an OF viewfactor generator can't handle well cases with closely spaced surfaces. It scans trough patch faces taken part in thermal radiation and determines the visibility relationship between every pair of faces. Then it calculates a view factor based on a well known double-integral relation. Being a one point integration this scheme doesn't perform well. A big improvement can be achieved by swiching from a doulble surface integral to a coutour intergal (using Stokes theorem) and inplementing a multi-point integration (e. g. Gaussian integration).
Another shortcoming of a built-in algorithm is that it doesn't account for a partly visible faces (some other face can intercept between a pair of faces in consideration). A simple (but highly non-effective) way to overcome this is to subdived every face into a number of subfaces and check the visibility among subfaces not the original faces. I made some basic improvements to the code but they are really raw and don't live up to high coding standards. There's a lot to do before you can use view factor generator confidently. I wish someone who is really proficient in code development took an effort and refactored view factor generator to the extent where we all can use it safely. |
|
![]() |
![]() |
![]() |
![]() |
#8 | |
Senior Member
Derek Mitchell
Join Date: Mar 2014
Location: UK, Reading
Posts: 172
Rep Power: 13 ![]() |
Quote:
I've tried contacting the authors but no success
__________________
A CHEERING BAND OF FRIENDLY ELVES CARRY THE CONQUERING ADVENTURER OFF INTO THE SUNSET |
||
![]() |
![]() |
![]() |
![]() |
#9 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
Yes, I've seen that article. The authors suggested that one should switch from surface integration to line integration as I described in my previous post. I did so and it made view factor calculation more accurate indeed. I used a parallelepiped as a test case varying the distance between its sides and the improvements were obvious. But the are not enough. Face interference is not accounted for properly. That's the problem.
|
|
![]() |
![]() |
![]() |
![]() |
#10 |
Member
Join Date: Sep 2014
Location: Germany
Posts: 88
Rep Power: 11 ![]() |
Sergei asked me to reply to this thread.
I could test viewFactorsGen with his modifications: I tested it on a case which has two opposite plates: - the doubleContour algorithm has a better result than the proprietary viewFactorGen utility - the result is better with more integration points, with the cost of a larger calculation time - it tends to underestimate the VF, 1.0 is the maximum and not 1.1 - the minimum to maximum range of the VF field is much smaller than the proprietary one - the deviation from VF field = 1 occurs always at the edge of the plates - the algorithm needs a lot of time, even in a two plate case I also tested it on a real car body part. The result was not as good as for the two plate case but also better than the original code. I think the fvDOM radiation model is more preferable, this has three reasons: - VF generation takes a lot of time, during this time the fvDOM simulation can already be running - when starting a VF simulation, the first calculation of the energy equation also takes a lot of time (one time it took nearly a whole day!) - I observed, that when using VF model, OpenFOAM computes the radiation on the master processor, when running the simulation in parallel. With this, the simulation of big domains is not scalable. However, fvDOM is fully parallelized. Hope this helps someone ![]() |
|
![]() |
![]() |
![]() |
![]() |
#11 |
Member
hannes
Join Date: Mar 2013
Posts: 47
Rep Power: 13 ![]() |
Hi All,
I'm replying to this thread because the above mentioned work from the OFUC2014 was carried out in our institute. For our setup the solution to the problem discussed in this thread was to switch to single line integration for the calculation of the view factors. Having inplemented that, the view factor calculation was accurate enough for our engineering purposes. With our implementation all test cases gave a sum of the view factors below or equal to one as it should be from theoretical considerations. If I remember correctly, the problems that still persist are firstly related to the "ray shooting" algorithm which caused some inaccuracies when faces are partly shaded and secondly to the face agglomeration which should be done "by hand" to give a reasonable agglomeration for the problem under consideration. Replying to the previous post I partly disagree, as I think that the view factor model can be much faster - and even more accurate - compared to the fvDOM. In my opinion fvDOM should only be used for participating media. For radiation between surfaces it is not well suited because the discretisation needed would be too time consuming. Looking forward to your replies Hannes |
|
![]() |
![]() |
![]() |
![]() |
#12 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
I am agree with the most part of observations made by Tobias and Hannes.
viewFactorsGen gives an adequate results for somewhat wide cavity cases. As soon as narrow domains are present (for example, two plates with a very little gap between them) the utility fails to calculate correct view factors. The error is magnified with increasing of the angle between the normals of 2 faces view factor is calculated for. That is why the error for 2 faces sharing an edge in a test box case is larger compared to the error for other faces. This kind of issue can be overcame to some extent by adopting any known algorithm of multipoint integration. The more important issue is the partly shadowing when a face can see only part of other face but the current implementation just can't recognize it. In the current implementation only two states are considered: 1) two faces see each other, 2) two faces don't see each other. |
|
![]() |
![]() |
![]() |
![]() |
#13 |
Member
Jaydeep
Join Date: Jun 2015
Posts: 34
Rep Power: 11 ![]() |
Thanks for this discussion.
I am testing fvDOM and viewFactors. It happens to be the case that fvDOM doesn't support wedge/cyclic patches. I was wondering if somebody has already tried to compare accuracy of viewfactors with wedge/cyclic patch. |
|
![]() |
![]() |
![]() |
![]() |
#14 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
wedge/cyclic/symmetry can't be accounted for correctly by viewfactors model. They are treated exactly the same way other boundary types (walls) are treated. You can exclude them from calculation of viewfactors though if you want.
|
|
![]() |
![]() |
![]() |
![]() |
#15 |
Member
Jaydeep
Join Date: Jun 2015
Posts: 34
Rep Power: 11 ![]() |
Thanks Zeppo!
Does excluding them allows for correct solution to radiation? |
|
![]() |
![]() |
![]() |
![]() |
#16 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
Excluding them makes results incorrect. Can you share your experience with view factors radiation model in OpenFOAM? Was it any good for your specific cases?
|
|
![]() |
![]() |
![]() |
![]() |
#17 |
Senior Member
Derek Mitchell
Join Date: Mar 2014
Location: UK, Reading
Posts: 172
Rep Power: 13 ![]() |
Great discussion it explains the problems i had with combs inside a honeybee hive. I'm now moving away from viewfactors as i need to have a participating medium.
__________________
A CHEERING BAND OF FRIENDLY ELVES CARRY THE CONQUERING ADVENTURER OFF INTO THE SUNSET |
|
![]() |
![]() |
![]() |
![]() |
#18 |
Member
Jaydeep
Join Date: Jun 2015
Posts: 34
Rep Power: 11 ![]() |
Zeppo,
No luck. View Factors give extremely unreliable results. In addition, my problem is a classic case of axisymmetry. Neither VF nor FvDOM from OpenFOAM support wedge patches. P1 in my case produces extremely error prone results. Overall, I am very unhappy with radiation treatment. Were you able to make progress on VF modeling? |
|
![]() |
![]() |
![]() |
![]() |
#19 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 ![]() |
No, unfortunately I didn't move any further with VF. I do plan to try and make any improvements to it though. Moreover, I might win over another person to my side so we could double our efforts.
Nevertheless VF can still be used in many situations like large enclosures where partial obsrtuction may not play any significant role and doesn't need to be accounted for. |
|
![]() |
![]() |
![]() |
![]() |
#20 |
New Member
Vijaya Kumar. G
Join Date: Jun 2016
Location: Chennai, India & Aachen, Germany
Posts: 20
Rep Power: 10 ![]() |
For my analysis I needed to consider only the surface to surface radiation. And fvDOM model was proving to be very expensive for my cases with 0.5 to 1 million cells, mainly because I need to run transient simulations for 5000 seconds and the wall temperatures change due to the gas-wall heat transfer. So I need to do a radiation iteration for atleast every 1 second of the flow simulation.
The fvDOM model gives sufficiently accurate radiative heat fluxes only when nPhi = 4, nTheta = 8 (128 rays or Intensity equations) and maxIter set to 20 atleast. So the computational cost will become prohibitively expensive for 5000 radiation iterations. Hence I tried my luck with the view factor model. And the results with simple test cases (cubical box, cylinrical enclosure) were encouraging and got good radiative heat flux values for drastically reduced computational cost.. But sadly, when I tried it on my main case (which has many numberof patches, in which some patches see themselves and some patches see the other patches only partially - shadow effect) it fails. The result is still good for patches which see themselves, but it is very poor for the patch which has shadow effect. Sadly I have to go back to the fvDOM model eventhough the computational cost is high.. |
|
![]() |
![]() |
![]() |
Tags |
radiation, view factors, viewfactorsgen |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
[snappyHexMesh] How to define to right point for locationInMesh | Mirage12 | OpenFOAM Meshing & Mesh Conversion | 7 | March 13, 2016 14:07 |
HELP!!! viewFactorsGen is not calculating view factors!! | zfaraday | OpenFOAM Pre-Processing | 0 | September 15, 2014 08:55 |
Radiation With View Factors in OPENFOAM | MadiS | OpenFOAM | 1 | August 23, 2012 11:21 |
Thin gap | Flu | CFX | 3 | March 30, 2006 17:40 |
Thermal Radiation View Factors and NEVADA software | Christos Chasapopoulos | Main CFD Forum | 0 | May 11, 2005 09:28 |