This document attempts to explain the various methods available to supply, import or predict the temperatures of surfaces and volumes in DIRSIG.

Temperature Prediction

The first class of approaches involves the use of predictive models to estimate the temperature of surfaces. These temperatures are predicted using material thermodynamic properties (thermal conductivity, heat capacity, etc.) and environmental conditions (air temperature, relative humidity, wind speed, etc.).

Using the THERM Temperature Solver

The THERM model was written by DCS Corporation in the late 1980’s to support the USAF AIRSIM program. The model formulation is essentially a 1D slab model, where the slab has uniform thermodynamic properties within a vertical volume with a user-defined thickness. N hours prior to the desired prediction time the temperature of the 1D slab is initialized to the air temperature. Then the model is iterated forward in time by performing a forward chaining set of radiative and convective flux calculations. When the model reaches the desired time, the model is assumed to have stabilized to a temperature reflecting the loading history and that is independent of the initial temperature. The number of hours into the past required to seed the model and forward chain the flux calculations is dependent on the environmental conditions and the material’s specific thermodynamic properties. For thick, lower conductivity materials such as a thick slab of concrete, the number of virtual hours before the desired can be nearly 24 hours. For thin, high conductivity materials this time can be a fraction of an hour.

The original FORTRAN code for the model was made available to RIT for incorporation into early versions of DIRSIG. As part of the DIRSIG4 development effort, the FORTRAN code was rewritten into C++ and an effort to streamline and optimize the code was undertaken, which included the following improvements:

  • The solar ephemeris calculation was replaced by the DE405 implementation used by the rest of DIRSIG (which includes caching of sun positions as a function of time).

  • Several material independent start-up calculations were moved to a single initialization phase to avoid duplicating common calculations for each run of the model.

  • The number of hours required to reach a stable temperature was originally fixed at 24 hours, but the new version automatically optimizes this time on a per material basis.

Strengths

The following are considered strengths of this method:

  • The THERM model is has a small set of input parameters that can be found in many resources.

  • This temperature model was the one validated as part of DIRSIG on several occasions.

Limitations

The following are considered limitations to this method:

  • The THERM model does not support for internally driven heat fluxes that produce heat signatures like the warming on the hood of a car because of the hot engine beneath it.

  • THERM is a 1D model and does not support conduction from "connected" objects. For example, a hot surface on an airplane (because it is exposed to strong sun) does not laterally transfer heat to the portion of the plane in the shade.

Configuration

The THERM temperature solver is requested via Therm temperature solver name. An example configuration is shown and discussed below:

    TEMP_SOLVER_NAME = Therm
    TEMP_SOLVER {
       SPECIFIC_HEAT        = 2.4000
       MASS_DENSITY         = 1.6000
       THERMAL_CONDUCTIVITY = 0.0200
       EXPOSED_AREA         = 0.5000
       THICKNESS            = 1.0000
       SOLAR_ABSORPTION     = 1.0000
       THERMAL_EMISSIVITY   = 0.9000
    }
Table 1. THERM parameters, units and descriptions.
Parameter Required Units Description

SPECIFIC_HEAT

Required

cal/g/oC

Specific heat

MASS_DENSITY

Required

gm/cm3

Mass density

THERMAL_CONDUCTIVITY

Required

(cm Langley)/hour/oC

The thermal conductivity

EXPOSED_AREA

Required

(fraction)

Surface exposed area

THICKNESS

Optional

cm

Characteristic thickness

SOLAR_ABSORPTION

Optional

(fraction)

Mean, broad-band solar absorptivity

THERMAL_EMISSIVITY

Optional

(fraction)

Mean, broad-band thermal emissivity

SELF_GENERATED_POWER

Optional

Langley/hour

Internal (self-generated) power source term

Useful/Important units descriptions and conversions:

  • 1 Langley = 1 cal/cm2

  • 1 Langley/hour = 11.622 watts/m2

    • Or, 1 watts/m2 = 0.0860 Langley/hour

  • 1 (cm Langley)/hour/oC = 0.11622 watts/(m K)

    • Or, 1 watts/(m K) = 8.604 (cm Langley)/hour/oC

Note The units in the material database are the native THERM units, but they are not exactly common (e.g. the use of Langleys). The DIRSIG graphical Material Editor tool allows your to enter these parameters in more commonly used metric units and save them as the native THERM units.
Exposed Area

