[Radiance-general] Python script (perl -S 'works')

Wed Jul 25 13:46:43 PDT 2012

Hi.
I can confirm that Thomas' suggestion to use prepend genskyvec.pl with  
'perl -S' appears to work on a windows 7 machine when run from a Python  
script. I have not tested numerical correspondence with OSX/linux yet as I  
am still going through the remainder of my code to get it to work with the  
windows command line (a process which is very much like extracting one's  
own teeth).
Ryan

On Wed, 25 Jul 2012 20:00:00 +0100,  
<radiance-general-request at radiance-online.org> wrote:

> Send Radiance-general mailing list submissions to
> 	radiance-general at radiance-online.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.radiance-online.org/mailman/listinfo/radiance-general
> or, via email, send a message with subject or body 'help' to
> 	radiance-general-request at radiance-online.org
>
> You can reach the person managing the list at
> 	radiance-general-owner at radiance-online.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Radiance-general digest..."
>
>
> Today's Topics:
>
>    1. Re: partly covered source (Thomas Bleicher)
>    2. Re: BSDF xml into Radiance (Greg Ward)
>    3. Genskyvec error revisited (Guglielmetti, Robert)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 25 Jul 2012 15:01:11 +0200
> From: Thomas Bleicher <tbleicher at googlemail.com>
> To: Radiance general discussion <radiance-general at radiance-online.org>
> Subject: Re: [Radiance-general] partly covered source
> Message-ID:
> 	<CAKGV-k3sBnDu3WCYOx9L723x1n-28HP80MvxNmyOQ8izTmbehA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Jan
>
> You could get the direction of the sun from your sky description and  
> point
> rtrace in that direction and only get the material (-om). You can add  
> your
> own variations to sample the whole disc to calculate the visible part of
> the sun if that's what you need.
>
> Thomas
>
> On Tue, Jul 24, 2012 at 9:50 PM, Jan Wienold
> <jan.wienold at ise.fraunhofer.de>wrote:
>
>> Hi Giulio, hi all,
>>
>> unfortunately it doesn't work out safely. In total I have many, many  
>> cases
>> to look at (in total 40000 timesteps x 33 points x 2geometries) and  
>> there
>> are still many cases, when rtrace doesn't catch the sun.
>> Since these are calculations for an expertise, which is used for a  
>> trial,
>> I have to be absolutely sure not to miss any case...
>>
>> Is there any idea except calculating images ? Source subdivisions are
>> unfortunately not possible when "source" is used...
>>
>> Thanks!
>>
>> Jan
>>
>>
>>
>>
>> On 07/24/2012 02:13 AM, Jan Wienold wrote:
>>
>>> hi giulio,
>>>
>>> Yes!
>>> The use of -dj helped, but only if I use also the -u option. Otherwise  
>>> I
>>> still get randomized zero values, also if I change -ds.
>>>
>>> thanks!
>>>
>>> jan
>>>
>>>
>>>
>>>
>>> On 07/24/2012 01:35 AM, giulio antonutto wrote:
>>>
>>>> Jan,
>>>> maybe you can fix it with -dj and oversampling?
>>>> G
>>>>
>>>> On 24 Jul 2012, at 00:03, Jan Wienold wrote:
>>>>
>>>>  Hi all,
>>>>>
>>>>> I just encountered a strange different behavior between rtrace and
>>>>> rpict:
>>>>> If the sun ( using "source") is  covered in large parts (in that case
>>>>> more than half) I can still "see" the uncovered parts in the image  
>>>>> (=>this
>>>>> is what I expect). In case I calculate at the same point and in the  
>>>>> same
>>>>> direction the illuminance with rtrace -I, I get zero contribution.   
>>>>> Is just
>>>>> the center of the source description tested in that case? Any  
>>>>> solution for
>>>>> this for rtrace?
>>>>> I just look for the sun, no sky description and use only direct
>>>>> calculation (-ab 0) .
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dr.-Ing. Jan Wienold
>>>>> Head of Team Passive Systems and Daylighting
>>>>> Fraunhofer-Institut f?r Solare Energiesysteme
>>>>> Thermal Systems and Buildings
>>>>> Heidenhofstr. 2, 79110 Freiburg, Germany
>>>>> Phone: +49(0)761 4588 5133 Fax:+49(0)761 4588 9133
>>>>> jan.wienold at ise.fraunhofer.de
>>>>> http://www.ise.fraunhofer.de
>>>>>
>>>>> In office:
>>>>> Mo,Tue: 8:30-18:00
>>>>> We,Thu: 8:30-16:00
>>>>> Fr:  8:30-15:30
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> Radiance-general mailing list
>>>>> Radiance-general at radiance-**online.org<Radiance-general at radiance-online.org>
>>>>> http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>
>>>>>
>>>>
>>>> ______________________________**_________________
>>>> Radiance-general mailing list
>>>> Radiance-general at radiance-**online.org<Radiance-general at radiance-online.org>
>>>> http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>
>>>>
>>>
>>>
>>>
>>
>> --
>> Dr.-Ing. Jan Wienold
>> Head of Team Passive Systems and Daylighting
>> Fraunhofer-Institut f?r Solare Energiesysteme
>> Thermal Systems and Buildings
>> Heidenhofstr. 2, 79110 Freiburg, Germany
>> Phone: +49(0)761 4588 5133 Fax:+49(0)761 4588 9133
>> jan.wienold at ise.fraunhofer.de
>> http://www.ise.fraunhofer.de
>>
>> In office:
>> Mo,Tue: 8:30-18:00
>> We,Thu: 8:30-16:00
>> Fr:  8:30-15:30
>>
>>
>> ______________________________**_________________
>> Radiance-general mailing list
>> Radiance-general at radiance-**online.org<Radiance-general at radiance-online.org>
>> http://www.radiance-online.**org/mailman/listinfo/radiance-**general<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/20120725/9ae71715/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 25 Jul 2012 09:44:51 -0700
> From: Greg Ward <gregoryjward at gmail.com>
> To: Radiance general discussion <radiance-general at radiance-online.org>
> Subject: Re: [Radiance-general] BSDF xml into Radiance
> Message-ID: <F856ADD1-FAD7-4DC1-9E31-34934AA170C2 at lmi.net>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Lars,
>
> Andy probably is the right person to respond to this, but as he's on a  
> vacation until the end of the month, I thought I'd offer a couple of  
> comments (inline).
>
> Cheers,
> -Greg
>
>> From: "Lars O. Grobe" <grobe at gmx.net>
>> Date: July 25, 2012 1:18:42 AM PDT
>>
>> Hi Andy, hi list-subscribers,
>>
>> I just came across this recent message about the usability of the bsdf
>> material type with patch-based models of the sky including direct sun
>> and complex fenestration. To avoid misunderstandings, I will try a short
>> summary for others to comment on available options for annual
>> simulations with complex glazing:
>>
>>
>> 1) classic radiance tools (rpict, rtrace), complemented by mkillum to
>> relax ambient setting.
>>
>> Advantages: low noise, validated.
>>
>> Disadvantages: very slow for annual simulations, no support when
>> non-planar specular reflective surfaces are involved.
>
> More specifically, non-planar, specular reflectors run into trouble for  
> insolation.  Cloudy skies or sunless skies are no problem.
>
>> 2) rtcontrib and patch-based model.
>>
>> Advantages: faster for annual simulations.
>>
>> Disadvantages: noise, nice images require high (slow) -ad and cannot be
>> optimized using mkillum, limitations about specular non-planar
>> reflectors apply.
>
> The accuracy of non-planar, specular reflectors is actually better than  
> #1, but the results are somewhat noisy.  A new -c option to vwrays  
> (coupled with the rtcontrib -c option) is a good way to reduce noise  
> that is available in the latest HEAD.  This is a better way to reduce  
> noise than increasing -ad, and less costly.
>
>> 3) rtcontrib and patch-based model, bsdf.
>>
>> Advantages: support for non-planar reflectors, should be slightly faster
>> than 2) as the fenestration system does not have to be traced internally
>> - did anyone compare?
>>
>> Disadvantages: still high -ad settings required leading to extended
>> rendering times and still no way to get mkillum in, tends to
>> underestimate direct sun (according Andy's message).
>>
>>
>> 4) three-phase-method.
>>
>> Advantages: very fast, can also be used with non-planar specular
>> reflectors as bsdf data is supported.
>>
>> Disadvantages: requires quite a lot of set-up work, e.g. subdivisions to
>> reflect external obstructions. Patches visible in the results,
>> fenestration geometry is not visible.
>
> Andy has proposed an improved annual simulation method, which we hope to  
> work on next year, to remedy the direct solar sampling difficulties in  
> the 3-phase method.  It should also alleviate problems with external  
> facade geometry and reduce the need to subdivide windows.
>
>> 5) pmap.
>>
>> Advantages: can be used with non-planar reflectors and multi-peak
>> transmission.
>>
>> Disadvantages: unknown status (any news?), not integrated with rtcontrib
>> (contributions would need to be rendered manually).
>>
>>
>> So if I need a way to generate images with visible fenestration
>> geometry, the only reliable option would be 2), which requires very
>> hight settings for -ad and thud will still be rather time-consuming, if
>> noise is to be controlled.
>>
>> Cheers, Lars.
>>
>> On Tue, 2012-06-12 at 08:43 -0700, Andrew McNeil wrote:
>>
>>> Though I've found that the BSDF material doesn't work well for
>>> daylight coefficient based annual simulations (I'm assuming dds.bash
>>> is a dynamic daylight simulation script).  Putting the solar radiance
>>> into skypatches relies on probabilistic sampling to find patches
>>> containing the sun, and if you don't have much direct transmission
>>> from the direction of the sun, you aren't likely to find the sun.  Not
>>> finding the sun causes big errors.
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 25 Jul 2012 12:01:03 -0600
> From: "Guglielmetti, Robert" <Robert.Guglielmetti at nrel.gov>
> To: Radiance general discussion <radiance-general at radiance-online.org>
> Subject: [Radiance-general] Genskyvec error revisited
> Message-ID: <CC35907F.12D36%robert.guglielmetti at nrel.gov>
> Content-Type: text/plain; charset="us-ascii"
>
> Well, it looks like WindowsXP isn't the only problem. While genskyvec.pl
> works fine with piped input from the command line on Windows7, when it's
> called from within my Ruby script, I get the same error that Ryan  
> Southall
> reported with his Python script
> (http://www.radiance-online.org/pipermail/radiance-general/2012-July/008758
> .html).
>
> Greg, I tried your suggestion again as well:
>
>> I can't test it for you, but I suspect the line:
>> } elsif (/\sskyfunc\s*$/) {
>> is the problem.  Try removing the final '\s*' to make it:
>> 	} elsif (/\sskyfunc$/) {
>
> ...but no luck.
>
> Ryan, have you made any more progress with this issue? Anyone else?
> Bueller?
>
>
> Rob Guglielmetti  IESNA, LEED AP
> Commercial Buildings Research Group
> National Renewable Energy Laboratory
> 15013 Denver West Parkway MS:RSF202
> Golden, CO 80401
> 303.275.4319
> robert.guglielmetti at nrel.gov
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
>
> End of Radiance-general Digest, Vol 101, Issue 31
> *************************************************
>
> ___________________________________________________________
> This email has been scanned by MessageLabs' Email Security
> System on behalf of the University of Brighton.
> For more information see http://www.brighton.ac.uk/is/spam/
> ___________________________________________________________

-- 
--
Dr Ryan Southall
Senior Research Fellow
School of Architecture & Design
University of Brighton
Mithras House
Lewes Rd
Brighton
BN2 4AT
T: ++44 (0) 1273 642335
E: R.Southall at brighton.ac.uk

___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________