Rtrace -PP problem

radiance-general
1

Hi,

I’m trying to use the “-PP” option with rtrace.
However, no matter what I do it seems that only the first process that was created does any actual work.

My call sequence goes something like that:

rtrace -h -w -ad 0 -av 0.000000e+00 0.000000e+00 1.000000e+00 -ovpn -fff -ab 0 -dj 0 -aa 0.000000 -as 0 -st 1.000000 -ss 0.000000 -lr 0 -PP temp.ctl temp.oct <temp.pts.1 >temp.out.1 &
rtrace -PP temp.ctl temp.oct <temp.pts.2 >temp.out.2 &
rtrace -PP temp.ctl temp.oct <temp.pts.3 >temp.out.3 &

Am I using this wrong?

2

The only example I can find in my files manages this via python, so no guarantees, but the general idea is you start the parent process without querying any rays (best to do this in a different terminal, rather than putting it in the background with &), this way you can also leave warnings on and possibly get some feedback:

 rtrace -h -w -ad 0 -av 0.000000e+00 0.000000e+00 1.000000e+00 -ovpn -fff -ab 0 -dj 0 -aa 0.000000 -as 0 -st 1.000000 -ss 0.000000 -lr 0 -PP temp.ctl temp.oct

Then, once this has loaded the scene, you can make subsequent calls, but all you need to reference is the control file:

rtrace -PP temp.ctl <temp.pts.1 >temp.out.1 &
rtrace -PP temp.ctl <temp.pts.2 >temp.out.2 &
rtrace -PP temp.ctl <temp.pts.3 >temp.out.3 &
3

I think you are using the -PP option correctly. It does take several seconds (5-7) before actual work can begin on the second and subsequent processes. Are the second and third processes hung – i.e., do they ever finish? What system are you running this on?

Also, your calculation is so simple (-ab 0) that unless you have a great many rays to trace, there isn’t much need for multi-processing. I suppose you are just doing this as a test. I tried something similar on my Mac laptop, and all three processes ran fine.

4

Indeed in my use case I have a very large amount of rays to trace. The processes finish, but when looking at the activity monitor (I’m on Mac), I see that they barely take up any CPU %, and the main process takes almost 100%. Also when timing the overall runtime, it’s actually slower than just using the -n 1 option. So I’m suspecting that for some reason the other processes don’t really kick in.

5

Again, unless you really have a lot of rays to trace, the -PP option might not make sense for your problem. You also have to be careful about which rtrace processes you are looking at – did you sort them by CPU usage? The process number you start with the shell ends up just passing i/o, and there’s another rtrace process that gets started to do the actual ray-tracing.

Also, why not just use the -n option of rtrace for your problem? I don’t think that -PP really has an advantage, unless you are trying to keep the inputs and outputs separate. (You can always concatenate them.) The rtrace -n option guarantees balance between the multiple processes with a FIFO queuing mechanism.