Temperature Solvers

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

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 T_s is the surface temperature in Celsius, E_s is the direct solar irradiance in Watts/m², E_i is the diffuse sky irradiance in Watts/m², T_a is the air temperature in Kelvin, W is the wind speed in meters/second and a₀ through a₄ 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.

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.

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:

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

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:

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

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

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.

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:

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:

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

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.

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

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