[Radiance-general] BSDF orientation and implementation

[Andrew McNeil]

This didn't get through when I originally set it so I'm trying again...

Chris,

You can use the 5-phase method without CFS geometry. just use a BSDF
material with zero thickness in model_suns.oct. This approach makes sense
for a case where you have a tensor tree BSDF but can't model the actual
system geometry.

Andy


On Tue, Mar 4, 2014 at 8:40 AM, Chris Coulter <Chris.Coulter at burohappold.com
> wrote:

>  Thanks, Greg. I knew I had previously changed the ulimit, and verified
> it was higher than default. I was at 4096 - close but radiance isn't
> horseshoes or hand grenades.
>
>
>
> Chris
>
>
>
> *From:* Greg Ward [mailto:gregoryjward at gmail.com]
> *Sent:* Monday, March 03, 2014 12:47 PM
>
> *To:* Radiance general discussion
> *Subject:* Re: [Radiance-general] BSDF orientation and implementation
>
>
>
> Hi Chris,
>
>
>
> Looking at the command you quoted, the "-opn" option to rtrace should be
> "-opN" for better efficiency, but this isn't what's causing the "broken
> pipe" error.  That indicates that rcontrib is refusing input before rtrace
> is done supplying it.
>
>
>
> The only think I can think of is that you are running out of file
> descriptors.  If using "-e MF:2" instead of "-e MF:6" solves the problem,
> then this is the most likely cause.  The MF:6 setting requires 5186
> descriptors.  Quoting Thomas Bleicher from a Feb. 2007 post:
>
>
>
>  On Mac OS X the max number of open files is limited to 256 per
> user process. That's pretty low and not sufficient for any subdivision
> of the Tregenza sky pattern.
>
> To change the open files limit (on OS X!) I created a file
> "/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
> and I set the kernel limit with "sysctl -w kern.maxfiles=1024".
>
> After a reboot I could set the shell's limit with "ulimit -n 1024".
> This can go into your ".profile" if you're going to use it a lot.
>
>
>
> Unfortunately, the method for changing the number of allowed descriptors
> varies from one system to the next.  Good luck!
>
>
>
> Best,
>
> -Greg
>
>
>
>  *From: *Chris Coulter <Chris.Coulter at BuroHappold.com>
>
> *Date: *February 27, 2014 3:47:22 PM PST
>
>
>
>  That's good to hear...I was just about to upload some images asking for
> clarification.
>
>
>
>
>
> Follow-up to the 5-phase process:
>
> I'm using a small CFS model to generate my BSDF, do I need to create an
> array with the actual geometry covering the full aperture for the Direct
> Sun Contribution (Cds)?
>
>
>
> For rendering - It seems so, otherwise I don't see how the shadow rays are
> traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy
> surface, only physical geometry.
>
> For calc points - Maybe? The model_suns.oct has both physical geometry and
> proxied geometry.
>
>
>
>
>
> Although, when I try the as the tutorial states, I get a "rtrace: Broken
> Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.
>
> Just to verify that wasn't an issue, I doubled back to the files used in
> Andy's tutorial, I also get the error. Code run there was:
>
> vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn
> -faa -ab 0 octs/model_nosuns.oct | \
>
>             rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac
> -fo -o viewpics_ds/back_%04d.hdr \
>
>             -e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I
> -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct
>
> My standard build is the HEAD from 26SEP13, but also tried one from last
> week (2/21) with no success.
>
>
>
>
>
> General question if 5-phase is unable to work without full geometry for
> the CFS, are we then limited to only systems that can be modeled (ie, no
> lenses, laser cut panels, etc)?
>
>
>
> Sorry if I'm all over the place, I started writing this mail at 3p.
>
>
>
> *Chris*
>
>
>
> *From:* Andrew McNeil [mailto:amcneil at lbl.gov <amcneil at lbl.gov>]
> *Sent:* Thursday, February 27, 2014 1:54 PM
> *To:* Radiance general discussion
> *Subject:* Re: [Radiance-general] BSDF orientation and implementation
>
>
>
> Chris,
>
> A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree
> BSDFs that flips the transmission front and back. So your tensor tree BSDF
> is probably fine. My stupid utility has a bug.  I'll let you know when I've
> fixed it and posted a new version.
>
> Andy
>
>
>
> On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <
> Chris.Coulter at burohappold.com> wrote:
>
> Andy/David/Rob - Thanks for the encouragement and suggestions.
>
> I've been working through trying to troubleshoot as I go along. Studying
> it in a 10m cube so I can easily understand how the light is being
> redistributed rather than in my full model. I also found that running the
> CFS through genBSDF with an all black material helpful to digest that
> specular transmission is occurring as expected.
> Andy's reminder that +Z is "in" the space was helpful in making me
> understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf
> seems backwards using the same geometry - which is unnerving. I'm reworking
> the process and will post updates, and inevitably more questions. I was
> finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much
> easier once I realized the network had been disabled and then resolved my
> proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will
> look into it.
>
> David, your note was clear. Thanks. My system is grid a 10mm cubes fit
> into skylights that are 4m x 8m or larger. I think the edge condition can
> be ignored in the BSDF calculation.
>
>
> Thanks again all for help here and in the tutorials, presentations, code,
> etc. Once I can confirm my results are wrong and its not as much of a user
> error as it likely is, I'll post more info/questions.
>
> Chris
>
>
> -----Original Message-----
> From: Guglielmetti, Robert [mailto:Robert.Guglielmetti at nrel.gov]
> Sent: Wednesday, February 26, 2014 11:40 PM
> To: Radiance general discussion
> Subject: Re: [Radiance-general] BSDF orientation and implementation
>
> Hi Chris,
>
> What Andy said! To that end, I would add that tools like objview (for
> visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF
> distribution) are very useful for getting comfortable with your generated
> BSDFs. I am working on a little "test room" model, a la the ltview script
> but for CFS instead of luminaries. When it's sensible I'll post some
> results. It's very helpful to visualize these things; Andy's BSDFviewer is
> awesome, but I also like to mock these things up in Radiance proper so I am
> certain the functions and the models are are being implemented and oriented
> correctly, you know what I mean?
>
> - Rob
>
> From: David Geisler-Moroder <david.moroder at gmail.com<mailto:
> david.moroder at gmail.com>>
> Reply-To: Radiance discussion <radiance-general at radiance-online.org
> <mailto:radiance-general at radiance-online.org>>
> Date: Wednesday, February 26, 2014 at 10:34 AM
> To: Radiance discussion <radiance-general at radiance-online.org<mailto:
> radiance-general at radiance-online.org>>
> Subject: Re: [Radiance-general] BSDF orientation and implementation
>
> Hi Chris,
>
> a short note from my side:
> Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs
> including the glass panes of your IGU. Therefore my approach is usually to
> simulate only the system without any glazing and put the overall system
> together in WINDOW with the right glass.
> Concerning the generation of BSDFs for various applications of a single
> system you should decide if the kind of system you are simulating is
> representative for your application. I tend to simulate typical periods of
> a systems (e.g. for a lamella system you can use the -dim settings to get
> that right) and model any frame in the geometric model. However, in cases
> where e.g. the ratio of system thickness to system size dimension is quite
> high and thus the frame will significantly influence the BSDF, it is better
> to include the real geometry in the BSDF simulation model. However, you
> then probably end up generating more than a single BSDF for the same system
> depending on the applications.
>
> I hope it's somehow clear... if not, let me know and I'll try again ;-)
>
> Cheers,
> David
>
>
>
> 2014-02-26 1:03 GMT+01:00 Andrew McNeil <amcneil at lbl.gov<mailto:
> amcneil at lbl.gov>>:
> Chris,
> Everything you write seems correct. One whatch-it I can offer is to make
> sure you're system is situated properly for the genBSDF run. +Z is into the
> space, +Y is up.  All of the geometry should be in the -Z space. If you
> don't follow these guidelines you're BSDF will be strange.
> Andy
>
>
> On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <
> Chris.Coulter at burohappold.com<mailto:Chris.Coulter at burohappold.com>>
> wrote:
> Good morning Gurus!
>
> I have worked through the 3- and 5-phase tutorials in hopes of being able
> to apply a BSDF to one of my projects. This project will be using
> micro-louver cellular structures imbedded within an IGU, in both skylights
> and vertical windows. I think I understand the general process, but wanted
> to ask a few questions before getting too far down the road...
>
>
> The skylights and windows are all different sizes and the windows are in
> multiple orientations (of course). My understanding of the BSDF and
> seemingly from this mail (
> http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html),
> I should be able to calculate the BSDF once for my system. I was planning
> model the louvers as 1m by 1m, but run genBSDF with the -dim arguments
> smaller than this. Is this the correct approach? Ideally I would not
> calculate the BSDF for each orientation, assuming that micro-louver
> geometry does not change.
>
> In my BSDF material definition, I would alter the up vector according to
> the surface being applied - the up vector matches the BSDF orientation
> (calculated in xy space) to the specific geometry's orientation (0 0 1 for
> a window). If the louver are rotated within the IGU assembly (rz -45) for a
> skylight, I can account for this with the up vector of 1 1 0 (surface
> normal is 0 0 1). This would hold true for rotation within the vertical
> apertures as well. Each different up vector would be a different BSDF
> material.
>
> Lastly, if the glazing properties (VLT) are not defined yet, can I import
> the BSDF file into Window and create multiple options for IGU's with
> varying properties? It seems so from David Geisler-Moroder's presentation
> at the 2012 Workshop (
> http://radiance-online.org/community/workshops/2012-copenhagen/Day1/Geisler-Moroder/geisler-moroder_BSDF_tutorial_s.pdf).
> Certainly skylights and windows will have different VLT and it would again
> be nice to not be required to run genBSDF multiple times.
>
> I am in the process of working through the steps on my own, but wanted to
> ask these questions while I'm waiting on genBSDF.
>
>
> Any help is much appreciated, as always.
>
> Chris Coulter
>
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20140307/9120b8a5/attachment-0001.html>