[Zeppo]

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:

F00: 0
F01: 24.05267
F10: 21.62112
F11: 0.01200849

Region width 10 mm
ViewFactorsGen output:

F00: 0
F01: 1.01395
F10: 0.8505047
F11: 0.1242975

Region width 100 mm
ViewFactorsGen output:

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?

[wyldckat]

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:

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

[Zeppo]

Originally Posted by wyldckat

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:

star4ToFoam -ascii -solids mesh/001mm/star // mesh/001mm/star or mesh/010mm/star or mesh/100mm/star
splitMeshRegions -cellZonesOnly -overwrite

then:

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]

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

[Zeppo]

Originally Posted by wyldckat

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.

[derekm]

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

[Zeppo]

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.

[derekm]

Originally Posted by Zeppo

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

[Zeppo]

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.

[TobM]

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

[hanness]

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

[Zeppo]

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.

[jaydeep]

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.

[Zeppo]

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.

[jaydeep]

Thanks Zeppo!

Does excluding them allows for correct solution to radiation?

[Zeppo]

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?

[derekm]

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.

[jaydeep]

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?

[Zeppo]

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.

[VIJAYA KUMAR]

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..