|
|
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 |
|
|
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/) |
|
2013-03-29 09:34
|
viewfactors_sphere.jpg (40,714 bytes) |
|
|
Hi, I tried to get viewfactors for a sphere. Without success. I uploaded an image of the resulting unusable viewfactorfield. Kind Regards. Edmund |
|
2013-04-04 13:55
|
|
|
2013-04-04 13:56
|
|
|
|
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 |
|
|
Could you upload the mesh you're using then we can check up the view factors utility? Thanks |
|
2013-04-08 12:34
|
|
|
|
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 |
|
|
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 |
- Anonymous
