Hello radiance users,

I am performing calculations on illumiance values inside a 22 x 13 x 6 m

geometry that is exclusively lit by a sort of rectangular light pipes.

There's no direct contribution on the spot where I want to know the

irradiance values so I've put some emphasis on the ambient parameters. I've

done measurements on a scale model so I already have a clue on what the

outcome should look like. I use rtrace and it goes like this:

rtrace -I+ -h -ab 7 -aa 0.05 -as 512 -ad 1024 -ar 10000 -av 0.1 0.1 0.1 -aw

1 -af ambfiles/trace.amb -dp 512 -ds .2 -dt .05 -dc .75 -dr 3 -dj .7 -sj

1 -st .01 -lr 8 -lw .001 -e errorfile octrees/room.oct < input > result

(Transformation from irradiance to illuminance happens elsewhere.) The

problem I'm faced with is that the process runs out of memory (on a 2 Gb

memory system). Depending on the platform the process is either terminated

(mingw) or starts swapping to HD (osx). The error message goes: rtrace:

system - out of memory in avstore. I've tried several alternative settings,

e.g. leaving out the -av and -aw parameters (that is setting them to -av 0 0

0 -aw 0) but it won't help. Thuogh reducing the ab setting to 3 solves the

problem, I need more bounces to get anywhere near the final result. I also

wonder if the continuously expanding ambfile behaves normally (it reaches up

to 1.5 Gb when the process terminates). It seems as if new values are added

rather that substituted in the ambfile. Or do I have to use some sort of

cut-off criteria?

I am not at all new to radiance, but obviously not familiar enough with the

code to sort out this problem. Can anyone help?

Kind regards,

Casper Esmeijer

P.S. The model is pretty straightforward. For the light pipes I created a

separate (frozen) octree and I used the instance surface type and xform to

put them in place.

rtrace -I+ -h -ab 7 -aa 0.05 -as 512 -ad 1024 -ar 10000 -av 0.1 0.1 0.1

-aw 1 -af ambfiles/trace.amb -dp 512 -ds .2 -dt .05 -dc .75 -dr 3 -dj .7

-sj 1 -st .01 -lr 8 -lw .001 -e errorfile octrees/room.oct < input >

result

I don't know if it will help your memory issue, but it seems your -ar

value of 10000 is much higher than should be required. I find that

extreme values for 'ar' are only required when the total scene size is

much larger than the zone you're interested in. An example would be a

daylighting model for a single small room in a building that also

includes large external geometry many times larger than the room itself.

Try -ar 200 and -ar 600. You may be surprised that high values don't

impact your results that much, but would have a strong impact on the

quality of rendered images.

-Chris

## ···

____________________________________________________________

Electronic mail messages entering and leaving Arup business

systems are scanned for acceptability of content and viruses

Hi Casper,

I think that light pipes are a bit tricky with Radiance. There are probably others who can chime in on this, but I will give you a few thoughts to start with.

Currently you are setting really high ambient parameters in order to try to trace rays back out the light pipe to fine the solar source. This is tricky with a backwards raytracer such as Radiance. One method that might help short circuit this a bit would be to use mkillum to calculate secondary sources that can be used to simplify things. These secondary sources would make it easier for light to "reach" the space from a calculation standpoint therefore allowing more manageable rendering parameters. One possible way to do this would be to place polygons at the top of your light pipe elements effectively "closing" them to the outside, then you could run mkillum with the polygons to generate secondary sources. Perhaps to optimize things further you could then place polygons to close the bottom end of the pipes and again run mkillum on these resulting in light distribution that is effectively at the bottom of the pipe. I am not sure how valid this is so perhaps others can chime in.

Regards,

-Jack de Valpine

Casper Esmeijer wrote:

## ···

Hello radiance users,

I am performing calculations on illumiance values inside a 22 x 13 x 6 m geometry that is exclusively lit by a sort of rectangular light pipes. There's no direct contribution on the spot where I want to know the irradiance values so I've put some emphasis on the ambient parameters. I've done measurements on a scale model so I already have a clue on what the outcome should look like. I use rtrace and it goes like this:

rtrace -I+ -h -ab 7 -aa 0.05 -as 512 -ad 1024 -ar 10000 -av 0.1 0.1 0.1 -aw 1 -af ambfiles/trace.amb -dp 512 -ds .2 -dt .05 -dc .75 -dr 3 -dj .7 -sj 1 -st .01 -lr 8 -lw .001 -e errorfile octrees/room.oct < input > result

(Transformation from irradiance to illuminance happens elsewhere.) The problem I'm faced with is that the process runs out of memory (on a 2 Gb memory system). Depending on the platform the process is either terminated (mingw) or starts swapping to HD (osx). The error message goes: rtrace: system - out of memory in avstore. I've tried several alternative settings, e.g. leaving out the -av and -aw parameters (that is setting them to -av 0 0 0 -aw 0) but it won't help. Thuogh reducing the ab setting to 3 solves the problem, I need more bounces to get anywhere near the final result. I also wonder if the continuously expanding ambfile behaves normally (it reaches up to 1.5 Gb when the process terminates). It seems as if new values are added rather that substituted in the ambfile. Or do I have to use some sort of cut-off criteria?

