running genBSDF

Dear List,

I am currently doing my final internship as part of my engineering studies.

I need to use Radiance software and encounter difficulties running “genBSDF” program.

I have followed the example 1 of the “genBSDF Tutorial" but an error message appears in my DOS, saying : “can’t load the Radiance input"

I’m working on Windows 7 & Radiance version 5.0.a.8, and I have downloaded the genBSDF.exe file from http://www.jaloxa.eu/resources/radiance/radwinexe.shtml.

My batch file is :

What's in blind1.rad?

Dear List,

I am currently doing my final internship as part of my engineering studies.

I need to use Radiance software and encounter difficulties running “genBSDF” program.

I have followed the example 1 of the “genBSDF Tutorial" but an error message appears in my DOS, saying : “can’t load the Radiance input"

I’m working on Windows 7 & Radiance version 5.0.a.8, and I have downloaded the genBSDF.exe file from http://www.jaloxa.eu/resources/radiance/radwinexe.shtml.

My batch file is :

blinds.rad (138 Bytes)

Severine,

---------blind1.rad ------

### blind1.rad
void plastic white
0
0
5 0.7 0.7 0.7 0 0
!genblinds white blind1 1 3 4 4 20 | xform -rz

did you accidentally cut off the file after -rz? because it should continue
like below. If your file doesn't contain the rest that is likely your
problem.

### blind1.rad
void plastic white
0
0
5 0.7 0.7 0.7 0 0

!genblinds white blind1 1 3 4 4 20 | xform -rz -90 -rx -90 -t 0 0 -0.939693

If your file contains the full xform command, can you share the exact and
full error reported by genBSDF? you've only said “can't load the Radiance
input" which I don't think is the full or exact error you received.
Sometimes something seemingly unimportant in the error is a useful hint as
to what's going wrong.

Andy

···

On Thu, May 12, 2016 at 3:35 AM, Séverine HUET <[email protected]> wrote:

--------
WARNING: At least one of the links in the message below goes to an .exe
file,
which could be malicious. To learn how to protect yourself, please go here:
https://commons.lbl.gov/x/_591B
--------

Hi everybody,

First, thank you very much for your interest in my issue !
Actually, my system execute .exe file without explicitly calling them as
such. I wrote the entire directory path just to compare...
So, I rewrote the batch file as following :
----
SET PATH=.;C:\Radiance\lib;C:\Radiance\bin;$RAYPATH;$PATH
SET RAYPATH=.;C:\Radiance\lib;C:\Radiance\bin;$RAYPATH
c:
cd C:\VSA_SolarFactor\test160428_01\

objview blind1.rad
pause
getbbox blind1.rad
pause
xform -e blind1.rad > blind2.rad
pause
genBSDF +f +b -c 500 -geom inch blind1.rad > blind1.xml
pause
-----

Every program work well, except genBSDF.
As you mentioned it, Robert Guglielmetti, something wrong is going under
the hood with xform. That is why I have tried to run xform, as written in
genBSDF.pl file line 149, and it works well providing blind2.rad.

Would you advise me to run genBSDF.pl file instead of genBSDF.exe ? I am
quite beginner and tried to but I guess I didn't enter the right command
line...

Is there something wrong in my files ? They are located in
C:\VSA_SolarFactor\test160428_01\
My files are :

---------blind1.rad ------

### blind1.rad
void plastic white
0
0
5 0.7 0.7 0.7 0 0

!genblinds white blind1 1 3 4 4 20 | xform -rz

----- And blind2.rad provided by xform -------

# xform -e
### blind1.rad

void plastic white
0
0
5 0.7 0.7 0.7
  0 0
# xform -rz -90 -rx -90 -t 0 0 -0.939693
# genblinds white blind1 1 3 4 4 20

white polygon blind1.1.0
0
0
12
                  0 0.5 -0.939693
                  3 0.5 -0.939693
                  3 0.842020143326 -3.79214000201e-007
