Simulating rooms with blinds: performance

I've been working with a simple model for glare studies, based on an LBL test room with blinds. The results are looking pretty good, but as soon as I put the blinds into the model, single-case simulation times went up to 2.5-3.5 hours. Does anyone have any feeling for these times? Are they reasonable for a naïve model or too high? The processor used is a quad-core AMD Opteron 2376 (2300 MHz) and I've been using Delaunay's implementation of the Perez sky model, gendaylit, and calculating five ambient bounces.

Possible lines of attack on the problem:
-- Using genBSDF/mkillum (suggested by a colleague.)
-- Simplify the blind model; use flat rather than curved slats.
-- Review the rtrace parameters I am using. I'm rereading John Mardaljevic's chapter in RwR on Daylight Simulation, looking for hints, but Mardaljevic (are you out there?) was primarily working with overcast skies, which aren't adequate for glare models, so I'm not sure how much of his advice still applies. I'm also going to be sweeping the archives of this mailing list for ideas.

Anyone have additional suggestions? Any thoughts on which to try first? Are there particular articles it might be helpful to look at?

···

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

Hi Randolph,

Depending on whether you need to compute the direct component precisely or not, the optimal calculation of a space with venetian blinds is going to come from rtcontrib or mkillum with a BSDF file describing the blinds. If you use genBSDF to create this file, the geometry is inserted into the final model using mkillum. If you don't care so much about the direct component (sunlight passing between the slats onto interior surfaces), then rtcontrib will be much faster if you are computing many time points. My feeling is that this should work well enough for glare evaluations.

Cheers,
-Greg

···

From: "Randolph M. Fritz" <[email protected]>
Date: January 5, 2011 11:34:22 AM PST

I've been working with a simple model for glare studies, based on an LBL test room with blinds. The results are looking pretty good, but as soon as I put the blinds into the model, single-case simulation times went up to 2.5-3.5 hours. Does anyone have any feeling for these times? Are they reasonable for a naïve model or too high? The processor used is a quad-core AMD Opteron 2376 (2300 MHz) and I've been using Delaunay's implementation of the Perez sky model, gendaylit, and calculating five ambient bounces.

Possible lines of attack on the problem:
-- Using genBSDF/mkillum (suggested by a colleague.)
-- Simplify the blind model; use flat rather than curved slats.
-- Review the rtrace parameters I am using. I'm rereading John Mardaljevic's chapter in RwR on Daylight Simulation, looking for hints, but Mardaljevic (are you out there?) was primarily working with overcast skies, which aren't adequate for glare models, so I'm not sure how much of his advice still applies. I'm also going to be sweeping the archives of this mailing list for ideas.

Anyone have additional suggestions? Any thoughts on which to try first? Are there particular articles it might be helpful to look at?
--
Randolph M. Fritz • [email protected]

but Mardaljevic (are you out there?)

I hadn't realised that I'd gone away.

was primarily working with overcast skies, which aren't adequate for glare models,

Indeed. (Actually, I'd already got a climate-based implementation working by then, but the chapter would have ended up longer than the book if I'd have tried to include it.)

so I'm not sure how much of his advice still applies.

Depends on what you mean. The advice re: convergence testing is (still) probably applicable to most scenarios, at least for a 'naive' calc. But we need to know a little more what your goal is. The bulk of the computational effort tends to be, of course, with the prediction of the indirect component. So a reasonable estimate for luminance of, say, the blinds shouldn't be too onerous since the direct component and maybe 1st bounce will usually (but perhaps not always) dominate. Same goes for the view to the outside.

Simplify the blind model; use flat rather than curved slats.

