<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><BR class="khtml-block-placeholder"></DIV><DIV> A recent question about the use of the MRT module to calculate</DIV><DIV>viewfactors and how complex the zones geometry can be....</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><P style="margin-top: 0px; margin-right: 0px; margin-bottom: 8px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="4"><SPAN class="Apple-style-span" style="font-size: 13.3px;">has anybody used mrt for ray tracing based view factor calculation (as was suggested a little while ago) on any problems with many surfaces? Are there known limits? I tried this in a zone with 24 surfaces (see attached files, if interested). Mrt does not seem to be able to cope with this based on default settings for compile (I set the two parameters “grid division” and “patch division” to maximum values – in this case 32 and 50). The results are mainly zeroes … for the zone view factors themselves and for the MRT sensor.</SPAN></FONT></P><P style="margin-top: 0px; margin-right: 0px; margin-bottom: 8px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="4"><SPAN class="Apple-style-span" style="font-size: 13.3px;">Is there any experience on this out there? What / where would one need to change settings in the headers and recompile for higher resolution? Has that been done / checked in the past? </SPAN></FONT></P></BLOCKQUOTE><BR><DIV>The MRT module has been tested for zones up to about 55 surfaces and with gridding</DIV><DIV>division set within the range of 12-25. Usually the patch division value does not get </DIV><DIV>changed (i.e. I do not bother changing it).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The interface should let you know the maximum values it will allow for the number</DIV><DIV>of sufaces in the zone.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The patch division is intended to put an array of points distributed across the surface</DIV><DIV>and this usually works ok UNLESS some of the dimensions are small - for example if</DIV><DIV>a surface has had a window inserted and the edge of the window and the nearest</DIV><DIV>edge of the bounding surface is less than 40mm then there may be no points</DIV><DIV>falling in that part of the bounding surface and the method will loose accuracy.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The other case where the calculation is less accurate is if a surface has more than</DIV><DIV>about 18 edges and in that case the accuracy is improved if such surfaces are</DIV><DIV>split into two surfaces.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And MRT does get confused if someone has defined a zone which is uniformally</DIV><DIV>inside-out (which can happen if someone defines a zone as an extruded floor plan but</DIV><DIV>puts the list of X-Y coordinates in reversed order.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If the sizes of surfaces within a zone include some with only a few square mm and</DIV><DIV>others with say 1000m2 then we would suggest some subdivision of the</DIV><DIV>really big surfaces.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The model that was attached to the original question does have a number of</DIV><DIV>surfaces that have small dimensions in comparison to the primary surfaces</DIV><DIV>of the zone. An initial suggestion is to subdivide some of the larger surfaces,</DIV><DIV>especially the floor and ceiling.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-ESRU</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>