Patran Thermal problems that define view factor calculations can be translated for input to and from the TRASYS code. The correspondence between the Viewfactor code subelemental areas and the TRASYS surface is shown in Figure C-8. A restricted subset of both Patran Thermal and TRASYS capabilities are supported at the moment. The linkages between the codes are not automatic and require intervention by the users in executing the calculations in either direction. The translation requires the vfin.dat file created during Patran Thermal submit. The basic procedure is outlined in the following sections.

Some of the steps below assume that Patran version 1.4-2 or later is available. For example if the template.dat.apnd file is defined before the job is spawned from Patran the template file will be pulled into the directory where the job is expected to execute. There is more than one way that a user can go about building the TRASYS results and the following just outlines one method.

First the template file has a new entry that defines the TRASYS surface properties. This entry is defined below:

In the above example the different item in the VFAC template which is used by Patran Thermal are:

The VTRA defines the surface properties required by TRASYS. The input definitions are:

The forward translation is done by executing PATQ. It assumes that you have already translated the neutral file to generate the required QTRAN input files in a previous step - menu pick 2. This is followed by a menu pick 6 which brings up the additional utilities menu and select menu pick 16 which will read the vfin.dat file and reformat the radiating surfaces into polygons in the TRASYS format. The output file for input to TRASYS is given the name trasys.inp. Each enclosure is defined as a BCS group with a 6 character name reflecting the enclosure number. Each radiating surface is given a TRASYS node ID which is 10 times the Patran THERMAL surface ID. The parent Patran element ID and node ID’s are identified in comment portions of the TRASYS surface declarations.

Some restrictions on how the TRASYS run should be made are: One, the units for TRASYS are BTU, feet and hours. The thermal model, when it is generated in Patran, should be in these units. If the model has different geometric units, the conversion should be exercised at the initial translation so that all conduction, convection and radiation boundary conditions are in a consistent set of units. Two, since the radiation resistor/conductors defined for Patran Thermal do not include the Stefan Boltzmann constant, SIGMA should be set to 1.0 for the TRASYS run. If it is desired to make a run with SINDA, then the SIGMA can be defined in the SINDA input. The desired output for the resistor network should be directed to tape and punched output should be requested for the desired solar heat fluxes.

After a successful TRASYS run has been made, a bcd file should be present. This file contains the requested output quantities the end of which is denoted by the character string c$end. If the radiation interchange has not been output to the bcd file, the user needs to add a c$end record at the beginning of the file. The reverse translator is initiated by going into the utilities menu and executing option 17. Normal Patran execution with generate a qin.dat file which has a number of insert file references that are specific to performing thermal analysis using data created from the reverse translation of the TRASYS data. The added file references are summarized on the following page. They are proceeded by a comment type keyword - **TRASYS_XX where the XX refers to one of three types of analysis that can be performed. DY is dynamic analysis with articulating bodies which create time dependent viewfactors, TR is transient analysis without dynamic viewfactors and SS indicates a steady state run based on average properties. When doing the reverse translation the user has a number of options first of which is to create run type qin.dat files. This will uncomment the appropriate files creating specific qin.dat files with suffixes corresponding to the type of analysis desired. To utilize this feature the user should define all input on the analysis form as if a transient run is to be performed. Also, the files are set up assuming a steady state run will be performed providing initial conditions for the transient analysis.

The user will continue to be queried for different options related to the type to reverse translation data is desired and conversion units relative to the TRASYS analysis. TRASYS analysis determine heating loads and viewfactors based on element entities. Since MSC THERMAL performs its analysis based on the finite element approach and uses the nodal subareas, the heat fluxes and viewfactors from TRASYS are distributed to each node of a given element based on the finite element shape functions associated with the element in question. After all the fluxes and viewfactors have been distributed to each node they are combined. As a result even though a finer distribution has been used to define the conditions at each node, the heating and resistor network associated with the finite element network is of the same order one would get from an elemental analysis. All the files created for input to MSC THERMAL at the user’s option can be translated to SINDA format as well.

The user can define the output names. The default names are consistent with those included in the qin.dat file and the information contained in each file is:

Currently all these files are ascii.

The Patran THERMAL TRASYS reverse translator treats the TRASYS ambient (space) node radk's differently than other surface to surface radk's. In the forward translation to TRASYS from Patran THERMAL, each element surface from P3THERMAL is multiplied by 10 as it is written to the TRASYS input deck. If the enclosure references an ambient node then that node ID is added in a comment card at the end of the TRASYS input deck. When creating the operations block in TRASYS, there are three options with regard to numbering the SPACE node.

The preferred option is to use "0" as the default SPACE node number. This will force TRASYS to use 32767 as the space node number. On reverse translation from TRASYS to Patran THERMAL, there is logic in the translator to detect incoming 32767 references and to convert those references to the original Patran THERMAL ambient node number which was included in the comment card. The second option is to hard code "32767" as the TRASYS SPACE node number. The result is the same as option 1. The third option for numbering the SPACE node is to number it the same as the ambient node ID in Patran THERMAL multiplied by 10. This will circumvent the 32767 logic and allow the reverse translator to strip the trailing "0" without changing the original Patran THERMAL space node number.