Description

When available, FRED will distribute computational tasks among multiple CPU cores in a multi-threading operation.  This can significantly reduce the time required to perform raytraces and calculations.  The following points regarding multi-threading should be noted:

•The ray trace is forced to single-threaded when the rays are being drawn to the screen.

•Currently, the ray trace and energy calculations are multi-threaded.

•When the trace is multi-threaded, the number of threads used obeys the following rules:

•An Advanced Raytrace is not required to get a multi-threaded trace. Trace All Sources and Trace Existing Sources also implement the multi-threaded tracing capability.

Application Notes

Live rays and interlacing (multi-threading)

FRED allows paging of the ray data to disk, which allows an arbitrary number of rays to be traced through the system.  When paging to disk FRED still operates multi-threaded.

Consider tracing ten rays using two CPUs.  Upon executing a trace command, FRED allocates individual rays to the available processors in an ordered fashion as illustrated below.

As the raytrace proceeds, new child rays will be created due to ray splitting at specular, scattering or diffractive events. Child rays are created and traced in the same buffer as their parent rays to help reduce the need for communication between CPUs, which tends to slow the multi-threaded raytrace. In the general case, some parent rays will generate child rays and some will not. When the raytrace finishes the ray buffers might be filled in the manner illustrated below, where we can see that more child rays were created in the first thread than in the second. Since FRED must maintain parent-child relationships, rays are not re-numbered when assembled into the main ray buffer:

It becomes obvious upon inspection that there is no ray 15 or 17, yet their slots in the buffer have been reserved. We can now identify rays 0-14, 16 and 18 as "Live" rays. Rays 15 and 17, if accessed, will generate a scripting error.

Note that the concept of a "Live" ray has no relationship to whether a ray is Active or not (see IsRayActive and SetRayActive). Any "Live" ray can have its Active flag set to True or False.

Looping over rays in script

When looping over rays in the buffer via scripting, the loop needs to be structured in a way that accounts for the concept of "live rays" as described in the previous section.  The following loop structures are recommended when iterating over the ray buffer in the scripting language.

While Loop Structure (first ray to last ray):

Dim success As Boolean

Dim curRay As Long

Dim tRay As T_RAY

success = GetFirstRay( curRay, tRay )

While success

          'Do stuff with ray information stored in tRay

          success = GetNextRay( curRay, tRay )

Wend

While Loop Structure (last ray to first ray):

Dim success As Boolean

Dim curRay As Long

Dim tRay As T_RAY

success = GetLastRay( curRay, tRay)

While success

'Do stuff with ray information stored in tRay

 success = GetPreviousRay( curRay, tRay)

Wend

For Loop Structure:

Dim success As Boolean

Dim curRay As Long

Dim tRay As T_RAY

For curRay = 0 To GetRayCount()-1

          If IsRayLive(curRay) Then

                    GetRay curRay, tRay

                    'Do stuff with ray information stored in tRay          

          End If

Next curRay

Number of rays and scripting commands

Prior to FRED version 16.41, a maximum of 2³¹ rays could be traced and analyzed.  Starting in FRED version 16.41, up to 2⁶³ rays can be traced and analyzed.  Scripting commands that access ray data from the ray buffer will generally accept an integer value as an argument or return an integer value after execution, where the integer value indicates a specific ray being operated on or a ray count.  Prior to FRED version 16.41, the integer values were dimensioned as data type Long in the scripting language and supported up to 2³¹ rays.  Since a value greater than 2³¹ cannot be represented by a Long data type, it may be necessary to dimension ray index or ray counter variables as data type Huge_ in FRED version 16.41 (or newer) when more than 2³¹ rays are present in your system.

When raytracing more than 2³¹ rays, dimension ray index and ray counter variables as data type Huge_ rather than data type Long in the scripting language. 

Scripted Entities and Document Modifications

It is strongly recommended that the scripted entities (surfaces, materials, coatings, scatter models) make no modifications to other nodes in the FRED document.

If a change is made to the document during the raytrace by way of a scripted entity, the state of the document as seen by each individual thread of the raytrace will be inconsistently defined and the results of the raytrace may not be valid.