{{>toc}}

TS21 uses TD to generate part of their PTCS thermal aspect GUNNS networks. They have a separate GUNNS thermal network for each of the main ISS modules (US Lab, Node 1, Node 2, Airlock, etc). These networks model the temperatures of all the of the structural components of the module (shell, hatches, truss beams, bulkheads, etc), as well as the temperatures of the various ORU’s inside the module (pumps/fans, power supplies, MDM’s etc). The structural pieces came from TD. The ORU’s were added separately, not using TD (more on that below).

TD creates a 3-dimensional CAD model representing the structure of the vehicle in 3-D space. It can represent the 3-D structure as a mesh of nodes and links. Each node has the average temperature of the mass that it represents, and the links describe the thermal interaction between the nodes — just like GUNNS. TS21 developed a set of scripts that can extract that node-link info out of the TD model into XML files that GUNNS can consume.

Back when we developed all this, we thought we were getting complete TD models of the ISS from the users — so reusing their models was going to save us a lot of time. However those models never materialized, but by that point we’d developed this capability and we were committed to it. Our TCS guy had to create all of TS21’s TD models of the ISS himself, using graphics models & diagrams as a guide. If we’d known that was going to happen, we wouldn’t have developed the TD interface.

The disadvantage of making the TD models ourselves was that we had to guess about a lot of the structural dimensions and materials. These weren’t official TD models and thus their thermal interactions (the links) couldn’t be trusted to predict real-world behavior. As a result we spent a lot of time manually tuning the links to get our networks to trend properly and follow flight data, etc.

The advantage of making the TD models ourselves was that we got to pick exactly how much fidelity we wanted. That is, how fine its node mesh is and therefore how many nodes are in the networks (remember the # of nodes is a big deal). Training sims do not need as much fidelity and accuracy as engineering analysis, and therefore a TD model developed for engineering analysis probably has a much finer mesh of nodes that what you need for training. We tried to limit the number of structural nodes to 100 or so for each network. A detailed TD model might contain thousands of nodes — in which case you’d have to “dumb down” that model to a coarser mesh of nodes. That takes some effort in TD.

TS21 doesn’t include the ORU’s in its TD models. Instead, they’re added to the network XML files through a separate process called the Thermal Aspect Registry. The registry is basically more XML files (in the same schema as the TD files) hand-written by the ORU modelers to add their ORU thermal aspects to the overall network. The nodes & links from the TD model get added with the ORU nodes/links to form final .xml files representing the ISS module and everything in it. The whole process looks like this:

So we generate some XML files from the TD model. This is fundamentally different than how GunnsDraw/GunnShow works. In GunnsDraw/GunnShow, each diagram generates a unique C++ class that represents one physical system. With TD, all the information describing the unique physical system is in the XML files, and the C++ network that uses it is generic. This generic class is at gunns/aspects/thermal/network/ThermalNetwork.hh. It has all the same stuff as GunnsDraw/GunnShow-generated networks: an array of nodes, a bunch of links, a solver, the same interface with the caller, etc. You instantiate this class for each separate network you want, and each instance loads its associated XML files during sim init.

An advantage with this is that once you build each instance into your sim, you don’t have to rebuild the sim when you change the XML files (say regenerate from TD), because they’re loaded in at runtime.

A disadvantage is that it’s a little trickier to reference the nodes & links in these ThermalNetwork networks. Whereas a GunnsDraw/GunnShow network instantiates each link with a unique name, all the links in a ThermalNetwork are in one of 7 arrays (one for each type of thermal link), and you have to go back to a reference or the XML files to know which offset in the link array contains the exact instance you are looking for. This is a hassle when trying to debug in runtime.

“Thermal Desktop” is technically just the 3D GUI and doesn’t have much analysis built-in. TD usually comes with another tool called SINDA/FLUINT, which has the analysis abilities for thermal & fluid aspects.

• TD/SINDA/FLUINT has almost nothing for the electrical aspect.
• SINDA/FLUINT’s thermal and fluid calculations are higher-fidelity than GUNNS, but GUNNS is more appropriately scoped for space vehicle real-time training sims. For instance, there’s no question that FLUINT’s model of fluid flows through ECLSS plumbing is more realistic and requires less tuning than GUNNS, but they might run slower and might lack certain specific ECLSS models like sublimators, CO2 scrubbers, crew metabolics, etc.
• TD’s website talks about multidisciplinary integration, which implies that maybe TD models could be embedded directly in a sim in lieu of GUNNS. This is probably quite tricky though, and we’ve never heard of anyone doing that in Trick.

• The scripts described above aren’t maintained by ER or delivered with GUNNS. Instead, they are currently scattered around in TS21. We have a goal of absorbing these back into ER’s releases of GUNNS but it has been a low priority.
• We’ve had brain-drain on TD. All of the above-mentioned development was done by another engineer who’s since moved on to other projects.