[Radiance-general] output to .unf file

[Thomas Bleicher]

On 23.01.2006, at 06:56, Huangwx wrote:

> dear all:
>
> I am using a supercomputer which has 128 CPUs, and should be very  
> fast.
> But I found the rendering speed is almost the same as my notepad.

As in life, mere size doesn't matter.

As Martin already said, you have to use the programm "rpiece" not
"rpict" to use more than one CPU. I don't remember the status of
"rpice" on SMP systems but I don't think it will scale up to 128
CPUs.

> A stuff of the super computer said that most time was not taken by
> computation, but by outputing data to files. I think writing data
> to the .unf file must take a lot of time. The supercomputer uses NFS
> storage, so maybe because it is too slow, the rendering cannot be
> finished quickly.

I tested the settings you give below and on my 2GHz PowerPC
("Core Solo") the daffodil test scene ran about 3 seconds.
If you have similar times on your system, saving image data
on a slow NFS system may indeed have an impact on your process.
But that's a problem of your NFS then, not of Radiance.

If you can set up a RAM disc on your nodes you could use that
to store the image computed on one node and copy the final
image to the shared storage space. But I don't think that's
possible on a managed cluster. (Perhaps there is a /tmp FS
local to each cluster node?) But you still have to share
your ambient data (in the day.amb file) across all nodes to
get the real benefit of multiple cpus.

Given your settings your need for render speed is _not_
render quality (pretty low). As well your image dimensions
are small. What are you trying to render in the end?
If it's an animation you could use "ranimate" to distribute
frame rendering to separate nodes explicitly.

> If there is any way that radiance do not use the NFS storage
> during rendering, but only the memory, I think the speed could
> be greatly improved.

You should share your ambient data (in the "day.amb" file)
between all nodes to get the benefit of multiple CPUs and to
avoid variations between frames or image parts. If this slows
down your system don't use the "-af day.amb" option and
rpict will use the memory during calculations (on each node
separately).

The image data is written to STDOUT by rpict. If you can
redirect to a local FS on each node you don't have to use NFS
all the time (like I said "/tmp" may be a local FS on each node).
Don't forget to copy the final image to your NFS area, though.
I use RAM discs when I have do create a lot of small files
for a short time only. Speed has not been a consideration,
only HD movements and noise.

Your settings for reference. You should provide information
about your rendering setup (which commands, control files)
and what you actually want to do (BIG image vs. animation vs.
high detail rendering) on the cluster, too.

> The rendering parameters in .opt file:
> -dp 256
> -ar 28
> -ms 2.6e+02
> -ds .3
> -dt .1
> -dc .5
> -dr 1
> -sj .7
> -st .1
> -ab 2
> -af day.amb
> -ad 329
> -as 42
> -av 0.36 0.36 0.36
> -lr 8
> -lw .002
> -st .001
> -dj .02
> -aa 0.25
> The image size: 256x176

HTH,

Thomas