DIRSIG

According to the webpage, DIRSIG4 is currently only supporting Solaris/SPARC 2.9+ and Linux/x86 2.4 kernels. The next set of releases (dirsig-3.6.5 and dirsig-4.0.7) will come with experimental support for the x86-64 platform. Internally, we have a cluster of Athlon64 machines running Fedora Core 5. The added registers on the 64-bit x86 architecture give a significant speed boost over the 32-bit counterpart. The biggest issue with supporting new platforms is packaging the end product. Solaris is a particular pain because users are poor at keeping their installations up to date. There are still people out there using Solaris 8 when the current OS version is Solaris 10. Another issue is which version of LAM MPI to use for the Linux builds. The key contenders are 7.0.6 and 7.1.2. Most of our userbase tend to have older OS setups, so we will probably use the former.

It occurred to me that the ODB instancing can be used on both solid geometry and voxelized grids. Among other things, this means that grids no longer need to be axis-aligned. Simply stick the solid geometry or grid in a separate ODB file and instance it using the technique discussed in Instancing ODBs .

Another feature coming in DIRSIG 4.0.6 is support for regular voxelized grids. The advantage of these structures is that they allow for extremely fast intersections of regularly spaced boxes. The backend code for implementing these grids is also used by DIRSIG to implement support for the QUIC concentration map outputs. In the ODB file: REGULAR_GRID { INSERT_POINT = 0,0,0 DELTA_X = 20 DELTA_Y = 10 DELTA_Z = 25 GRID_FILENAME = niek.grid } The INSERT_POINT indicates a grid extent, the point with the smallest x,y,z coordinate values. DELTA_X/Y/Z indicates the size, in meters, of each voxel. The GRID_FILENAME indicates where the voxel data is stored. Note that the .grid extension is not required. The contents of the .grid file are as follows: 10 10 10 9 9 0 13 230 0 9 8 0 13 230 0 9 7 0 13 230 0 The first line indicates the number of boxes in the x, y, and z direction. For

The DIRSIG team is working with Los Alamos National Laboratory (LANL) to integrate the Qwick Urban industrial Complex (QUIC) plume model in to DIRSIG. Starting with version 4.0.6, the functionality to read in a QUIC gas concentration output will be available. The functionality is currently experimental, and the syntax is liable to change in future DIRSIG revisions. An example of an NH 3 plume: PLUME { QUIC_INSTANCE { CONCENTRATION_MAP = quic.dat MOLECULAR_WEIGHT = 17.03 MATERIAL_ID = 5 RELEASE_TEMPERATURE = 550 INSERT_POINT = 0,0,0 GRID_OFFSET = 3,3,0 DELTA_X = 1.0 DELTA_Y = 1.0 DELTA_Z = 1.0 } } The CONCENTRATION_MAP indicates the QUIC output file. The MOLECULAR_WEIGHT allows DIRSIG to convert from the [g/m 3 ] used by QUIC to the [ppm] used by DIRSIG. The MATERIAL_ID gives the entry in the materials database supplying the radiometric and thermal properties of the gas. The RELEASE_TEMPERATURE, in kelvin, is a hack, compensa

A helpful hint if you are using PGM images with DIRSIG maps. It is orders of magnitude faster to load a binary (aka "raw") PGM than an ASCII one. The difference is especially visible when loading large images, such as 4k by 4k textures in Microscene1. You can check the PGM format by opening the .pgm file in a text editor. If the first characters in the file are "P2", then you have an ASCII image (notice that all the digital counts are stored in ASCII further down the file). If it says "P5", then it's already binary, so there is nothing left to do. To convert from ASCII to binary PGMs, you can use the freely available image tool GIMP ( www.gimp.org ). Simply open the image, select "Save As" and choose "Raw" when it queries about data formatting.

The current development version of DIRSIG4 supports ODB instancing. Like object instancing, the same ODB can be used multiple times via an affine transformation. This also gives a quick way to rotate entire ODB files. Here's the new syntax: OBJECT { ODB_FILENAME = ./foxbat.odb UNITS = METERS INSTANCES { INFO = 0.00, 0.00, 0.0, 1.00, 1.00, 1.00, 0.00, 0.00, 0.0 INFO = 0.00, 0.00, 0.0, 1.00, 1.00, 1.00, 0.00, 0.00, 90.0 } } This functionality should become available in the next release of DIRSIG4.

In many DIRSIG installations (including the one at the DIRS lab), the included sample scenes are placed into read-only directories. What happens when you want to add additional materials and geometry? This post discusses a neat trick that can help. The obvious, brute-force, method copies scene contents to a writable location (via cp -R). This is clearly a poor solution for complex scenes, such as Megascene1 which takes several gigs of disc space. Furthermore, copies may end up out of sync with any patches and updates applied to the read-only version. Another approach reconstructs the scene directory in a writable location using symbolic links (UNIX ln command), making local copies only of files which need to be changed. This technique can be a pain to set up for complex scene directory layouts. Again, a local copy of the material database can become out of sync with the read-only one. Alternatively, we can take advantage of the INCLUDE_FILE directive. For a material database, we'd

I'm one of the three core developers on the DIRSIG project. This blog is simply an experiment in information dissemination. It's intended for both power users and developers. Hopefully, it will make our development process a bit more transparent.