5.75395780114e-017 0.842020143326 -3.79213999979e-007

white polygon blind1.2.0
0
0
12
                  0 1.5 -0.939693
                  3 1.5 -0.939693
                  3 1.84202014333 -3.7921400009e-007
5.75395780114e-017 1.84202014333 -3.79213999868e-007

white polygon blind1.3.0
0
0
12
                  0 2.5 -0.939693
                  3 2.5 -0.939693
                  3 2.84202014333 -3.79213999979e-007
5.75395780114e-017 2.84202014333 -3.79213999757e-007

white polygon blind1.4.0
0
0
12
                  0 3.5 -0.939693
                  3 3.5 -0.939693
                  3 3.84202014333 -3.79213999979e-007
5.75395780114e-017 3.84202014333 -3.79213999757e-007
--------------

Thank you in advance,
Severine

-----Message d'origine-----
De : [email protected] [mailto:
[email protected]]
Envoyé : jeudi 12 mai 2016 10:10
À : [email protected]
Objet : Radiance-dev Digest, Vol 110, Issue 5

Send Radiance-dev mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.radiance-online.org/mailman/listinfo/radiance-dev
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Radiance-dev digest..."

Today's Topics:

   1. Re: running genBSDF (Guglielmetti, Robert)
   2. Re: Meta files and library (Gregory J. Ward)
   3. Re: NREL Radiance re-distribution (Georg Mischler)
   4. Re: Meta files and library (Georg Mischler)
   5. Re: NREL Radiance re-distribution (Georg Mischler)

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

