viewFactorsGen produces incorrect view factors in a very thin gap
 

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:
http://i65.tinypic.com/ydwg7.png
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:
http://i67.tinypic.com/2e1xiyx.png

Region width 10 mm
ViewFactorsGen output:
http://i64.tinypic.com/wmii6v.jpg

Region width 100 mm
ViewFactorsGen output:
http://i64.tinypic.com/1e75g9.jpg
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?

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

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:
then:
And I also submitted a bug report: http://www.openfoam.org/mantisbt/view.php?id=2008

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

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.

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

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

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.

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 ;)

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

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.

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.

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.

Thanks Zeppo!

Does excluding them allows for correct solution to radiation?

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?

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.

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?

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.

Do not use viewFactor model in OpenFOAM
 

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

Hello Everyone,


As you all are discussing about viewFactors etc, so I thought to ask some basic questions.


I am trying to implement view Factor radiation model in chtMultiRegionSimpleFoam, I have a simple geometry of two solid regions.


As you can see in the attached figure:


1. small green box is a heater with 500K temperature
2. Big blue box is the room with 300K


So heat transfer through radiation will take place from the green small solid to big blue solid.


Now, I implemented view Factor model. and my case is running, but I am not sure about the values.


Questions:


1. How we decide what should we write in viewFactorsDict? At this time, I randomly put 20 and 10, as you can see below, but I don't know how to decide these values.


My viewFactorsDict is given below:
2. What should be check in Paraview to see if our model is working fine? because as I have temperature difference of 200K between two solids, so the heat will flow in any case from green to blue solid.


I shall be very thankful if someone can help me out in this.


Thank you

Hello Rava Javez,


I assume that the green box is a solid region and the blue one a fluid region, thus the viewFactorField is generated only in the blue region.


1) nfacesInCoarsestLevel decides the number of agglomerated faces that will be used in the radiation exchange. For example, if you have a cube with 36 faces on each side and you set nfacesInCoarsestLevel to 6 then after the agglomerations the faces used by the view factor model shall be around six. Attached you can see that as you raise the number there are more agglomerated patches and they become smaller. Rember that the number you set is not exactly the number of agglomerated faces you will have.
The featureAngle value is still a mystery. By changing the value I observed that it does have an impact on the computation time but not on the results. Hopefully, someone will explain to us what it does exactly.

2) To check that the view factors are correct the first thing to do is to open the viewFactorField file and check that there are not too many faces with values way above one. If you have too many faces with a values above 1 or with very big values (this happens with small gaps due to the algorithm used in viewFactor.C) increase the number of nfacesInCoarsestLevel this will make the discretization finer and the values of the view factors shall move towards one.

To visualize the view factors in paraView see
https://www.cfd-online.com/Forums/op...alization.html
and just check that the values of all the patches are around 1. The corners will always have the biggest values as the distance between the faces will be small thus due to the algorithm used the value is bigger. See picture attached

You can also check the view factor from one patch to the another using the option in the viewFactorDict after the write(...) options


To check the heat fluxes you can use paraView calculator to integrate the "qr" field over the patches or run the following command when the solver has reached convergence

Hi MatteoQ,

I would like to view the result of the view factor, please help me with how to extract these results. Thank you in advance.

Hi Nghiep,

in my last post on this thread just after point "2)" there is a link to another thread that is dedicated in visualizing the viewFactorField. I leave you here the link to the thread.

Keep in mind that what you will see in paraview is the sum of the view factors between a face agglomeration and all the others, thus for an enclosure such value must be close to one. If you see some faces with values ~1.2 is ok.

If you want the view factor between one face agglomeration and another face agglomeration such information is written in the file named "F" in the constant folder (or <region>/constat folder if the case is multiregion).

Hi MatteoQ,
Thank you for your reply. I did it.
I have another question, Is there a way to see the output of View Factor like F01 = .., F11 =... I want to compare them with theoretical results.

Thank you in advance!!!