The EXPOSED_AREA variable is used to communicate the amount of exposure the facet has to the ambient air. For example, a facet may be a slab of parking lot asphalt that is exposed to the air only on the top side. In contrast, a facet may be a vertical panel or fence that is exposed to the ambient air on both the front and back sides. The differences between these two cases is very important since the convective load in each case differs significantly. The sign of this exposure term is used to indicate one of these two possibilities. In addition to controlling to the convective processes, this term plays a roll in the radiational loading of a surface (for example, describing how much of a surface is exposed to the cold sky). Using the original documentation from the DCS Corporation, we provide the following as a guideline:

  • -0.35-0.65 for surfaces exposed on both sides

  • +0.35+0.65 for surfaces exposed on the top side only

The magnitude of this value can be used to capture the implicit surface roughness of the surface. A value greater than 0.5 will increase the convective heat transfer rate, which would be appropriate for a rough surface that forms a turbulent air flow over it. Whereas a value less than 0.5 might be more appropriate for a smoother surface that maintains a laminar flow and a thin insulative boundary layer over it.

Thickness

The DIRSIG GDB file allows a thickness to be supplied with each facet in the object. However, most 3D geometry formats (e.g. OBJ, etc.) do not have such a feature. Hence, the thickness can be provided on a per material basis. If you need to attribute an OBJ object with the same material but varying thicknesses, you will need to make multiple materials, each with the same parameters except the THICKNESS.

Important The THICKNESS variable will override any thickness values that were supplied on a per-facet basis via a GDB file.
Broad-band Optical Properties

The broad-band SOLAR_ABSORPTION and/or THERMAL_EMISSIVITY values will override values that are automatically derived from the optical properties associated with the material.

Relevant Demos

  • Almost all DIRSIG scenes that have support for thermal predictions use the THERM model.

  • The Thermal1 demo includes a few examples of THERM driven temperature solutions.

Using the Balfour Temperature Solver

The Balfour model is a semi-physical, empirical model intended for background materials such as rock, dirt, grass, etc. [1]. The model makes a key assumption that "the radiating surface of many natural background elements are in a steady state of heat transfer with its surroundings."

The model uses four environmental variables:

  • Solar irradiance

  • Atmospheric irradiance

  • Air temperature

  • Wind speed

The model also takes five material specific fit coefficients. The mathematical formulation is as follows:

\begin{equation*} T_s = a_0 + a_1 \cos{(\theta)} E_s + a_2 E_i + a_3 T_a + a_4 W T_a \end{equation*}

where Ts is the surface temperature in Celsius, Es is the direct solar irradiance in Watts/m2, Ei is the diffuse sky irradiance in Watts/m2, Ta is the air temperature in Kelvin, W is the wind speed in meters/second and a0 through a4 are the material specific coefficients.

There are several ways to derive the material specific fit coefficients. One technique is to use five or more measurements and to apply a least squares fit. The matrix rows consist of the measurements for wind speed, irradiances, and air temperature corresponding to the model equation. The right hand side consists of the associated (known) surface temperature measurements. It is then a simple matter to solve for the coefficient vector. Note that one can also derive much of this "known measurement" information from multispectral thermal imagery. Thus, there are alternative methods of solving for the coefficients. The fit coefficients should be constant with time, so they could also be derived from temporal imagery of the material.

Strengths

The following are considered strengths of this method:

  • The primary advantages of this model is it’s simplicity and that it requires a minimal environmental data and fit parameters for the a given material can be derived from a small dataset.

Limitations

The following are considered limitations to this method:

  • RIT has found that the fitted coefficients are generally tied to the weather data that they were fitted with. This means that a set of Balfour coefficients are not inherent values that can be applied to arbitrary weather conditions. A detailed derivation of the Balfour equation reveals that each coefficient contains the wind speed, which can vary as a function of time.

  • In DIRSIG4, the coefficients are spatially constant for a given material so the variation within a material will be due to spatially varying environmental conditions (for example, being in shadow or not). In DIRSIG5, this was addressed with the option to use spatially mapped coefficients. This option is discussed more below.

  • In DIRSIG4, there is no way to model "thermal inertia" effects. Since the model only uses the current weather conditions, it doesn’t know that a given location might have been in shadow for the last N hours and only recently was exposed to the Sun. In that case, a patch of asphalt might expected to hold onto it’s "coldness" for some period of time. In DIRSIG5, this was addressed by the introduction of an additional coefficient that acts as the time constant for an iterative approach. This option is discussed more below.

Configuration

The Balfour temperature solver is requested via Balfour temperature solver name. An example configuration is shown and discussed below:

    TEMP_SOLVER_NAME = Balfour
    TEMP_SOLVER {
        A0 = -268.876
        A1 = 6.30008e-06
        A2 = 0.00567805
        A3 = 0.976968
        A4 = 0.00041509
    }
Note The optional A5 parameter was introduced by RIT to create the iterative Balfour variant in DIRSIG5.

