Cumulative calculations of irradiance

Hello group,

I am working out some simulations to get some figures that help me estimate irradiance on a building for thermal load comparison. What I am trying to do is to gauge the range of numbers one can get and the differences in different part of the building so I have a basis to speak to the engineer.

To do this I generate my Radiance model with only one material to start with with 50% reflectance. I generate a 1/2 hour series of renderings (with -i switch on).
Afterwards I add up the irradiances with pcomb to get one picture from which to get the falsecolor scale in kWh / m2.

I'm using falsecolor with -m = 0.001 to get the output in kWh / m2 to get daily cumulative irradiances. Is this approach correct?

I'm doing this because RADMAP for windows fails to work (even the example files that come with it) so I wanted to play around with radiance and learn something on the way.

I guess my next step is to feed real irradiance data into radiance and foloow the procedure outlined before, Am I in the proper direction?

Thanks for any feedback!

Iván Pajares

Hi Iván,

Regarding your calculation of kWh / m2, you should probably use -m 0.0005 if you are adding up values every half hour rather than once per hour.

As for the -i option not doing quite what you want, glass and other transparent surfaces are excepted for this calculation and pass through to whatever lies beyond. Under circumstances where you are after a rendering of visible surfaces, this is usually preferred. To get the irradiance on every surface regardless of type, use:

  vwrays -x xres -y yres [view options] -fd \
    > rtrace -fd -h -opN scene.oct \
    > rtrace -fdc -I `vwrays -d -x xres -y yres [view options]`scene.oct \
    > irradiance.pic

Vwrays produces the view rays, which the first rtrace very quickly turns into intersection points and surface normals. These are then passed to the second rtrace as irradiance measurement points. The second invocation of vwrays in backwards quotes is simply there to tell the second rtrace the image dimensions.

I hope this helps.
-Greg

···

From: Iván Pajares Sánchez <[email protected]>
Date: June 5, 2008 2:35:36 AM PDT

Hello group,

I am working out some simulations to get some figures that help me estimate irradiance on a building for thermal load comparison. What I am trying to do is to gauge the range of numbers one can get and the differences in different part of the building so I have a basis to speak to the engineer.

To do this I generate my Radiance model with only one material to start with with 50% reflectance. I generate a 1/2 hour series of renderings (with -i switch on).
Afterwards I add up the irradiances with pcomb to get one picture from which to get the falsecolor scale in kWh / m2.

I'm using falsecolor with -m = 0.001 to get the output in kWh / m2 to get daily cumulative irradiances. Is this approach correct?

I'm doing this because RADMAP for windows fails to work (even the example files that come with it) so I wanted to play around with radiance and learn something on the way.

I guess my next step is to feed real irradiance data into radiance and foloow the procedure outlined before, Am I in the proper direction?

Thanks for any feedback!

Iván Pajares

Hi Iván,

Regarding your calculation of kWh / m2, you should probably use -m 0.0005 if you are adding up values every half hour rather than once per hour.
  

Absolutely, I was testing with 1 hour intervals then going up.

As for the -i option not doing quite what you want, glass and other transparent surfaces are excepted for this calculation and pass through to whatever lies beyond.

For the moment my model is a sort of a 'cardboard' model to estimate incident irradiance on exterior-yet-undefined surfaces.

Under circumstances where you are after a rendering of visible surfaces, this is usually preferred. To get the irradiance on every surface regardless of type, use:

  vwrays -x xres -y yres [view options] -fd \
    > rtrace -fd -h -opN scene.oct \
    > rtrace -fdc -I `vwrays -d -x xres -y yres [view options]`scene.oct \
    > irradiance.pic

Vwrays produces the view rays, which the first rtrace very quickly turns into intersection points and surface normals. These are then passed to the second rtrace as irradiance measurement points. The second invocation of vwrays in backwards quotes is simply there to tell the second rtrace the image dimensions.

I hope this helps.
-Greg

Thank you for your help Greg. Let me add another question:

