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.

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 simple emperical 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/cm2, Ei is the diffuse sky irradiance in Watts/cm2, 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:

  • At this time the coefficients are 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).

  • 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.

Relevant Demos

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

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 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)