DIRSIG5 also supports a spatially-varying version of the Balfour model. Rather than supplying a spatially constant set of coefficients, the user supplies an ENVI image cube of parameters. The image file is expected to be a 5 band, floating-point data cube (single or double precision) where the bands directly correspond to the A0A4 variables. The standard map projection options can be used to specify how the map is geometrically projected into the scene. The example below shows a mapped Balfour configuration:

    TEMP_SOLVER_NAME = MappedBalfour
    TEMP_SOLVER {
        NAME = Plate Balfour Map
        IMAGE_FILENAME = panel.img
        TYPE = Classic
        UV_PROJECTOR {
            FLIPX = FALSE
            FLIPY = FALSE
        }
    }

Relevant Demos

  • The Balfour1 demo includes two slab surfaces using coefficients taken from the creators SPIE paper used to develop and test the DIRSIG implementation of the model.

  • The Balfour2 demo includes a surface that is assigned a spatially-varying Balfour (aka "Mapped Balfour") configuration.

Using the Null Temperature Solver

DIRSIG will not accept a material configuration without a temperature solver for a thermal simulation. However, there are scenarios where the user will not want to configure a specific temperature solver because a given material will always use supplied temperatures. For example, the temperatures might be stored in the input GDB or MuSES geometry file.

This Null temperature solver does not perform any calculations because it is assumed that the temperatures externally supplied.

Strengths

None (this solver performs no calculations).

Limitations

None (this solver performs no calculations).

Relevant Demos

None.

Supplied Temperatures

This section describes a variety of mechanisms that allow the user to supply or import temperatures that were measured or predicted outside of DIRSIG.

Using the Data-Driven Temperature Solver

The first option is a special temperature solver that allows the user to specify either a temporally constant or time varying temperature. Since temperature solvers are assigned to materials, it means that all surfaces assigned this material would get assigned the corresponding temperature. The user can distribute material assignments within their geometry to facilitate the spatial granularity that temperatures are assigned at.

The data-driven temperature solver can be configured via the Material Database Editor or by hand-editing the DIRSIG .mat file. The following example shows how a temperature of 289.3 Kelvin will be assigned to all surfaces mapped to the "Radiator" material:

MATERIAL {
   ID           = 1
   NAME         = Radiator
   ...
   TEMP_SOLVER_NAME = DataDriven
   TEMP_SOLVER {
       TEMPERATURE = 289.3
   }
}

The user can also specify an external file that has temperatures listed as a function of fractional local hours:

MATERIAL {
   ID           = 1
   NAME         = Radiator
   ...
   TEMP_SOLVER_NAME = DataDriven
   TEMP_SOLVER {
       FILENAME = radiator_temps.txt
   }
}

Strengths

The following are considered strengths of this method:

  • This method is great solution for applications where the temperature of a specific component within a complex object is to be assigned, and where that component is already assigned a unique material.

Limitations

The following are considered limitations to this method:

  • The spatial resolution with which temperatures can be mapped is driven by the granularity with which materials are assigned.

Relevant Demos

  • The DataDrivenTempSolver1 demo has an example of two objects driven by the data-driven temperature solver.

Using Built-in Solid Geometry

The built-in solid geometry objects described in the ODB and GLIST files can have the temperatures specified with the geometric description. For example, a sphere in an ODB file can have the temperature defined via the TEMPERATURE variable:

SPHERE {
    MATERIAL_IDS = 4
    CENTER = 0,0,0
    RADIUS = 12.5
    TEMPERATURE = 310.0
}

The same sphere could be defined in a GLIST file using the <temperature> element:

<sphere>
    <matid>4</matid>
    <center><point><x>0</x><y>0</y><z>0</z></point></center>
    <radius>12.5</radius>
    <temperature>310.0</temperature>
</sphere>

Using a GDB file with Temperatures

Unlike the Alias OBJ input geometry file format, the DIRSIG native GDB input geometry file format lets you specify temperatures on a per-facet (polygon). The following section of a GDB file shows how a temperature of 26.89 Celsius can be assigned to a specific facet (polygon):

1-1-1
steel
36
unused
26.89
1.0
0.0
0.0
NULL
NULL
NULL
4
+5.000000e-01 -5.000000e-01 0.000000e+00
...

If you are using an Alias OBJ file for your geometry you can convert it from OBJ to GDB it with the command-line object_tool utility.

Strengths

The following are considered strengths of this method:

  • Unlike some of the other assignment methods described so far, this method lets you manipulate the temperatures on any facet independent of what material is assigned to that facet.

Limitations

The following are considered limitations to this method:

  • Determining which facets (polygons) is very tricky, because there is not (currently) a way to quickly edit or visualize the temperatures.

Using the MuSES Import Mechanism

