Search NASA⌕ Search
Home/Archive/NASA NTRS

NASA NTRS · 20205003603

Extending the Capabilities of Thermal Desktop with the OpenTD Application Programming Interface

Hume L Peabody
View original source ↗Export metadata ↓

Abstract

With the release of Thermal Desktop 6.0, users now had the ability to interface with some of the many elements and constructs of a Thermal Desktop model through external applications developed using the TD API (Application Programming Interface). This file allows applications to be developed in the .NET framework and interface to a number of object types within a Thermal Desktop model. The release of 6.1 expands the subset of objects able to be manipulated and now includes the raw geometrical information of surfaces. With the release of 6.1, the API was now referred to as OpenTD. This paper discusses some of the utilities and capabilities developed using the OpenTD API at the NASA Goddard Space Flight Center. These include utilities to help with configuration control of models and case sets, addition of logic to better process heater performance, and a methodology implemented to allow for submodel level processing of radiation couplings to include smaller radks where needed in a cryogenic region without using the same criteria for the warmer portions of the model. This last utility is targeting a reduction in run time without sacrificing accuracy. Lastly, some lessons learned, work-arounds, and wishes for the next release of the OpenTD API are also presented.

Explore related subjects

Thermal Desktop

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Hume L Peabody. Extending the Capabilities of Thermal Desktop with the OpenTD Application Programming Interface. https://ntrs.nasa.gov/citations/20205003603

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related reports

NASA NTRS2019

SINDA/FLUINT and Thermal Desktop Multi-Node Settled and Unsettled Propellant Tank Modeling of Zero Boil Off Test

Cryogenic propellant storage tank self-pressurization involves complex physical phenomena which are usually analytically modelled via complex multidimensional CFD (Computational Fluid Dynamics) codes. Unfortunately these codes, even when modelling axisymmetric domains, may take weeks or longer to obtain transient pressure and temperature information for relatively short periods of time (several seconds to several hours). Propellant tank storage end-to-end mission simulations can last a duration of days to weeks to months. Multi-node modelling of propellant tanks is a viable alternative to traditional CFD modelling and presents the advantage of greatly reduced run times on the order of hours and days compared to the weeks or longer for CFD codes. A multi-node model represents the fluid within the storage tank, as well as the storage tank itself, as a fluid-thermal network. This type of setup is not necessarily geometrically based. This can be accomplished using a commercial generalized fluid-thermal network code, such as SINDA/FLUINT (SF). The advantage of using a fluid-thermal network code like SF lies in its extensive ability to model the external environment of the storage tank through the graphical user interface, Thermal Desktop (TD). The total heat load into the tank may be a function of heaters and a complex radiative environment as well. Thermal Desktop may be used to address the detailed radiative environment of the tank as well as building a geometrically accurate depiction of the storage tank itself.

Thermal Desktop↗
NASA NTRSDate not supplied

Tracking Critical Thermal Metrics throughout the Life Cycle of a Large Observatory Thermal Model

Observatory thermal models for large, complex missions, such as the Wide Field InfraRed Survey Telescope (WFIRST) mission, produce an immense amount of data to be processed. Configuration management of the model throughout the project life cycle has mainly focused on which versions of the subsystem models form the current observatory level configuration. However, the results produced by the model are not nearly as well tracked and traceable. Given the various states of design maturity for each of the components in the WFIRST design, an updated component model is nearly ready to be integrated at the next higher level of assembly about every month or two. With each subsystem model delivery, the observatory model needs to remove the old component, integrate the new one, execute the model, and inspect the results. Usually, this inspection focuses primarily on the newly integrated component. Recently, a Metric Tracking Spreadsheet was developed to help provide a “big picture” view of the entire observatory highlighting key parameters critical to mission performance. This spreadsheet helps track impacts on subsystems by updates of other subsystems that were not intuitively obvious. Metrics tracked include: absorbed environmental loading (to determine effectiveness of sunshield), temperatures of critical avionics, electrical dissipations, heater power predictions, stability of critical optics, parasitic heat leaks in cryogenic region, high level heat flows between elements, and model run time. Producing this data for the same operational configuration with each model update has helped produce a trail of data to evaluate the impact of model updates. While the metrics selected are specific for WFIRST, other large, complex observatories could be well served to establish their own metrics early in the project life cycle to track to quickly assess the impact of any subsystem on other subsystems or the overall system itself.

Thermal Desktop↗