Message: 1
Date: Wed, 11 May 2016 19:05:31 +0000
From: "Guglielmetti, Robert" <[email protected]>
To: code development <[email protected]>
Subject: Re: [Radiance-dev] running genBSDF
Message-ID: <D358DE8B.2563A%[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

--------
WARNING: At least one of the links in the message below goes to an .exe
file, which could be malicious. To learn how to protect yourself, please go
here:
https://commons.lbl.gov/x/_591B
--------

I'm admittedly grasping at straws...

On 5/11/16, 12:17 PM, "Georg Mischler" <[email protected]> wrote:

>--------
>WARNING: At least one of the links in the message below goes to an .exe
>file, which could be malicious. To learn how to protect yourself,
>please go
>here:
>https://commons.lbl.gov/x/_591B
>--------
>
>The executable file types are configured in the PATHEXT environment
>variable. Its default contents are (for Win7/8):
>
> .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
>
>It would be VERY unusual for .EXE to be missing there, and an
>indication of a severely misconfigured system.
>
>Cheers
>-schorsch
>
>
>Am 2016-05-11 17:31, schrieb Guglielmetti, Robert:
>>
>> On the second command, are you sure your batch file calls "getbbox",
>> and not "getbbox.exe? My sense is that your system is not set up to
>> execute .exe files without explicitly calling them as such. The
>> genBSDF script calls xform on line 150 (note the lack of the '.exe'
>> or any kind of operating system-specific conditional), and if it
>> fails to run the script generates the error you are seeing.
>>
>> I think there's something you can set up in Windows to automatically
>> try appending ".exe" (and ".bat" and .com) to any program calls on
>> the command line, but it has to be set up, I guess.
>>
>> On 5/11/16, 1:20 AM, "S?verine HUET" > >> <[email protected]<mailto:[email protected]>> wrote:
>>
>> Dear List,
>>
>> I am currently doing my final internship as part of my engineering
>> studies.
>>
>> I need to use Radiance software and encounter difficulties running
>> "genBSDF" program.
>>
>> I have followed the example 1 of the "genBSDF Tutorial" but an error
>> message appears in my DOS, saying : "can't load the Radiance input"
>>
>> I'm working on Windows 7 & Radiance version 5.0.a.8, and I have
>> downloaded the genBSDF.exe file from
>> http://www.jaloxa.eu/resources/radiance/radwinexe.shtml\.
>>
>> My batch file is :
>>
>> -----
>>
>> SET PATH=.;C:\Radiance\lib;C:\Radiance\bin;$RAYPATH;$PATH
>>
>> SET RAYPATH=.;C:\Radiance\lib;C:\Radiance\bin;$RAYPATH
>>
>> c:
>>
>> cd C:\VSA_SolarFactor\test160428_01\
>>
>> C:\Radiance\bin\objview.exe blind1.rad
>>
>> pause
>>
>> C:\Radiance\bin\getbbox blind1.rad
>>
>> pause
>>
>> C:\Radiance\bin\genBSDF.exe +f +b -c 500 -geom inch blind1.rad >
>> blind1.xml
>>
>> -----
>>
>>
>>
>> I have no idea how to fix it because it is perfectly working with the
>> other programs of Radiance software like getbox or objview. Now, my
>> internship ends soon, that's why I'm writing to you; I would be
>> grateful if you have any suggestion about what is wrong with my batch
>> file.
>>
>> Thank you in advance for your help,
>>
>> Best regards,
>>
>> Severine
>
>
>--
>Georg Mischler -- simulations developer -- schorsch at schorsch com
>+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
>_______________________________________________
>Radiance-dev mailing list
>[email protected]
>http://www.radiance-online.org/mailman/listinfo/radiance-dev

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

Message: 2
Date: Wed, 11 May 2016 17:27:54 -0700
From: "Gregory J. Ward" <[email protected]>
To: code development <[email protected]>
Subject: Re: [Radiance-dev] Meta files and library
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Schorsch,

I only have a response to a few of these, so I'll pull them out...

> From: Georg Mischler <[email protected]>
> Date: May 11, 2016 1:31:34 AM PDT
>
> So the plot files are really cal files?
> Or just a very similar, but subtly incompatible variation thereof?
> The documentation sometimes talks about "plot files", and sometimes
> about "graph files". Are those the same?

The "graph files" are related to .cal files in an odd way. Specifically,
functions in graph files use the .cal language, but you only get one line
per definition, so end-of-line must be escaped with a backslash ('\') if
you want to keep a function neat and semicolons at the end are optional.
You can specify as many variables and related functions as you need,
subject to the same restrictions. Other lines in the graph file define
strings rather than expressions, and are parsed differently. So, it's a
mix, but pretty easy to work with. I use it all the time when I want to
make a quick plot. Try:

include=function.plt
include=polar.plt
DEG:PI/180
xmin=0
xmax=360
abs(x):if(x,x,-x)
A(x)=abs(sin(x*DEG)+cos(x*DEG))

Then, give the file to bgraph and pipe the output to psmeta or meta2bmp to
see what comes out.

> ...
> As long as nobody complains eg. about output resolution, it's clearly
> easier to keep working with meta files internally for the moment.
> But then, it would still be nice if we could simplify things a bit.
> Is there really still a need for pexpand? And I'm not quite sure what
> psort is good for to begin with.

The pexpand command is called internally, as is psort by image converters
that want their vector primitives sorted.

> Since those tools are not used anywhere else, wouldn't it make sense
> to ditch $MLIB, and simply use $RAYPATH/meta instead?

Except that RAYPATH is a list of directories, where MDIR is a single
location. All the same, a function that finds the first meta directory in
$RAYPATH could be used instead.

> The documentation also mentions (usually under "see also") a number of
> manpages that either never existed or have been removed: graph(1G),
> plot(1), plot(5), plotout(1), primout(3), t4014(1), mx80(1), impress(1).

Yeah, RIP many disused graphics output devices. We could remove the
references if anyone cares.

> And last (for the moment): Looking at the manpage, it appears that
> plotin(1) has a very similar if not identical purpose as bgraph(1).
> What am I missing there?

The plotin tool converts from old-school plot primitives to metafile
equivalents. I don't know if anyone uses the original graph or plot
routines anymore, so this could probably be retired as well. The
functionality is better in bgraph, anyway.

-Greg

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

Message: 3
Date: Thu, 12 May 2016 09:10:56 +0200
From: Georg Mischler <[email protected]>
To: Radiance Dev <[email protected]>
Subject: Re: [Radiance-dev] NREL Radiance re-distribution
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

--------
WARNING: At least one of the links in the message below goes to an .exe
file, which could be malicious. To learn how to protect yourself, please go
here:
https://commons.lbl.gov/x/_591B
--------

There's no way for this to be the same problem we recently identified.
For one, I don't think Robs gcc is using the MS Universal CRT from Windows
10 which caused that one. And secondly, the character that gets eaten here
is nowhere near a line ending.

Mostapha, can you send me your current test dataset? I only have the
version with 420 names, which does not seem to cause trouble anymore.
Then I'll check if the SCons build has the same issue, and if so, walk
through it to see what really happens.

Cheers
-schorsch

PS: I'm following radiance-dev, no need for a seperate cc.

Am 2016-05-12 00:39, schrieb Gregory J. Ward:
> OK, this seems to happen when a Windows read operation ends halfway
> through a "\r\n" sequence, leaving a '\r' at the end of one buffer and
> reading a '\n' character at the beginning of the next read() call. It
> isn't a bug in my code as far as I'm concerned, as Unix handles this
> case just fine. Rather, I think there's a bug in the way Windows
> replaces "\r\n" with "\n" so that it ends up replacing "\ns" in this
> case with the empty string, effectively lobbing the first character
> off the returned buffer.
>
> We can test this by running a couple of read() calls on an input
> buffer such that the length of the read splits an EOL sequence. This
> may be the source of the occasional dropped characters Schorsch was
> seeing in his earlier tests. Microsoft said they will fix this at
> some point....
>
> Meanwhile, we could try setting the _O_BINARY flag in the open()
> command in wordfile(), assuming we won't run into the ^Z EOF marker
> that Schorsch claims is just a childhood trauma of mine and nothing to
> fear these days...
>
> If Rob is willing to re-compile the librt.a in src/common using the
> attached version of wordfile.c and link it with the debug version of
> rcontrib, we can see if it makes any difference to test my hypothesis.
>
> Cheers,
> -Greg
>
>
>> FROM: Mostapha Sadeghipour <[email protected]>
>>
>> SUBJECT: Re: NREL Radiance re-distribution
>>
>> DATE: May 11, 2016 3:17:59 PM PDT
>
>> Thanks Greg! Let me know if there is anything that I can do on my
>> side to help.
>> Mostapha
>>
>> On Wed, May 11, 2016 at 6:09 PM, Gregory J. Ward > >> <[email protected]> wrote:
>>
>> Hi Mostapha,
>>
>> Your screen capture came through -- now we're getting somewhere!
>> The error again happens near the boundary between read() calls, so
>> it's a matter of figuring out what could be going wrong on Windows
>> even after the earlier bug fix.
>>
>> Schorsch has noticed issues with dropped bytes on stdin, but I don't
>> think we've seen this sort of problem with file input. It could
>> still have something to do with the conversion of "\r\n" EOL
>> sequences to "\n" in O_TEXT input files, but I need to think how this
>> might happen.
>>
>> More later,
>> -Greg
>>
>> FROM: Mostapha Sadeghipour <[email protected]>
>>
>> DATE: May 11, 2016 2:44:18 PM PDT
>>
>> Thanks Rob! Dropbox link worked. Maybe I was doing something wrong.
>>
>> I think we're close. New rcontrib prints out some notes which show
>> that solar1216 is picked up as 8-letter modifier `olar1216` missing
>> the starting s. The rest are 9 letter modifiers. That should be why
>> it never shows up?
>>
>> I almost never copy images in an email but I hope this one shows up
>> right. Let me know if it wasn't and I can save and attach it.
>>
>> Mostapha
>>
>> On Wed, May 11, 2016 at 5:31 PM, Guglielmetti, Robert > >> <[email protected]> wrote:
>> Mo, I'm confused. I double checked the build, and it's 64-bit. What
>> makes you think it's 32-bit? I didn't run your specific test, but I
>> ran it with the '-version' flag and it worked fine. Only thing I can
>> think of is it somehow got messed up as an attachment.(?) Try
>> downloading this re-re-rebuilt copy from Dropbox:
>>
>> Dropbox - File Deleted - Simplify your life
>>
>> A tutorial on how to use the CMake crap we put in there would be
>> nice, wouldn't it? Someday...
>>
>> On 5/11/16, 1:26 PM, "Mostapha Sadeghipour" > >> <[email protected]<mailto:[email protected]>> wrote:
>>
>> Thanks Rob. I couldn't get the new rcontrib to run. It gives me the
>> same error. I will wait for you.
>>
>> PS: I should start to learn how to compile Radiance for Windows from
>> source code. Is there a tutorial somewhere?
>>
>> On Wed, May 11, 2016 at 3:05 PM, Guglielmetti, Robert > >> <[email protected]<mailto:[email protected]>> > >> wrote:
>> Sorry about that, it shouldn't have been (that's scary). I'm in a
>> meeting right now but can look into this in a bit...
>>
>> On 5/11/16, 1:02 PM, "Mostapha Sadeghipour" > >> > > <[email protected]<mailto:[email protected]><mailto:sadeghipou > > [email protected]<mailto:[email protected]>>> > >> wrote:
>>
>> Hello all,
>>
>> Thanks Greg and Rob. Sorry for the delay! I just saw this.
>>
>> Hey Rob. This is again 32-bit. =) I'm downloading the Radiance 32-bit
>> built to test it again. I will report back shortly.
>>
>> Mostapha

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

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

