New rtrace -n option

radiance-general
#1

Hi All,

I just finished testing a new parallel processing option for rtrace (-n). It should work on all multicore Unix (Linux, Mac OS X) machines. Download the HEAD from www.radiance-online.org and give it a whirl. Getting the -I option working was the real trick, so let me know of any differences you spot in your results if you use it.

The only major caveat is that the -o*t* (trace tree) options won't work properly, as all the output will be randomly interleaved. Not much I can do about that, I'm afraid.

Please don't ask when -n will be added to rpict. It won't. I have spent some time looking at it, and we're stuck with rpiece for the forseeable future. The good news is that rpiece works just fine on multicore machines. It's only when you open it up to a network of machines that it starts to be troublesome, and a -n option in rpict wouldn't help that situation, anyway.

Cheers,
-Greg

#2

Hmmm. I downloaded the HEAD, ran makeall, but rtrace gives an unknown option
error on -n. My rtrace binary is five minutes old, and the rtrace.c file it
was compiled from is dated Dec 14 00:31. Did I jump on that download a
little too fast, Greg?

···

On 12/15/09 11:56 AM, "Gregory J. Ward" <gregoryjward@gmail.com> wrote:

Hi All,

I just finished testing a new parallel processing option for rtrace (-
n). It should work on all multicore Unix (Linux, Mac OS X) machines.
Download the HEAD from www.radiance-online.org and give it a whirl.

#3

In what should come as no surprise to anyone on this list, this was a user
error situation. Sorry.

$ ls -l /usr/local/bin/rtrace
$ -rwxr-xr-x 1 root wheel 397736 Dec 15 13:09 /usr/local/bin/rtrace
$ which rtrace
$ /usr/local/bin/RAY/rtrace (you idiot)

OK, so that's sorted. But in testing out the -n option, I do notice a
strange behavior. If you have a bogus material definition in your scene
files -- even if it is not referenced in the octree -- using rtrace with the
-n option will throw a fatal error about the material definition and quit.
Again, this is not a material that is actually used in the octree, no ray
would ever need to evaluate the definition; it's an unassigned material that
happens to reference a .cal file that's not on my system. But I compiled an
octree and I ran rpict twice on the same octree. Once without the -n, and
that ran fine. Then I ran the same exact command adding "-n 10" and I got
this error:

rtrace: fatal - cannot find function file "glaz.cal"

I went back and deleted the bogus material from my material file completely,
recompiled, and now rtrace -n works. Not sure what's going on there.

Thank you for this addition, Greg! It's nice to feed rtrace one grid and
watch top automatically fill up with all these rtrace processes!

- Rob G.

···

On 12/15/09 1:56 PM, "Robert Guglielmetti" <robert.guglielmetti@nrel.gov> wrote:

Hmmm. I downloaded the HEAD, ran makeall, but rtrace gives an unknown option
error on -n. My rtrace binary is five minutes old, and the rtrace.c file it
was compiled from is dated Dec 14 00:31. Did I jump on that download a
little too fast, Greg?

#4

Hi Rob,

Thanks for the feedback.

The bogus material error is caused by the function preload_objs(), which goes through and loads all the auxiliary data (including .cal files) for all scene objects, whether referenced or not. This function is called by any of the shared-memory parallel execution modes to maximize static shared data, thereby minimizing system memory use. The same thing would happen with the -PP option.

Cheers,
-Greg

···

From: "Guglielmetti, Robert" <Robert.Guglielmetti@nrel.gov>
Date: December 15, 2009 2:36:37 PM PST

On 12/15/09 1:56 PM, "Robert Guglielmetti" <robert.guglielmetti@nrel.gov > > > wrote:

Hmmm. I downloaded the HEAD, ran makeall, but rtrace gives an unknown option
error on -n. My rtrace binary is five minutes old, and the rtrace.c file it
was compiled from is dated Dec 14 00:31. Did I jump on that download a
little too fast, Greg?

In what should come as no surprise to anyone on this list, this was a user
error situation. Sorry.

$ ls -l /usr/local/bin/rtrace
$ -rwxr-xr-x 1 root wheel 397736 Dec 15 13:09 /usr/local/bin/rtrace
$ which rtrace
$ /usr/local/bin/RAY/rtrace (you idiot)

OK, so that's sorted. But in testing out the -n option, I do notice a
strange behavior. If you have a bogus material definition in your scene
files -- even if it is not referenced in the octree -- using rtrace with the
-n option will throw a fatal error about the material definition and quit.
Again, this is not a material that is actually used in the octree, no ray
would ever need to evaluate the definition; it's an unassigned material that
happens to reference a .cal file that's not on my system. But I compiled an
octree and I ran rpict twice on the same octree. Once without the -n, and
that ran fine. Then I ran the same exact command adding "-n 10" and I got
this error:

rtrace: fatal - cannot find function file "glaz.cal"

I went back and deleted the bogus material from my material file completely,
recompiled, and now rtrace -n works. Not sure what's going on there.

Thank you for this addition, Greg! It's nice to feed rtrace one grid and
watch top automatically fill up with all these rtrace processes!

- Rob G.

#5

Thank you again, makes perfect sense.

- Rob

···

On 12/15/09 4:21 PM, "Greg Ward" <gregoryjward@gmail.com> wrote:

Hi Rob,

Thanks for the feedback.

The bogus material error is caused by the function preload_objs(),
which goes through and loads all the auxiliary data (including .cal
files) for all scene objects, whether referenced or not.