I am not at all new to radiance, but obviously not familiar enough with the code to sort out this problem. Can anyone help?

Kind regards,

Casper Esmeijer

P.S. The model is pretty straightforward. For the light pipes I created a separate (frozen) octree and I used the instance surface type and xform to put them in place.

------------------------------------------------------------------------

_______________________________________________

Radiance-general mailing list

[email protected]

http://www.radiance-online.org/mailman/listinfo/radiance-general

--

# Jack de Valpine

# president

#

# visarc incorporated

# http://www.visarc.com

#

# channeling technology for superior design and construction

Jack de Valpine wrote:

.... Perhaps to optimize things further you could then place polygons to close the bottom end of the pipes and again run mkillum on these resulting in light distribution that is effectively at the bottom of the pipe. I am not sure how valid this is so perhaps others can chime in.

Oooh, I hadn't thought of that before, but of course you're right. A very complex skylight/laylight system with multiple "nasty" layers could be sorted out, via mkillum, one at a time with progressive mkillum runs starting from the outside and working your way in. Then for the final calcs/renders, you would simply use the last set of illums. Why wouldn't this be valid? As long as you only use the last set of illums so there isn't any double- or triple counting of contributions, this seems totally valid to me. Greg?

- Rob

Hi Casper et al.,

I need a little more information about the material on the inside of the light pipes. Is it diffuse? If not, then you probably don't need all the ambient bounces. Even if it is, Jack's idea for using mkillum is a good one. I'd try putting the illum surface on the interior portal first, and set mkillum -aa 0 so there's no ambient storage, decreasing other parameters to mkillum accordingly, e.g.:

mkillum -ab 0 -ad 256 -as 0 -ab 4

This will perform a pure Monte Carlo calculation in mkillum, which will avoid the storage problem and still give you reasonable results.

As Jack points out, light pipes are not really Radiance's forte, and down the line there will be better options, like using rtcontrib in a more general ray-tracing precalculation. Right now, you're sort of stuck with mkillum. If your interior surfaces are mirror-like, then you may also avail yourself of the "mirror" type to handle redirected sunlight, but only if you expect that.

Best,

-Greg

## ···

From: Rob Guglielmetti <[email protected]>

Date: May 13, 2008 8:52:38 AM PDT

Jack de Valpine wrote:

.... Perhaps to optimize things further you could then place polygons to close the bottom end of the pipes and again run mkillum on these resulting in light distribution that is effectively at the bottom of the pipe. I am not sure how valid this is so perhaps others can chime in.

Oooh, I hadn't thought of that before, but of course you're right. A very complex skylight/laylight system with multiple "nasty" layers could be sorted out, via mkillum, one at a time with progressive mkillum runs starting from the outside and working your way in. Then for the final calcs/renders, you would simply use the last set of illums. Why wouldn't this be valid? As long as you only use the last set of illums so there isn't any double- or triple counting of contributions, this seems totally valid to me. Greg?

- Rob

Greg, Rob, Jack, Christopher,

Thanks for your response. The light pipes are lined with a diffuse material. So are all other

surfaces. I hadn't thought of using mkillum. Probably the result of how a design process works.

You start out with a plan, then it is slightly changed, some modifications are made and before

you know it you are stuck with something completely different than you started with.

Even though I realise a backward raytracer is not at it's best in these circumstances I'll give the

illums a go and keep you posted.

Casper

## ···

-----Original Message-----

From: Greg Ward <[email protected]>

To: Radiance general discussion <[email protected]>

Date: Tue, 13 May 2008 11:21:55 -0700

Subject: Re: [Radiance-general] out of memory in avstore

Hi Casper et al.,

I need a little more information about the material on the inside of

the light pipes. Is it diffuse? If not, then you probably don't

need all the ambient bounces. Even if it is, Jack's idea for using

mkillum is a good one. I'd try putting the illum surface on the

interior portal first, and set mkillum -aa 0 so there's no ambient

storage, decreasing other parameters to mkillum accordingly, e.g.:

mkillum -ab 0 -ad 256 -as 0 -ab 4

This will perform a pure Monte Carlo calculation in mkillum, which

will avoid the storage problem and still give you reasonable results.

As Jack points out, light pipes are not really Radiance's forte, and

down the line there will be better options, like using rtcontrib in a

more general ray-tracing precalculation. Right now, you're sort of

stuck with mkillum. If your interior surfaces are mirror-like, then

you may also avail yourself of the "mirror" type to handle redirected

sunlight, but only if you expect that.

Best,

-Greg