That might not be practicable if it changes the view of potentially illuminated slat area.
For what it's worth, I'm still very much with the sceptics re: predicting glare for deployed blinds (unless perhaps they're fabric). With venetian or vertical blinds, the experienced field of view luminance is dependant on the vagaries of user operation, which, I feel, renders an evaluation all but meaningless - even for a stochastic-based model of user operation (due to uncertainties in the parameterisation). I'm open to be convinced otherwise if someone can come up with a sufficiently compelling argument.
Cheers
John

···

-----------------------------------------------
Dr. John Mardaljevic
Reader in Daylight Modelling
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 Randolph,

Depending on whether you need to compute the direct component precisely or not, the optimal calculation of a space with venetian blinds is going to come from rtcontrib or mkillum with a BSDF file describing the blinds. If you use genBSDF to create this file, the geometry is inserted into the final model using mkillum. If you don't care so much about the direct component (sunlight passing between the slats onto interior surfaces), then rtcontrib will be much faster if you are computing many time points. My feeling is that this should work well enough for glare evaluations.

Cheers,
-Greg

Thanks, Greg. If sunlight is getting through the blinds, we're doing it wrong, so I think I'll try rtcontrib, though I probably need to consult with the rest of my team first.

Randolph

···

On 2011-01-05 12:50:05 -0800, Greg Ward said:

From: "Randolph M. Fritz" <[email protected]>
Date: January 5, 2011 11:34:22 AM PST

I've been working with a simple model for glare studies, based on an LBL test room with blinds. The results are looking pretty good, but as soon as I put the blinds into the model, single-case simulation times went up to 2.5-3.5 hours. Does anyone have any feeling for these times? Are they reasonable for a naïve model or too high? The processor used is a quad-core AMD Opteron 2376 (2300 MHz) and I've been using Delaunay's implementation of the Perez sky model, gendaylit, and calculating five ambient bounces.

Possible lines of attack on the problem:
-- Using genBSDF/mkillum (suggested by a colleague.)
-- Simplify the blind model; use flat rather than curved slats.
-- Review the rtrace parameters I am using. I'm rereading John Mardaljevic's chapter in RwR on Daylight Simulation, looking for hints, but Mardaljevic (are you out there?) was primarily working with overcast skies, which aren't adequate for glare models, so I'm not sure how much of his advice still applies. I'm also going to be sweeping the archives of this mailing list for ideas.

Anyone have additional suggestions? Any thoughts on which to try first? Are there particular articles it might be helpful to look at?
--
Randolph M. Fritz • [email protected]

Greg, I'm confused as to how rtcontrib would apply in my blinds case. I think it falls under "arbitrary input-output relationships in optical systems," but I am not sure how to do this for my blinds. Did you do a presentation on this? Something I could read? Or...?

Randolph

···

On 2011-01-05 12:50:05 -0800, Greg Ward said:

Hi Randolph,

Depending on whether you need to compute the direct component precisely or not, the optimal calculation of a space with venetian blinds is going to come from rtcontrib or mkillum with a BSDF file describing the blinds. If you use genBSDF to create this file, the geometry is inserted into the final model using mkillum. If you don't care so much about the direct component (sunlight passing between the slats onto interior surfaces), then rtcontrib will be much faster if you are computing many time points. My feeling is that this should work well enough for glare evaluations.

Cheers,
-Greg

From: "Randolph M. Fritz" <[email protected]>
Date: January 5, 2011 11:34:22 AM PST

I've been working with a simple model for glare studies, based on an LBL test room with blinds. The results are looking pretty good, but as soon as I put the blinds into the model, single-case simulation times went up to 2.5-3.5 hours. Does anyone have any feeling for these times? Are they reasonable for a naïve model or too high? The processor used is a quad-core AMD Opteron 2376 (2300 MHz) and I've been using Delaunay's implementation of the Perez sky model, gendaylit, and calculating five ambient bounces.

Possible lines of attack on the problem:
-- Using genBSDF/mkillum (suggested by a colleague.)
-- Simplify the blind model; use flat rather than curved slats.
-- Review the rtrace parameters I am using. I'm rereading John Mardaljevic's chapter in RwR on Daylight Simulation, looking for hints, but Mardaljevic (are you out there?) was primarily working with overcast skies, which aren't adequate for glare models, so I'm not sure how much of his advice still applies. I'm also going to be sweeping the archives of this mailing list for ideas.

Anyone have additional suggestions? Any thoughts on which to try first? Are there particular articles it might be helpful to look at?
--
Randolph M. Fritz • [email protected]

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs

Hi Randolph,

Have you looked through Axel's tutorial? You'll need to run genBSDF if you don't have WINDOW6 data to get a BSDF for your blinds. Andy can help you with that if you need help.

Cheers,
-Greg

···

From: "Randolph M. Fritz" <[email protected]>
Date: January 14, 2011 2:37:56 PM PST

Greg, I'm confused as to how rtcontrib would apply in my blinds case. I think it falls under "arbitrary input-output relationships in optical systems," but I am not sure how to do this for my blinds. Did you do a presentation on this? Something I could read? Or...?

Randolph

On 2011-01-05 12:50:05 -0800, Greg Ward said:

Hi Randolph,
Depending on whether you need to compute the direct component precisely or not, the optimal calculation of a space with venetian blinds is going to come from rtcontrib or mkillum with a BSDF file describing the blinds. If you use genBSDF to create this file, the geometry is inserted into the final model using mkillum. If you don't care so much about the direct component (sunlight passing between the slats onto interior surfaces), then rtcontrib will be much faster if you are computing many time points. My feeling is that this should work well enough for glare evaluations.
Cheers,
-Greg

Great, thanks!

···

On 2011-01-14 15:40:42 -0800, Greg Ward said:

Hi Randolph,

Have you looked through Axel's tutorial? You'll need to run genBSDF if you don't have WINDOW6 data to get a BSDF for your blinds. Andy can help you with that if you need help.

Cheers,
-Greg

From: "Randolph M. Fritz" <[email protected]>
Date: January 14, 2011 2:37:56 PM PST

Greg, I'm confused as to how rtcontrib would apply in my blinds case. I think it falls under "arbitrary input-output relationships in optical systems," but I am not sure how to do this for my blinds. Did you do a presentation on this? Something I could read? Or...?

Randolph

On 2011-01-05 12:50:05 -0800, Greg Ward said:

Hi Randolph,
Depending on whether you need to compute the direct component precisely or not, the optimal calculation of a space with venetian blinds is going to come from rtcontrib or mkillum with a BSDF file describing the blinds. If you use genBSDF to create this file, the geometry is inserted into the final model using mkillum. If you don't care so much about the direct component (sunlight passing between the slats onto interior surfaces), then rtcontrib will be much faster if you are computing many time points. My feeling is that this should work well enough for glare evaluations.
Cheers,
-Greg

--
Randolph M. Fritz • [email protected]
Environmental Energy Technologies Division • Lawrence Berkeley Labs