Older CFD simulation programs fragment their user environment into three separate programs: model generation, model simulation, and model visualization. These subprograms then share data through a common file space or through information pipes. This program flow provides the most benefit to users who have fleshed out their numerical design in advance, and penalizes users who switch back and forth between subprograms. However, most architects and HVAC engineers desire interactivity, unity and fluidity between the model generation, CFD computation, and results visualization stages. In particular, the following five stages of CFD simulation design as shown in Figure 4 are commonly executed. In the initial generation phase, the user gives a shell description of the problem to be simulated. This typically includes specifying a small subset of the physical and computational parameter sets, including adding the room’s objects and indicating the level of computational accuracy desired. The computation phase is handled by the CFD engine chosen by the user. The results are then forwarded to the visualization phase, where the user analyzes the
esults. At this point, the user may choose to enter the model modification phase and solve again, or save the
results for the presentation phase. Examples of slight model modifications include minor alterations to the
oom geometry, changing airflow rate or direction, increasing the density of the mesh topology (to
investigate a particular flow detail), or altering other parameters to achieve finer results. This investigation
endeavored to create an interface that allowed rapid and seamless transition between the five stages of
CFD simulation design.
SCI combines all three applications into a single workspace, eliminating any wasted time or effort
incurred by application switching. To achieve this result, a window with a large, central, blank area is
created for 3-D visualizations and presentation animations. There are two dialog boxes in the
interface. The first dialog box controls the visualizations viewed in the main window, and the
second dialog box commands the model layout tools. A generic menu bar controls all other
parameterizations with four separate tools: a mesh topology tool, a problem description tool, an iteration
ontrol tool, and a simulation properties tool. Activating any of the tools launches dialog boxes that
assist the user through the process. To avoid workspace clutter, these boxes disappear as soon as
they are no longer needed. Moving to the computation stage requires the pressing of a button marked “GO”
on the toolbar. Thus, all five stages are represented on the main window, less than a single mouse-click
away. Automating Model Format Translation for Rapid Model Development and Multiple Simulation
Many professional CFD packages require their users to specify the layout of the room using a foreign or
unfamiliar methodology. Sometimes the topology of the mesh is used as a physical reference to locate
physical items, such as walls, tables, and chairs (this is k nown as a logical coordinate system as indicated
in Figure 5(a)). At other times, the user is prompted for the precise distance of objects from a common
reference point (known as a physical coordinate system as illustrated in Figure 5(b)). If a user switches
from a CFD solver that uses the former system to one that uses the latter, then the user must recast the
model’s object into the new format. In many cases, whenever the user switches CFD simulation software,
he or she must reconstruct the entire building design using the methodology of the new CFD software.
This process of reconstruction impedes the success of many CFD user interfaces. Two immediate solutions
to this problem involve automating the process of transforming the model from one CFD software data
format to another. This first solution is to adapt a building environment file format standard. An
international consortium of programmers known as the International Alliance for Interoperability has
established a standard building file format known as IFC, or Industrial Foundation Class, to realize this
solution. Building environment simulators, such as CFD simulators, are to include the ability to
automatically translate IFC files into their own desired format, thus eliminating the necessity of
involving the user beyond the initial generation. The other solution is to only ever use one single interface,
and hope the interface can internally handle translations needed to run the different CFD solvers.
This solution is similar in essence to how AutoCAD lug-ins behave – AutoCAD is the single interface
where a model is created, and the plug-ins give and receive model data to the interface. The first solution
is a smart-application solution and the second is a smart-interface solution, since the first requires
additional intelligence built into the simulation software and the second requires additional
intelligence built into an umbrella interface
A translator for reading IFC-formatted files and converting them to our own, internal SCI format is
included to implement the smart-application solution. In addition, an IFC exporting utility is included,
should the user want any geometry changes made in SCI to be recognized by other IFC-compliant building
simulation tools. In addition to IFC compliance, we also included a STL (Stereolithography) geometry file
[1] translation tool, to read model geometry directly from AutoCAD.
The implementation of the smart-interface solution allows SCI to work with more than just one
underlying CFD numerical simulator. Once the model is translated into the SCI format, we can send it to as
many CFD simulators as we have written translator modules. Currently, we have two translator modules.
The modules are an interface for a CFD code to provide SCI data in a specific format. The modules
can be written in any program language.
SCI combines all three applications into a single workspace, eliminating any wasted time or effort
incurred by application switching. To achieve this result, a window with a large, central, blank area is
created for 3-D visualizations and presentation animations. There are two dialog boxes in the
interface. The first dialog box controls the visualizations viewed in the main window, and the
second dialog box commands the model layout tools. A generic menu bar controls all other
parameterizations with four separate tools: a mesh topology tool, a problem description tool, an iteration
ontrol tool, and a simulation properties tool. Activating any of the tools launches dialog boxes that
assist the user through the process. To avoid workspace clutter, these boxes disappear as soon as
they are no longer needed. Moving to the computation stage requires the pressing of a button marked “GO”
on the toolbar. Thus, all five stages are represented on the main window, less than a single mouse-click
away. Automating Model Format Translation for Rapid Model Development and Multiple Simulation
Many professional CFD packages require their users to specify the layout of the room using a foreign or
unfamiliar methodology. Sometimes the topology of the mesh is used as a physical reference to locate
physical items, such as walls, tables, and chairs (this is k nown as a logical coordinate system as indicated
in Figure 5(a)). At other times, the user is prompted for the precise distance of objects from a common
reference point (known as a physical coordinate system as illustrated in Figure 5(b)). If a user switches
from a CFD solver that uses the former system to one that uses the latter, then the user must recast the
model’s object into the new format. In many cases, whenever the user switches CFD simulation software,
he or she must reconstruct the entire building design using the methodology of the new CFD software.
This process of reconstruction impedes the success of many CFD user interfaces. Two immediate solutions
to this problem involve automating the process of transforming the model from one CFD software data
format to another. This first solution is to adapt a building environment file format standard. An
international consortium of programmers known as the International Alliance for Interoperability has
established a standard building file format known as IFC, or Industrial Foundation Class, to realize this
solution. Building environment simulators, such as CFD simulators, are to include the ability to
automatically translate IFC files into their own desired format, thus eliminating the necessity of
involving the user beyond the initial generation. The other solution is to only ever use one single interface,
and hope the interface can internally handle translations needed to run the different CFD solvers.
This solution is similar in essence to how AutoCAD lug-ins behave – AutoCAD is the single interface
where a model is created, and the plug-ins give and receive model data to the interface. The first solution
is a smart-application solution and the second is a smart-interface solution, since the first requires
additional intelligence built into the simulation software and the second requires additional
intelligence built into an umbrella interface
A translator for reading IFC-formatted files and converting them to our own, internal SCI format is
included to implement the smart-application solution. In addition, an IFC exporting utility is included,
should the user want any geometry changes made in SCI to be recognized by other IFC-compliant building
simulation tools. In addition to IFC compliance, we also included a STL (Stereolithography) geometry file
[1] translation tool, to read model geometry directly from AutoCAD.
The implementation of the smart-interface solution allows SCI to work with more than just one
underlying CFD numerical simulator. Once the model is translated into the SCI format, we can send it to as
many CFD simulators as we have written translator modules. Currently, we have two translator modules.
The modules are an interface for a CFD code to provide SCI data in a specific format. The modules
can be written in any program language.