Message: 4
Date: Thu, 12 May 2016 09:58:14 +0200
From: Georg Mischler <[email protected]>
To: code development <[email protected]>
Subject: Re: [Radiance-dev] Meta files and library
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Am 2016-05-12 02:27, schrieb Gregory J. Ward:
> The "graph files" are related to .cal files in an odd way.

"Subtly incompatible" it is then...
So a parser needs to use different patterns/escapes for seperating
statements from each other. Apart from not seeing any of the simulation
specific variables, is that the only difference?

> The pexpand command is called internally, as is psort by image
> converters that want their vector primitives sorted.

That would seem to make more sense as library routines then.
Not sure if refactoring as such would be worth the effort now, though.

>> Since those tools are not used anywhere else, wouldn't it make sense
>> to
>> ditch $MLIB, and simply use $RAYPATH/meta instead?
>
> Except that RAYPATH is a list of directories, where MDIR is a single
> location. All the same, a function that finds the first meta
> directory in $RAYPATH could be used instead.

The new Python scripts do exactly that to find their "pyradlib" support
library. Granted, that one has a more unique name (deliberately so),
which is less likely to collide with something a user might have within
their project.

> Yeah, RIP many disused graphics output devices. We could remove the
> references if anyone cares.

If you have any interest in avoiding confusion among new users,
you should care.

