CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Pre-Processing

viewFactorsGen produces incorrect view factors in a very thin gap

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree9Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 13, 2016, 16:40
Question viewFactorsGen produces incorrect view factors in a very thin gap
  #1
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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?
derekm likes this.

Last edited by wyldckat; February 21, 2016 at 16:09. Reason: repaired link
Zeppo is offline   Reply With Quote

Old   February 21, 2016, 16:18
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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"
there have already several bugs fixed in this utility and there are possibly still a few more to be solved, probably including this issue that you're pointing out.

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
__________________
wyldckat is offline   Reply With Quote

Old   February 28, 2016, 12:22
Default
  #3
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
Quote:
Originally Posted by wyldckat View Post
Can you provide the test case(s) that you've used for reproducing these results? 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
Bruno, thank you for your reply.
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
then:
Code:
faceAgglomerate -region cellZone_2 -dict constant/viewFactorsDict > log.faceAgglomerate.$i 2>&1
viewFactorsGen -region cellZone_2 > log.viewFactorsGen.$i 2>&1
And I also submitted a bug report: http://www.openfoam.org/mantisbt/view.php?id=2008
wyldckat likes this.
Zeppo is offline   Reply With Quote

Old   March 6, 2016, 10:20
Default
  #4
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
__________________
wyldckat is offline   Reply With Quote

Old   March 6, 2016, 15:41
Default
  #5
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
Quote:
Originally Posted by wyldckat View Post
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
Bruno, actually I have already tried view factors radiation model to solve a case with structured uniform pure hexa mesh and got the same - wrong results.
It would be really nice of you If you could resolve the issue. Looking forward to hearing from you on the progress.
Zeppo is offline   Reply With Quote

Old   May 13, 2017, 12:38
Default
  #6
Senior Member
 
Derek Mitchell
Join Date: Mar 2014
Location: UK, Reading
Posts: 172
Rep Power: 13
derekm is on a distinguished road
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
derekm is offline   Reply With Quote

Old   May 13, 2017, 15:11
Default
  #7
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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.
Zeppo is offline   Reply With Quote

Old   May 13, 2017, 15:22
Default
  #8
Senior Member
 
Derek Mitchell
Join Date: Mar 2014
Location: UK, Reading
Posts: 172
Rep Power: 13
derekm is on a distinguished road
Quote:
Originally Posted by Zeppo View Post
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.
have you seen this http://elib.dlr.de/91571/1/OFUC2014_...ew-factors.pdf
I've tried contacting the authors but no success
__________________
A CHEERING BAND OF FRIENDLY ELVES CARRY THE CONQUERING ADVENTURER OFF INTO THE SUNSET
derekm is offline   Reply With Quote

Old   May 13, 2017, 17:04
Default
  #9
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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.
Zeppo is offline   Reply With Quote

Old   October 23, 2017, 02:59
Default
  #10
Member
 
Join Date: Sep 2014
Location: Germany
Posts: 88
Rep Power: 11
TobM is on a distinguished road
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
TobM is offline   Reply With Quote

Old   November 7, 2017, 06:22
Default
  #11
Member
 
hannes
Join Date: Mar 2013
Posts: 47
Rep Power: 13
hanness is on a distinguished road
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
hanness is offline   Reply With Quote

Old   November 12, 2017, 08:56
Default
  #12
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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.
altinel likes this.
Zeppo is offline   Reply With Quote

Old   December 8, 2017, 14:13
Default
  #13
Member
 
Jaydeep
Join Date: Jun 2015
Posts: 34
Rep Power: 10
jaydeep is on a distinguished road
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.
jaydeep is offline   Reply With Quote

Old   December 22, 2017, 12:56
Default
  #14
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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.
altinel likes this.
Zeppo is offline   Reply With Quote

Old   December 22, 2017, 14:10
Default
  #15
Member
 
Jaydeep
Join Date: Jun 2015
Posts: 34
Rep Power: 10
jaydeep is on a distinguished road
Thanks Zeppo!

Does excluding them allows for correct solution to radiation?
jaydeep is offline   Reply With Quote

Old   January 6, 2018, 15:19
Default
  #16
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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?
Zeppo is offline   Reply With Quote

Old   January 7, 2018, 16:04
Default
  #17
Senior Member
 
Derek Mitchell
Join Date: Mar 2014
Location: UK, Reading
Posts: 172
Rep Power: 13
derekm is on a distinguished road
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
derekm is offline   Reply With Quote

Old   February 3, 2018, 19:21
Default
  #18
Member
 
Jaydeep
Join Date: Jun 2015
Posts: 34
Rep Power: 10
jaydeep is on a distinguished road
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?
jaydeep is offline   Reply With Quote

Old   February 7, 2018, 14:35
Default
  #19
Senior Member
 
Zeppo's Avatar
 
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21
Zeppo will become famous soon enough
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.
Zeppo is offline   Reply With Quote

Old   June 14, 2019, 10:56
Default Do not use viewFactor model in OpenFOAM
  #20
New Member
 
Vijaya Kumar. G
Join Date: Jun 2016
Location: Chennai, India & Aachen, Germany
Posts: 20
Rep Power: 9
VIJAYA KUMAR is on a distinguished road
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..
B_R_Khan likes this.
VIJAYA KUMAR is offline   Reply With Quote

Reply

Tags
radiation, view factors, viewfactorsgen

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
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


All times are GMT -4. The time now is 04:26.