the vwrays lines you sent uses inline commands which I cannot mimic in windows shell, can someone pont me to some source on how to place 'inline' commands in windows shell commands? (using F Anselmo's Mingw Radiance binaries)

Thanks again.

Iván

Hi Iván,

Do it in MingW like so:

  vwrays -d -x xres -y yres [view options] > dimensions.txt
  vwrays -x xres -y yres [view options] -fd \
    > rtrace -fd -h -opN scene.oct \
    > rtrace -fdc -I @dimensions.txt scene.oct \
    > irradiance.pic
  rm dimensions.txt

-Greg

Hi Ivan,

When combining irradiance pics you may wish to set the pixel jitter to zero (i.e. -pj 0), and render at the final resolution. This will prevent different surfaces from possibly contributing to the summed irradiance for those pixels that delineate the 'line' between one surface and another. The consequence is more prominent jaggies, but I prefer that to 'halos'.

-John

···

-----------------------------------------------
Dr. John Mardaljevic
Senior Research Fellow
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
http://www.iesd.dmu.ac.uk/~jm

Hi Ivan,

One approach we have taken for cumulative irradiance studies is to add
up the sky sources first and then do a single simulation with multiple
skies. There is a script that Francesco Anselmo developed (I can't
recall the name or where it might be at the moment) that creates an
annual sky based on a tmy2 weather file. Not sure of your exact needs,
but this might be an easier way to go about it.

Regards,
Zack

Zack Rogers, P.E., IESNA, LEED AP
Daylighting Analysis Group Leader
Architectural Energy Corporation
2540 Frontier Avenue, Suite 201
Boulder, CO 80301 USA

tel (303)444-4149 ext. 435
fax (303)444-4304

Iván Pajares Sánchez <[email protected]> 6/5/2008 3:35 AM >>>

Hello group,

I am working out some simulations to get some figures that help me
estimate irradiance on a building for thermal load comparison. What I
am
trying to do is to gauge the range of numbers one can get and the
differences in different part of the building so I have a basis to
speak
to the engineer.

To do this I generate my Radiance model with only one material to start

with with 50% reflectance. I generate a 1/2 hour series of renderings
(with -i switch on).
Afterwards I add up the irradiances with pcomb to get one picture from

which to get the falsecolor scale in kWh / m2.

I'm using falsecolor with -m = 0.001 to get the output in kWh / m2 to
get daily cumulative irradiances. Is this approach correct?

I'm doing this because RADMAP for windows fails to work (even the
example files that come with it) so I wanted to play around with
radiance and learn something on the way.

I guess my next step is to feed real irradiance data into radiance and

foloow the procedure outlined before, Am I in the proper direction?

Thanks for any feedback!

Iván Pajares

···

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

I've been trying to work out a similar solution for generating a composite image of hourly irradiance values over a full year. However, rather than cumulative results, as produced with pcomb, I want each pixel in the final image to only represent the highest value of irradiance that occurs at that pixel location over a years worth of hourly runs. Ex: if a given pixel gets the highest level of irradiance on June 21 @ noon then that will be the value given to that pixel in the final image. Has anyone tackled this before? Thanks.

Regards to all,
Chris H
Berkeley,CA

···

From: Iván Pajares Sánchez <[email protected]>
Date: June 5, 2008 2:35:36 AM PDT

Hello group,

I am working out some simulations to get some figures that help me estimate irradiance on a building for thermal load comparison. What I am trying to do is to gauge the range of numbers one can get and the differences in different part of the building so I have a basis to speak to the engineer.

To do this I generate my Radiance model with only one material to start with with 50% reflectance. I generate a 1/2 hour series of renderings (with -i switch on).
Afterwards I add up the irradiances with pcomb to get one picture from which to get the falsecolor scale in kWh / m2.

I'm using falsecolor with -m = 0.001 to get the output in kWh / m2 to get daily cumulative irradiances. Is this approach correct?

I'm doing this because RADMAP for windows fails to work (even the example files that come with it) so I wanted to play around with radiance and learn something on the way.

