HEMIVIEW module information

The HEMIVIEW module calculates diffuse blackbody view factors using the hemicube method, which allows computer graphics hardware to accelerate the calculations.

The HEMIVIEW module requests start with Card 6v HEMI ON and end with HEMI OFF. Between these cards is the body of the HEMIVIEW requests. Details of the calculations are written to the verbose and report log files. Results are written on file VUFF.

The HEMIVIEW module has two different operational modes: off-screen and off-screen. In the off-screen mode there are options to use either the graphic card based rendering to take advantage of hardware acceleration in the graphics card or software based rendering for cases where the loss of hardware acceleration can be compensated by better parallel processing performance or, on Linux platform, for use on machines that do not have graphics cards or the X-server running.

In off-screen mode, a fixed size window is popped-up in the top corner of the left hand side of the screen and the images are directly rendered to the window. This window must not be obscured, and it cannot be resized. A disadvantage of the off-screen mode is that it is less robust. The window must not be obscured, the computer cannot be locked, and no screen saver can be activated while the module is running. The off-screen mode is currently available only on Windows platforms, as a non-default option. It can be activated either through an advanced solver parameter (HOR), or through specifying the Card 9 GPARAM 56 28 1.

In the off-screen mode, no popped-up window can be seen and the images are rendered directly to either the memory of the graphics card or the CPU memory. On UNIX platforms, the graphic card is used through the pBuffer, which allows hardware accelerated rendering. On Windows platforms, by default, this is done with device-independent bitmaps (DIB), which use software-based rendering without hardware acceleration in the graphic card. For graphic cards that support Windows-specific WGL pBuffer extension to OpenGL, the hardware accelerated rendering can be enabled in the off-screen mode on Windows platforms by specifying Card 9 GPARAM 56 28 -1. For newer graphic cards that support OpenGL frame buffer objects (FBO) through the GL_EXT_framebuffer_object OpenGL extension, an FBO-based off-screen mode can be used for hardware accelerated rendering on both Windows and Linux platforms, by specifying Card 9 GPARAM 56 28 -2. Only one of those Card 9 GPARAM 56 28 X settings should be used in a given run.

On Windows and Linux platforms, there is also an off-screen mode that exploits software rendering in the CPU memory via the OSMesa API of the Mesa 3D Graphics Library. That option uses a different HEMIVIEW executable, which is statically linked to the OSMesa library and does not have any dependencies on either the presence of the graphic card or the X server running or the X libraries availability on the machines. To activate that option one can either add GPARAM 0 47 1 to Card 9 or set the TMG_HEMI_OSMESA environment variable to ON.

When the graphic card based rendering is used, one may not get a performance advantage from HEMIVIEW multiprocessing with multiple HEMIVIEW processors per machine because those processes would be competing for the same graphic card resources.

For HEMIVIEW performance diagnostics in different operational modes one can also use Card 9 GPARAM 56 41 1 setting, which will activate printing of some of the HEMIVIEW key timing statistics to the run standard output not to the verbose log file.

Remote rendering

It is possible to specify rendering on a remote graphic card on a network. To do this, with either the on- or off-screen modes, the DISPLAY environmental variable must be properly set. Remote rendering is slower than local, especially on UNIX platforms, because X server is invoked to perform a series of actions such as encoding and decoding Open-GL commands, and the rendering is indirect.

The most frequently encountered problem with remote rendering is the availability of the remote graphics card, especially on UNIX platforms. Often access to the card is not permitted, or there is no active display available. To enable access control on UNIX platforms, the local user must run xhost + <host_name> where <host_name> is the machine name from which the connection request to the graphic card is made.

Another problem often encountered with remote rendering is the unavailability of the display. The display is not available when the remote computer is off, when there is no local login session running using the local graphic card, or when the number of clients or graphic applications using the graphics card has reached its allowable limit.

Any remote graphics card on the network can be used by HEMIVIEW. A robust procedure is used to ensure the availability of a graphics card. If the desired graphics card is not local, and is not defined with the user’s $DISPLAY variable, it can be specified by the TMG_HEMI_DISP environmental variable. HEMIVIEW first checks if TMG_HEMI_DISP is defined. If it is, HEMIVIEW tries to connect to it. If it is not defined, or the access to it is denied, HEMIVIEW tries to use the local display, i.e., the graphics card on the local host machine, the machine on which TMG is running. If this graphics card is not accessible, HEMIVIEW tries to use the display specified by the DISPLAY environment variable as the last resort. If no display is available after the above three steps, a FATAL error is issued and HEMIVIEW terminates.