enclosed opaque space recieves daylight

[Anonymous]

As the subjecttitel says i got daylightfactor results inside an object/room that should not recieve any daylight.

I imported a dxf model (i used sketchup and exported the "faces" only) to ecotect analysis, asigned the material properties and added a calculationgrid.

After this i added a column by making a square and extruding it, i asigned an opaque material.

The column goes trough the grid.

After a radiance calculation i got daylightfactor results inside the column. Since this is an enclosed space this seems imposible.

On the asumption a grid cell/point uses an an area for the calculation i increased the number of cells but still got results up to 3 cells inside the column.

I tried using single point recievers, the problem still percisted though not that extreme. I tried a simpler model of boxes in boxes (again imported a dxf made with sketchup) and got the same problem with the grid but not with the single point sensors.

So im wondering is this a bug, am i doing something wrong or do grid cells use an area for the calculation thats bigger then the cell?

In 1 of the moddels i also get a (memory?)access error when closing ecotect but i am not sure if that is related.

Ps: I added pdf files with a visual representation of results and settings of the 2 models and a pdf with the acces error

[Pennetier1]

Hi mercyfull_fate, 

It would be easier for me to trouble shoot with your actual .eco model, but I'll try a few tests here from what you provided.

1. Since you have imported the model from Sketchup, make sure all surface normals are facing the exterior correctly.  Typically, when importing from Sketchup, the floors and ceilings will be facing the correct direction, while the wall object will be pointing inward.  You can easily fix that by going to the Select Menu > By element type > Walls.  Then press Crtl +F9 to display the surface normals.  If they are pointing inward, press Crtl+R to reverse the surface normal of all the selected wall objects.

2. It seems to me that while the analysis shows some results above 0, there are still pretty small (<1%). This could happen with the geometry of the model as the calculation is based on ray tracing.  By default, Radiance does not calculate Daylight Factor, but rather Illuminance; Ecotect simply set the unobstructed Sky Illuminance to 100, and the illuminance value is then referenced to a Daylight Factor %.

a) Try to run the same calculation but using Illuminance, instead of Daylight factor, and see what results you get.

b) Run the calculation again, but this time, hide the point objects in your model; I am wondering if these points are not somehow reflecting some light that is not really there. Also, do you have any camera object in your model?  if so, try again with the camera "off".

3. What is your ceiling/floor material?  Same as the wall material?

The grid cells of the analysis grid do not really have a surface area.  All the calculation is done at the intersection point of the grid, so there are no surface areas, it is like single point objects without a surface.  The grid squares are simply a graphic representation of the interpolation of the results within the analysis grid points.

I do not believe that the memory access error is related; does it happen when switching to the Visualize page, or simply when closing Ecotect?  Are you still able to save your file?

let me know a little bit more about these testings.  I have a feeling it is just a modeling glitch as the results still seem very low.  Make sure the planes are well connected and no light might be coming through, although i would doubt it would be the cause given the backward ray-tracing nature of Radiance would probably not pick up such small inaccuracy in the modeling.

Best,

[Anonymous]

Hey Olivier A. PENNETIER,

Thanks for the response,

I redid the calculations acording to your points. I used the simpler "box in box" model.

1: As you said walls where facing inwards but changing the direction did not make any significant diference. I tried with only the walls facing outwards and with both windows and walls facing outwards

This does confuse me though as i asumed the direction would not matter for lightinganalysis if you give both sides the same reflection values etc.

Ecotect showed the wall directions with arrows and the floor/ceiling direction with lines, see atachement "sideview_walldirection".

2a: Using illuminance i have the same result, at 1 location in the model ranging from 3333LUX at 1 gridpoint from the wall (100mm) to 3124 LUX at 3 gridpoint from the wall (300mm) all points farther inwards are the "expected" <20LUX

2b: In this simpler model i did not have any camera's, after removing the sensor points i had similar results

3: In the simpler "box in box" model i used the same wall material for all sides of the inner "boxes" and the same window material for all sides of the outer box.

Based on this question i tried a calculation with floor materials for all floors and ceilling materials for all ceillings/roofs, this gave similar results with slightly lower values as to be expected with less window surface.

The memory access error occurs only when shutting down ecotect, saving the file gives no errors.

It seems to be limited to some files in 1 specific folder, copys of the (almost)exact same model made before the error first ocured dont have the error.

I did notice they are smaller in size to very similar models in the same folder, see atachement "pictures.pdf".

As for checking if the model is enclosed,

I tried running the model with only 1 reflection (i believe with overcast sky that should only show direct light from the sky and no reflected light from walls etc), this also had similar results.

And i checked the *.RAD file, it showed all conecting faces using the same points.

Aditionaly because i know Radiance is weird with blank spaces i checked all names i could think of including the layernames in the sketchupmodel, i used only letters, numbers and underscores. I also tried putting the .ecofile in a location with no spaces.

Finaly i did a Ecotect Analysis daylight calculation (i have no experience with those so might have made some errors there), this calculation does not have the same problem (all gridpoints within the opaque walls give a value of 0). So the problem seems Radiance specific

I added the .eco file of the "box in box" model before (boxtest.eco) and after (boxtest2.eco) doing these tests as discribed in this message, let me know if you need more. It seems the new boxtest2.eco file gets the same memoryaccess error mentioned before so there might go something wrong when i save ecotectfiles.