I guess my next step is to feed real irradiance data into radiance and foloow the procedure outlined before, Am I in the proper direction?

Thanks for any feedback!

Iván Pajares

Hi Chris,

I haven't done this, but you should be able to compute the maximum values between two images using pcomb like so:

  pcomb -h -e 'max(a,b):if(a-b,a,b)' -e 'lo=max(li(1),li(2))' -o last_max.pic -o new_vals.pic > cur_max.pic

Renaming cur_max.pic to last_max.pic (using mv -f cur_max.pic last_max.pic) before each invocation should maintain the maximum values at each pixel over each new addition of new_vals.pic. (The -h option is to avoid endless growth of the picture header.)

I hope this helps.
-Greg

···

From: Christian Humann <[email protected]>
Date: June 8, 2008 11:08:44 AM PDT

I've been trying to work out a similar solution for generating a composite image of hourly irradiance values over a full year. However, rather than cumulative results, as produced with pcomb, I want each pixel in the final image to only represent the highest value of irradiance that occurs at that pixel location over a years worth of hourly runs. Ex: if a given pixel gets the highest level of irradiance on June 21 @ noon then that will be the value given to that pixel in the final image. Has anyone tackled this before? Thanks.

Regards to all,
Chris H
Berkeley,CA

Hi Greg,

Thanks for the quick response. I've been trying the pcomb line as you have suggested but the resultant image still seems to show the cumulative values? I seem to get the same results just using:
     pcomb *.raw > annual.pic

Thanks again.

Chris

···

On Jun 8, 2008, at 11:55 AM, Greg Ward wrote:

Hi Chris,

I haven't done this, but you should be able to compute the maximum values between two images using pcomb like so:

  pcomb -h -e 'max(a,b):if(a-b,a,b)' -e 'lo=max(li(1),li(2))' -o last_max.pic -o new_vals.pic > cur_max.pic

Renaming cur_max.pic to last_max.pic (using mv -f cur_max.pic last_max.pic) before each invocation should maintain the maximum values at each pixel over each new addition of new_vals.pic. (The -h option is to avoid endless growth of the picture header.)

I hope this helps.
-Greg

From: Christian Humann <[email protected]>
Date: June 8, 2008 11:08:44 AM PDT

I've been trying to work out a similar solution for generating a composite image of hourly irradiance values over a full year. However, rather than cumulative results, as produced with pcomb, I want each pixel in the final image to only represent the highest value of irradiance that occurs at that pixel location over a years worth of hourly runs. Ex: if a given pixel gets the highest level of irradiance on June 21 @ noon then that will be the value given to that pixel in the final image. Has anyone tackled this before? Thanks.

Regards to all,
Chris H
Berkeley,CA

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Dunno what to say. It works for me -- are you sure of your test?

-Greg

···

From: Christian Humann <[email protected]>
Date: June 8, 2008 2:47:15 PM PDT

Hi Greg,

Thanks for the quick response. I've been trying the pcomb line as you have suggested but the resultant image still seems to show the cumulative values? I seem to get the same results just using:
    pcomb *.raw > annual.pic

Thanks again.

Chris

One approach we have taken for cumulative irradiance studies is to add
up the sky sources first and then do a single simulation with multiple
skies. There is a script that Francesco Anselmo developed (I can't
recall the name or where it might be at the moment) that creates an
annual sky based on a tmy2 weather file. Not sure of your exact needs,
but this might be an easier way to go about it.
Regards,
Zack

Hi Zack,

I have tried creating a let's call it 'accumulated' sky (rendering multiple skies as a big cube, adding them with pcomb and then re-rendering with them as a light probe). However as I'm trying to include the direct component I generate the skies seperately without sun and the the suns on another file to render. This is leading to extraordinarily big numbers so I guess I have to, and please correct my mathematical language if wrong, normalize the numbers to get a manageable figure to work with, is this right?

I know I might be repeating what F. Anselmo and R. Compagnon have done with radmap and other scripts but I confess I enjoy learning this things 'the hard way'...

So, to sum up:

