View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000656OpenFOAM[All Projects] Bugpublic2012-10-04 14:492013-06-20 14:04
Reportermarc.immer 
Assigned ToSergio 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
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.
Attached Filesjpg file icon viewfactors_sphere.jpg [^] (40,714 bytes) 2013-03-29 09:34


jpg file icon viefactors_rays_default.jpg [^] (355,964 bytes) 2013-04-04 12:55
jpg file icon viefactors_rays_modified.jpg [^] (365,241 bytes) 2013-04-04 12:56
gz file icon viewfacctorgen_sphere_bug.tar.gz [^] (58,556 bytes) 2013-04-08 11:34

- Relationships

-  Notes
(0001702)
Sergio (developer)
2012-10-05 10:35

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
(0001703)
marc.immer (reporter)
2012-10-05 10:50

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/ [^])
(0002080)
eddi0907 (reporter)
2013-03-29 09:36

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

Edmund
(0002086)
eddi0907 (reporter)
2013-04-04 13:24

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
(0002096)
Sergio (developer)
2013-04-08 11:06

Could you upload the mesh you're using then we can check up the view factors
utility?
Thanks
(0002097)
eddi0907 (reporter)
2013-04-08 11:43

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
(0002101)
eddi0907 (reporter)
2013-04-09 09:09

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 14:49 marc.immer New Issue
2012-10-05 10:35 Sergio Note Added: 0001702
2012-10-05 10:50 marc.immer Note Added: 0001703
2013-03-29 09:34 eddi0907 File Added: viewfactors_sphere.jpg
2013-03-29 09:36 eddi0907 Note Added: 0002080
2013-04-04 12:55 eddi0907 File Added: viefactors_rays_default.jpg
2013-04-04 12:56 eddi0907 File Added: viefactors_rays_modified.jpg
2013-04-04 13:24 eddi0907 Note Added: 0002086
2013-04-08 11:06 Sergio Note Added: 0002096
2013-04-08 11:34 eddi0907 File Added: viewfacctorgen_sphere_bug.tar.gz
2013-04-08 11:43 eddi0907 Note Added: 0002097
2013-04-09 09:09 eddi0907 Note Added: 0002101
2013-06-20 14:04 Sergio Status new => resolved
2013-06-20 14:04 Sergio Resolution open => fixed
2013-06-20 14:04 Sergio Assigned To => Sergio