Rtrace - several questions

1

Hi,

I have several questions on rtrace…

  1. Is there a way to create sensor points (.pts) on the input obj file with some Radiance modules or with some command-line tools?
  2. Running in parallel is possible? Is there a way to implement this?
  3. Progress report - at least showing the rays amount (without checking the size of the output).

Thank you.

2

Hi Ilker,

I am going through your questions one by one:

Is there a way to create sensor points (.pts) on the input obj
file with some Radiance modules or with some command-line tools?

A rectangular grid of points can be created quite easily with cnt, a
multi-dimensional counter, and rcalc, a column-wise calculator. E.g. to
generate a grid of 10 x 15 sensors at a heigth of 0.85m and 0.5m apart,
starting at x,y=0.25,0.25, with direction vectors pointing up as input
to rtrace:

cnt 10 15 | rcalc -e ‘$1=.25+$10.5; $2=.25+$20.5;$3=.85; $4=0; $5=0;
$6=1’ | rtrace -I -ov model.oct

You could probably speed up this by switching the data format to binary
floats rather than the default chars.

Running in parallel is possible? Is there a way to implement this?

Please check the rtrace manpage for the -n parameter.

Progress report - at least showing the rays amount (without
checking the size of the output).

You can e.g. use the tee command to “split” the results stream, and pipe
it into wc -l to count its lines. These are equal to the processed sensors.

Best, Lars.

3

Thank you for the answers.

  1. cnt module can be very efficient to create a planar work-plane but I am trying to create sensor points for the buildings in a complex urban scene. I have written my own console application for the sensor points, it just subdivides the input mesh and then exports vertices positions and normals to a *.pts file. However, when a sensor point is directly located on the building surface, it results in 0 lux, there. So, I need to offset them, however, it doesn’t work properly for complex geometries, because offset should be implemented in a way that it understands the offset direction. Otherwise, some of the points will stay in the inner part of the geometry.

  2. Simply using -n option doesn’t work, I have tried it, before. The console window shows “only single process is supported”

  3. Could you please implement it for the syntax below? I couldn’t understand, exactly.

rtrace -I -h -dp 2048 -ms 0.063 -ds .2 -dt .05 -dc .75 -dr 3 -st .01 -lr 12 -lw .0005 -ab 2 -ad 1000 -as 20 -ar 300 -aa 0.1 Trial.oct< subdivided.pts > Trial.dat

Thank you again.

4

For (1), John Mardeljevic and others have used a two-step process, whereby rtrace is used to determine where surfaces are in an environment, and the output is used to place points for the “money” run.

For (2), the normal parallel processing options are not supported in Windows due to its very different methods for memory sharing, which are incompatible with the genesis of Radiance tools on Unix. However, you can break up your points and send them to multiple rtrace processes to achieve some degree of parallelism manually.

For (3), I think Lars was trying to recommend tee, rather than rsplit, as the latter tool does not duplicate data, but splits it apart. Anyway, you still wouldn’t see the result out of wc until the process had finished. In the end, there is no better method than checking output file size, which is subject to buffering, but that can be controlled using the rtrace -x option.

5

Thank you Greg.

  1. Could you please offer me a specific paper for the 2 steps approach? Is there a Radiance module for this?
  2. The manually dividing points into different rtrace runs also gives the same amount of total time. I think this is due to the reason that the calculation for the first point needs some caching which takes considerable time comparing with the remaining part of the run.
  3. I am not so familiar with this but will try -x approach. With the syntax that I shared, the size of the output file only changes at the end of the run, so I couldn’t follow the file size approach.
6

It took me some effort to find this, and I’m not sure if it’s 100% relevant, but the technique I mentioned for (1) is in this post, although the PDF link seems to be dangling.

To save time in parallel runs (2) , be sure to share the ambient file if you are using -ab 1 or greater by specifying the same -af option for every rtrace invocation.

If you set rtrace -x 1 for judging doneness (3), it will send out every value as it’s calculated.

7

Hi,

Thank you again, this is a great community! I will share a video on what I have achieved until now. But this is the offset problem that I have mentioned.

image
image1600×634 199 KB

  1. There is a paper on using vertices of OpenFoam mesh as input points for the rtrace calculations. I think they have used a script to offset vertices positions according to the surface mesh. This is valid for the plugins like Ladybug and Diva. Both of them requires offset of the grid points from the surface.The paper mentioned

2-3. will try and let you know.

8

Missing stuff here: http://climate-based-daylighting.com/doku.php?id=resources:radiance

9

Thank you John! It is excellent to get a contribution from the author, directly.

10

Here’s another using OpenFoam and rtrace: https://repository.lboro.ac.uk/articles/Annual_solar_irradiation_mapping_and_visualization_for_complex_geometries/9433988

11

Thank you, again. I have tried the stencil approach, but couldn’t adapt it from bash to batch. So, I have switched back to offsetting vertices from the façade. After several days of trials, it worked!
Parallel run also works, I have just divided input sensor points to 8 (# of cpu’s for me) distinct files, then run parallel batch for each of them with rtrace instances. I have also got important steps on reading the output file of rtrace to track simulation progress. However, the high cpu usage due to instances prevents reading the file, accurately, but will solve it.

Last, here is the video output from the interface that I have mentioned. It just took 10 mnts to run an annual simulation and get 3D output for a complex urban setting from very beginning:

1 Like