Is it better to render the direct sun component on separate file to get all the sun's dayli/montly or yearly positions and render with all those direct sources plus the accumulated skies or to accumulate the skies with the sun and render?

Thanks to everybody for the feedback, it is outstanding the knowledge that flows through these emails...

Hi Ivan,

Is it better to render the direct sun component on separate file to get all the sun's dayli/montly or yearly positions and render with all those direct sources plus the accumulated skies or to accumulate the skies with the sun and render?

If I understand the question correctly, It's more efficient to render using a 'sky' file that contains both the cumulative sun (e.g. many suns) and the cumulative sky [1] contribution since the inter-reflection calculation will determine the indirect sun component as well and the direct + indirect sky components.
-John
[1] Cumulative sky could be based on either brightdata format or an aggregated 'image'.

···

-----------------------------------------------
Dr. John Mardaljevic
Senior Research Fellow
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
http://www.iesd.dmu.ac.uk/~jm

John-

How would I do this with brightdata? I use a modified version of Francsco's radmap to produce the aggregated image for these types of analyses, but I'm interested in learning how to apply a brightdata method instead. Is this faster? What is the input?

- Rob Guglielmetti

···

On Jun 9, 2008, at 6:57 AM, John Mardaljevic wrote:

If I understand the question correctly, It's more efficient to render using a 'sky' file that contains both the cumulative sun (e.g. many suns) and the cumulative sky [1] contribution since the inter-reflection calculation will determine the indirect sun component as well and the direct + indirect sky components.
-John
[1] Cumulative sky could be based on either brightdata format or an aggregated 'image'.

Francesco's radmap has worked well for us (that would be Zack & myself), creating a single annual sky file (or monthly, or seasonal, depending on how much TMY2 data you feed the script) that contains a single, summed hemispherical sky describing the total radiance for the period, plus all the suns . Your lightprobe idea sounds interesting, too. I would like to update radmap to use gendaylit to create the sky descriptions for greater accuracy, but the current version works well for us for now.

···

On Jun 9, 2008, at 1:57 AM, Iván Pajares Sánchez wrote:

I have tried creating a let's call it 'accumulated' sky (rendering multiple skies as a big cube, adding them with pcomb and then re-rendering with them as a light probe). However as I'm trying to include the direct component I generate the skies seperately without sun and the the suns on another file to render. This is leading to extraordinarily big numbers so I guess I have to, and please correct my mathematical language if wrong, normalize the numbers to get a manageable figure to work with, is this right?

I know I might be repeating what F. Anselmo and R. Compagnon have done with radmap and other scripts but I confess I enjoy learning this things 'the hard way'...

So, to sum up:

Is it better to render the direct sun component on separate file to get all the sun's dayli/montly or yearly positions and render with all those direct sources plus the accumulated skies or to accumulate the skies with the sun and render?

Rob,

How would I do this with brightdata? I use a modified version of Francsco's radmap to produce the aggregated image for these types of analyses, but I'm interested in learning how to apply a brightdata method instead. Is this faster? What is the input?

I generate the sky luminance pattern for each entry in the TMY file and then read-off the luminance values for points on a pre-determined grid. I just keep adding to the values and then write them out in brightdata format (much like was done for the measured sky luminance patterns). I settled on this scheme since it followed on from the validation. I doubt that it is faster, or significantly so, than the aggregated image method.

The cumulative sun contribution is provided by a pre-determined grid of standard Radiance suns, where each sun contains the aggregated effect of all the nearby sun positions that occur throughout the year. Just 150-200 or so suns provides a spatial distribution that is equivalent to a time-step of around 1/2 hour. So, much better than creating a rad file with potentially several thousand suns (for a cumulative annual file).

Unfortunately, it's not code that I can share since it is part of an unwieldy mass of IDL procedures and scripts that only ever gets used in-house and is probably not fit to be let out of the door.

-John

···

-----------------------------------------------
Dr. John Mardaljevic
Senior Research Fellow
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
http://www.iesd.dmu.ac.uk/~jm