DIRSIG allows the user to import geometry and temperature predictions produced by the Multi-Service Electro-optic Signature (MuSES) model produced by ThermoAnalytics, Inc. MuSES is an advanced infrared signature prediction code that can model complex targets that include active heat sources, conduction and computational fluid dynamics (CFD). At this time DIRSIG supports a basic MuSES import mechanism, which works as follows:

  • The user creates a working MuSES simulation of the object of interest.

    • The geometry of the object and the output of the MuSES simulation of that object are stored in a MuSES TDF file.

  • The TDF file for the MuSES simulation, containing both the geometry and the predicted temperatures (for one or more simulated times) is "imported" into the DIRSIG simulation.

    • This import process extracts the geometry and a set of temperature predictions from the MuSES TDF file.

  • The TDF import operation is performed during the DIRSIG initialization, and requires the user to:

    • Instruct DIRSIG how to remap MuSES materials to DIRSIG materials

    • Instruct DIRSIG which simulated time to use for the DIRSIG simulation

  • The imported geometry is attributed with the DIRSIG native materials (based on associations with MuSES materials) and temperatures (based on the time provided by the user).

A MuSES predicted object is imported in a similar syntax to that used for the GDB and OBJ file, the TDF file is specified in the <basegeometry> via the <tdf> element. This element requires 3 sub-elements:

  • The filename element specifies the name of the TDF file.

  • The materialidremappings element specifies the list of material ID mappings.

  • The resulttimestepindex element specifies which of the temperature results contained in the TDF file to import.

Below is the key section of the GLIST file used in the Muses1 demo simulation:

    <basegeometry>
      <tdf>
        <filename>vehicle-insight-transient.tdf</filename>
        <materialidremappings>
          <remap>
            <tdfid>1</tdfid>
            <dirsigid>50</dirsigid>
          </remap>
        </materialidremappings>
        <resulttimestepindex>8</resulttimestepindex>
      </tdf>
    </basegeometry>

The list of material ID remappings is composed of series remap elements that contain MuSES and DIRSIG material ID pairs. In the example here, the MuSES material ID 1 in the TDF file will be modeled in DIRSIG with material ID 50.

Note The MuSES and DIRSIG material ID schemes are completely independent, however, if you are creating and managing both simulations then you might consider making the material IDs the same in both tools.

If the TDF file contains multiple materials, then multiple remap elements will need to be defined ( one for each material).

Important Each material utilized in the MuSES TDF file must be remapped to a valid DIRSIG material ID.

Strengths

The following are considered strengths of this method:

  • The MuSES model is extremely robust and capable of modeling complex temperature signatures.

Limitations

The following notes and limitations should be considered. Most of the limitations are because this basic import mechanism assumes the user is aware that the simulation conditions in MuSES and DIRSIG must be consistent:

  • As it was mentioned earlier, the user can remap a MuSES material that had a high thermal emissivity to a DIRSIG material that has a dramatically different emissivity. There is no mechanism for DIRSIG to flag this as a potential error in your setup at this time.

  • This basic import mechanism does not support any automatic time synchronization between the models. If the supplied result time index corresponds to 11 PM at night and DIRSIG is run for 9 AM in the morning, there is no way for DIRSIG to flag this as a potential error in your setup at this time.

  • The orientation of the object can be changed in DIRSIG. Therefore, a vehicle that was simulated with the driver’s side facing east can be inserted into the DIRSIG scene with that side of the vehicle facing west. There is currently no mechanism in DIRSIG to flag this as a potential error in your setup at this time.

Relevant Demos

  • The Muses1 demo includes a MuSES TDF file from which geometry and temperatures are extracted.

Using the Map Temperature Solver

The map-based temperature solver allows the user to drive the temperatures of a surface (or group of surfaces) with a raster image map. One example is the surface temperature on a body of water that was created from either calibrated sensors or predicted by a hydrodynamic model. Another example is the output of a temperature signature model that stores the results from an entire 3D target into a 2D, UV projected image file. To create a temperature map, a 3D modeling person would probably need to help layout the map with you so that the right temperatures go to the right parts of the geometry. And that is because a UV wrapping a map onto a complex 3D object (like your satellite) can result in a very complex map (see the UV mapping discussion for more details).

Strengths

The following are considered strengths of this method:

  • A temperature map can be used to import the temperature signatures from an external model, as long as that model produces a compatible image file (or can be converted to one).

Limitations

The following are considered limitations to this method:

  • A temperature map is fixed and cannot respond to changes in the time of day or shadows cast by a nearby object.

Relevant Demos

  • The TemperatureMap1 demo includes a detailed example of used both static and dynamic temperature maps.


1. L. S. Balfour, A simple thermal model for natural background elements, 9th Meeting on Optical Engineering in Israel, Proc. SPIE 2426, 79-84 (1995)