> The plotin tool converts from old-school plot primitives to metafile
> equivalents. I don't know if anyone uses the original graph or plot
> routines anymore, so this could probably be retired as well. The
> functionality is better in bgraph, anyway.

Ah, so "plot files" are indeed something different from "graph files".
Since the plot(5) man page presumably documenting that format is gone,
keeping a program around that depends on it doesn't make much sense.

Cheers
-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

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

Message: 5
Date: Thu, 12 May 2016 10:09:36 +0200
From: Georg Mischler <[email protected]>
To: code development <[email protected]>
Cc: [email protected]
Subject: Re: [Radiance-dev] NREL Radiance re-distribution
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Ah, so now I figured that this wasn't actually on radiance-dev to begin
with...
Mostapha, have you considered joining the list for a while?
And please see my query just below.

Cheers
-schorsch

Am 2016-05-12 09:10, schrieb Georg Mischler:
>
> There's no way for this to be the same problem we recently identified.
> For one, I don't think Robs gcc is using the MS Universal CRT from
> Windows 10 which caused that one. And secondly, the character that gets
> eaten here is nowhere near a line ending.
>
> Mostapha, can you send me your current test dataset? I only have the
> version with 420 names, which does not seem to cause trouble anymore.
> Then I'll check if the SCons build has the same issue, and if so,
> walk through it to see what really happens.
>
> Cheers
> -schorsch
>
> PS: I'm following radiance-dev, no need for a seperate cc.
>
>
> Am 2016-05-12 00:39, schrieb Gregory J. Ward:
>> OK, this seems to happen when a Windows read operation ends halfway
>> through a "\r\n" sequence, leaving a '\r' at the end of one buffer and
>> reading a '\n' character at the beginning of the next read() call. It
>> isn't a bug in my code as far as I'm concerned, as Unix handles this
>> case just fine. Rather, I think there's a bug in the way Windows
>> replaces "\r\n" with "\n" so that it ends up replacing "\ns" in this
>> case with the empty string, effectively lobbing the first character
>> off the returned buffer.
>>
>> We can test this by running a couple of read() calls on an input
>> buffer such that the length of the read splits an EOL sequence. This
>> may be the source of the occasional dropped characters Schorsch was
>> seeing in his earlier tests. Microsoft said they will fix this at
>> some point....
>>
>> Meanwhile, we could try setting the _O_BINARY flag in the open()
>> command in wordfile(), assuming we won't run into the ^Z EOF marker
>> that Schorsch claims is just a childhood trauma of mine and nothing to
>> fear these days...
>>
>> If Rob is willing to re-compile the librt.a in src/common using the
>> attached version of wordfile.c and link it with the debug version of
>> rcontrib, we can see if it makes any difference to test my hypothesis.
>>
>> Cheers,
>> -Greg
>>
>>
>>> FROM: Mostapha Sadeghipour <[email protected]>
>>>
>>> SUBJECT: Re: NREL Radiance re-distribution
>>>
>>> DATE: May 11, 2016 3:17:59 PM PDT
>>
>>> Thanks Greg! Let me know if there is anything that I can do on my
>>> side to help.
>>> Mostapha
>>>
>>> On Wed, May 11, 2016 at 6:09 PM, Gregory J. Ward > >>> <[email protected]> wrote:
>>>
>>> Hi Mostapha,
>>>
>>> Your screen capture came through -- now we're getting somewhere!
>>> The error again happens near the boundary between read() calls, so
>>> it's a matter of figuring out what could be going wrong on Windows
>>> even after the earlier bug fix.
>>>
>>> Schorsch has noticed issues with dropped bytes on stdin, but I don't
>>> think we've seen this sort of problem with file input. It could
>>> still have something to do with the conversion of "\r\n" EOL
>>> sequences to "\n" in O_TEXT input files, but I need to think how
>>> this might happen.
>>>
>>> More later,
>>> -Greg
>>>
>>> FROM: Mostapha Sadeghipour <[email protected]>
>>>
>>> DATE: May 11, 2016 2:44:18 PM PDT
>>>
>>> Thanks Rob! Dropbox link worked. Maybe I was doing something wrong.
>>>
>>> I think we're close. New rcontrib prints out some notes which show
>>> that solar1216 is picked up as 8-letter modifier `olar1216` missing
>>> the starting s. The rest are 9 letter modifiers. That should be why
>>> it never shows up?
>>>
>>> I almost never copy images in an email but I hope this one shows up
>>> right. Let me know if it wasn't and I can save and attach it.
>>>
>>> Mostapha
>>>

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

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

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

End of Radiance-dev Digest, Vol 110, Issue 5
********************************************

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