Regards,

Wouter

[Anonymous]

I might have found when the problem ocurs, it still needs a bit of testing though.

It seems the problem occurs when the grid extents beyond the model, i did not have a problem with the grid starting at a negative point when the grid was smaller then the model, but i did recreate a similar problem when i extended that grid past the model on all sides.

[Pennetier1 · Accepted solution]

Hi mercyfull_fate, 

I took a look at your models.  Indeed, the issue is caused by your grid being set on the outside of your model.

The typical method to create analysis grid is to select the floor object (such as the floor of your glass box), and go to the Auto-Fit Grid to Objects button > Select "within", and specified an appropriate grid spacing.

Doing so on your model will create an analysis grid on the inside of your model, with a "buffer space" to purposely avoid having the grid too close to the exterior boundaries.

The specific reason this happen is not known to me, but I suspect it creates a false reading of the scaling of the DF scale; you can read up on the way Ecotect uses Radiance to perform DF analysis here.

You are correct that the surface normals of the objects should not have any effects on the Radiance calculations as long as the surfaces reflectance are the same; however, I wanted you to be aware of this as the surface normal will impact the DF analysis when using the Ecotect internal engine for daylighting.  Ecotect uses the surface normals to determine whether the sensor point will be inside or outside of a internal space, or on which side of a window object.

Regarding your Access Violation at Address errors, it did not occur on my computer.  I suspect another program is trying to access that memory and thus create this error.  Do you remember if you were using more than one instance of Ecotect when the error occurred? This could cause the error I suppose.

Try un-installing and reinstalling Ecotect after running a registry cleaner.

See attached the results of your model using Radiance with the grid confined to the boundaries of your model.

I hope this helps.

Cheers,

[Anonymous]

Hey Olivier A. PENNETIER,

Thanks for the reply and ecotectfile, it did point me in the right direction.

Based on this i readressed the model where i first encountered the problem, i made the grid by selecting the floor and using autofit grid, but i had the problem again even after removing the gridpoints withing 1 "gridcell distance" of the object inside the room (autofit grid adjusted the grid only to the oute limit not all selected objects). (ecotect keeps a distance of half a cell from a object when using autofit therefor i asume 1 "gridcell distance" should be enough)

After some testing i found out what happens even though i don't really understand it:

The amount of illuminace in 1 gridcell seems to affect the illuminance value of all gridcells within a certain distance (in case of a fine grid this can be more then 1 "gridcell distance")

The attached ecotect files ilustrate what i mean, 1 file shows almost no light inside the object when i removed a lot of gridcells around it. the next files i added gridcells closer to the object and the illuminancevalues inside the object increased. and the last file has grid cells even closer to the object and again the are higher iluminance values inside the object.

The access violation error resolved itself somehow, yesterday and the day before the problem was there today not anymore. Windows had some updates so i think the updates automaticly "repaired" the problem.

regards,

Wouter

[Pennetier1]

Hello mercyfull_fate, 

The issue is partly due to the grid cells being close to the object's boundary.  The real issue is that even though you are "deleting" some grid points surrounding the object's boundary, the analysis grid itself is still located on the outside of your area of analysis, thus it is still picking up light from the outside of the "dark box".  Hiding the analysis grid cells only does that: it hides the cell but the calculation is still there.

The grid points are calculating the average light value surrounding that point, i.e., to 1/2 the distance of the grid cell size, up and down and side to side, as explained in this article; so I am assuming that some grid points on the inside of the box can still be averaging adjacent grid cells that are located on the outside of the box.  I suspect there is a kind of "domino effect" at some point, where one cell value on the inside of the box picks up an average of the adjacent cell on the outside of the box; the next grid point on the inside of the box in turns picks up an average of that cell, thus it shows some light, although less and less, that was originally picked up from the cell on the outside of the box.

The correct way is thus to assign your analysis grid only to that area of analysis.  You can only assign one grid per object; in your scenario, if you are trying to assess the daylight at desk's height in that classroom, you would select the floor object of the classroom and set the grid 30" (60 cm) in height and run the calculation.  Another fast method is simply to select the desk objects and run the calculation based on selected object rather than the analysis grid. 

What is the particular question you have in mind for this analysis?  The illuminance value at the desks for a particular time of the day/year?

I hope things are starting to make sense.

Let me know if you have more questions on this topic, otherwise please accept as a solution so that others can benefit from this information.

Cheers,

[Anonymous]

Hey Olivier,

Thanks for your help, my isue is solved.

the cascade is just a bit weird though since hiding 1 cell decreases the value in another nearby cell (on the other side of the boundary).

After some test i found no changes in the values on the "room side" of the boundary by hiding or showing cells while it does have an effect on the dark part of the grid. I was woried the cascade effect would also affect the roomside of the boundary but thats not the case.

I will just limit myself to 1 room at a time for grid calculation and make sure not cross the rooms outside boundary.

The "original" goal for the calculation was showing the effect of diferent shape and size obstructions in the Radiance calculation as part of my thesis. But as i encountered that "anomaly" my focus kind of shifted to that anomaly and its effects. As part of limiting the amount of work my thesis limits itself mostly to overcast sky conditions and illuminance/daylightfactor at deskheight.

Thanks again,

Wouter