rtcontrib - funky error when using -n

Hi List -

I have two questions related to rtcontrib. I'll send two messages for separate discussion threads.

The first is about multi-core runs and a strange error, the second about setting the maximum number of open files on OSX.

Multi-core runs question:
The following command uses 8 processors and successfully generates a bin of 578 .hdr images based on test.oct made of scene geometry, material descriptions and an isotropic sky:

vwrays -ff -vf view.vf -x 800 -y 800 | rtcontrib -n 8 -ab 3 -ad 4000 -as 1000 -dt .05 -ds .1 -dc .17 -lw 9e-19 -e MF:2 -ffc $(vwrays -d -vf view.vf -x 800 -y 800) -f reinhart.cal -b rbin -o bin/%0d.hdr -m sky_glow -w tmp/test.oct

For some reason, one of the bin images is funky (381.hdr in this case) and when I try to do anything with it I get a read error. Example:
pvalue -o -h -H 381.hdr > test.txt
pvalue: read error

I found that I can still view the bad image with ximage, and here the error shows up. The image is shifted 82 pixels to the left, with the clipped pixels placed on the right side of the image.

I re-did the simulation using the exact same command but with just one processor (no -n option) and everything works out fine and dandy. Has anyone else encountered this kind of oddity with multi-core runs and rtcontrib?

Thanks!

Michael

Hi Michael,

Everyone was so busy on your second question, looks like the first one was neglected:

Multi-core runs question:
The following command uses 8 processors and successfully generates a bin of 578 .hdr images based on test.oct made of scene geometry, material descriptions and an isotropic sky:

vwrays -ff -vf view.vf -x 800 -y 800 | rtcontrib -n 8 -ab 3 -ad 4000 -as 1000 -dt .05 -ds .1 -dc .17 -lw 9e-19 -e MF:2 -ffc $(vwrays -d -vf view.vf -x 800 -y 800) -f reinhart.cal -b rbin -o bin/%0d.hdr -m sky_glow -w tmp/test.oct

I can't be sure, but most likely you've run into the "bin counting problem." Quoting the rtcontrib man page:

  The actual bin number is computed at run time based
       on ray direction and surface intersection, as described below. If the
       number of bins is known in advance, it should be specified with the -bn
       option, and this is critical for output files containing multiple val-
       ues per record. A variable or constant name may be given for this
       parameter if it has been defined via a previous -f or -e option. Since
       bin numbers start from 0, the bin count is always equal to the last bin
       plus 1. Set the this value to 0 if the bin count is unknown (the
       default).

Not having the -bn option causes trouble in a lot of cases where there isn't always a ray striking the last bin.

Hope this fixes it!

-Greg

Thanks Greg - that did it. Everything is working smoothly now.

ยทยทยท

On Jul 20, 2011, at 2:41 PM, Greg Ward wrote:

Hi Michael,

Everyone was so busy on your second question, looks like the first one was neglected:

Multi-core runs question:
The following command uses 8 processors and successfully generates a bin of 578 .hdr images based on test.oct made of scene geometry, material descriptions and an isotropic sky:

vwrays -ff -vf view.vf -x 800 -y 800 | rtcontrib -n 8 -ab 3 -ad 4000 -as 1000 -dt .05 -ds .1 -dc .17 -lw 9e-19 -e MF:2 -ffc $(vwrays -d -vf view.vf -x 800 -y 800) -f reinhart.cal -b rbin -o bin/%0d.hdr -m sky_glow -w tmp/test.oct

I can't be sure, but most likely you've run into the "bin counting problem." Quoting the rtcontrib man page:

  The actual bin number is computed at run time based
      on ray direction and surface intersection, as described below. If the
      number of bins is known in advance, it should be specified with the -bn
      option, and this is critical for output files containing multiple val-
      ues per record. A variable or constant name may be given for this
      parameter if it has been defined via a previous -f or -e option. Since
      bin numbers start from 0, the bin count is always equal to the last bin
      plus 1. Set the this value to 0 if the bin count is unknown (the
      default).

Not having the -bn option causes trouble in a lot of cases where there isn't always a ray striking the last bin.

Hope this fixes it!

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