View Issue Details

IDProjectCategoryView StatusLast Update
0000656OpenFOAMBugpublic2013-06-20 15:04
Reporteruser522Assigned Touser21 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Summary0000656: View Factor Generation Inaccurate
Descriptionthe pre-processing utility viewFactorsGen is inaccurate. This is because the function calculateViewFactorFij (in viewFactorsGen.C) that calculates the view factor of two faces, uses the formula for the view factor of two infinitesimal faces. Instead, it should use a double integration over the face area or a line integration around the borders.
Steps To Reproducerun viewFactorsGen on any geometry
Additional InformationThe computed radiative heat flux using the radiosity method and view factors is highly sensitive to the precision of the view factor. The method currently used in OpenFOAM is unusable and can lead to errors up to a factor 1000 on coarser grids. However, due to the nature of the view factor calculation used now, the view factor converges to the correct value when the cell size goes towards 0.
Tests were made to compare OpenFOAM with View3D and an analytical solution.
TagsNo tags attached.

Activities

user21

2012-10-05 11:35

  ~0001702

We are aware of the drawbacks of this method. It was a design decision fit for the project in which this model was developed.
If you have the code or reference for the model you are referring I could have a look at it.
Thanks

user522

2012-10-05 11:50

  ~0001703

http://www.bfrl.nist.gov/IAQanalysis/docs/NISTIR-6925.pdf provides an overview over different integration techniques. For example, the double line integration seems suitable (eq. 4), or the single area integration methode (eq. 7). A similar methode is implemented in View3D (http://view3d.sourceforge.net/)

user633

2013-03-29 09:34

 

viewfactors_sphere.jpg (40,714 bytes)   
viewfactors_sphere.jpg (40,714 bytes)   

user633

2013-03-29 09:36

  ~0002080

Hi,
I tried to get viewfactors for a sphere. Without success.
I uploaded an image of the resulting unusable viewfactorfield.
Kind Regards.

Edmund

user633

2013-04-04 13:55

 

user633

2013-04-04 13:56

 

user633

2013-04-04 14:24

  ~0002086

I was able to locate the problem.

A double integral procedure is used and not causing the problem.

For debugging I added the following lines to viewFactorsDict:

debug 1;
dumpRays true;

The "zero entries" are due to aglomeratedFaces that are choosen to have no visble faces in shootRays.H. (This can als be checked in globalFaceFaces in the constant directory. There should be faces belonging to the coarse faces)

Changing the following lines in shootRays.H as done here shows interesting results:
00043 start.append(fc ); 00045 end.append(fc );


Due to that change I have no more zero entries but now there are rays entering the sphere and I have an overestimation of the surrounding patch.

(see pictures)


I hope a specialist can give a good fix now.


Kind Regards

Edmund

user21

2013-04-08 12:06

  ~0002096

Could you upload the mesh you're using then we can check up the view factors
utility?
Thanks

user633

2013-04-08 12:34

 

user633

2013-04-08 12:43

  ~0002097

I uploaded a test case.

The debug output is for now looking like in the following:
Calculating view factors...
Writing view factor matrix...
F00: 0.991325
F01: 0.0212071
F10: 0.653728
F11: 0
End

But it should be (ideal):

F00: 0.97
F01: 0.03
F10: 1.0
F11: 0

user633

2013-04-09 10:09

  ~0002101

Hi Sergio,

I think I solved the problem:

After checking visibility using the inner product in line 41 of shootRays.H the connecting vector is reduced in line 43 (start.append(fc + 0.0001*d);) and 45 (end.append(fc + 0.9999*d); ) for not having start/end-points on the face anymore so that they are not detected as intersection in line 73 (if (!hitInfo[rayI].hit())). But the surfaces used for checking intersection are coming from a triangulization in searchingEngine.H and are not the original faces. This results in a lot of faultily detected intersections due to insufficient length reduction in line 43 and 45.

A secure setting could be:
line 43: start.append(fc + 0.1*d);
line 45: end.append(fc + 0.9*d);

Now the rays are not sorted out faultily any more.
If the reduced line is used as distance for the viewfactor calculation as well maybe 0.99 and 0.01 is better.

Kind Regards

Edmund

Issue History

Date Modified Username Field Change
2012-10-04 15:49 user522 New Issue
2012-10-05 11:35 user21 Note Added: 0001702
2012-10-05 11:50 user522 Note Added: 0001703
2013-03-29 09:34 user633 File Added: viewfactors_sphere.jpg
2013-03-29 09:36 user633 Note Added: 0002080
2013-04-04 13:55 user633 File Added: viefactors_rays_default.jpg
2013-04-04 13:56 user633 File Added: viefactors_rays_modified.jpg
2013-04-04 14:24 user633 Note Added: 0002086
2013-04-08 12:06 user21 Note Added: 0002096
2013-04-08 12:34 user633 File Added: viewfacctorgen_sphere_bug.tar.gz
2013-04-08 12:43 user633 Note Added: 0002097
2013-04-09 10:09 user633 Note Added: 0002101
2013-06-20 15:04 user21 Status new => resolved
2013-06-20 15:04 user21 Resolution open => fixed
2013-06-20 15:04 user21 Assigned To => user21