Cubit 15.2 User Documentation
Various methods may be used to define a geometric model. In most cases, a solid model is created in a commercial CAD tool such as Pro/Engineer or Solidworks. It can also be generated natively within Cubit using geometry commands. One of the most time consuming tasks in developing an analysis model is in dealing with geometric anomalies. Carefully considering how the model is constructed and what format the model will be defined in can eliminate many potential problems downstream in the model creation workflow. The following describes the various solutions for defining geometry within Cubit along with their pros and cons:
Cubit can use one of three different commercial geometry representations, ACIS (.sat, .sab), Pro/E (.g) or Catia (.cat). It may also use a facetted format (MBG) that is developed in-house at Sandia. When a model of any of these formats is imported, Cubit uses the appropriate third party geometry kernel to directly manage and evaluate the geometry. Since the geometry is considered “native” when any of these formats is used, no translation step is required.
Since commercial solid modelers do not necessarily agree on formats and representations, using a translation process to convert a non-native format to a native format, can introduce errors in the geometry. While this in itself may not be a show-stopper, it can frequently add hours to an otherwise simple process while the user is forced to clean up dirty geometry. Neutral formats such as STEP and IGES are common in the CAE industry. They can often be an ideal solution for representing the analysis solid model. In Cubit, when importing a neutral format, it is automatically translated to the ACIS format. The user should be careful however in selecting these formats as commercial solid modeling engines frequently interpret standard specifications for these formats in different ways sometimes resulting in unusual results. Wherever possible a native format should be used.
Native geometry kernels provide the most accurate way for transferring data between solid-model based applications. Since these geometry kernels must be licensed and incorporated into the Cubit distribution separately, one drawback is the additional licensing and cost for maintaining these kernels. Cubit is currently able to provide licenses for ACIS and Pro/E kernels for government and academic use. Additional licensing arrangements may be required for Catia or for any commercial use.
Cubit offers a wide variety of tools for creating geometry natively. The advantage to this is the ability to control the geometry creation process without the need for another CAD tool. Although Cubit is not designed to be a CAD tool it does provide many tools for both bottom-up and primitive creation.
Bottom-up creation refers to the process of building geometry from its basic components starting with vertices, curves, surfaces and then volumes. This process can be somewhat tedious, but is often useful for generating auxiliary geometry once a CAD model has been imported.
Primitive creation refers to the various operations for generating geometric primitives such as bricks, spheres, cylinders and cones. Once defined, operations for repositioning the objects and performing Boolean operations between them may be used. Relatively complex models may be generated using this approach.
One advantage to generating your own geometry within Cubit is the ability to parameterize the construction of the model. Cubit utilizes a rich command language that can be stored as a script or journal file. Parameters representing dimensions of objects may be defined in the script and conveniently adjusted to update the geometry representation. For more ambitious users, Cubit also has the ability to interpret python scripts, allowing a high degree of customization that can employ the full capability of the python scripting language.
It should be noted that when using Cubit, commands are automatically echoed to an external temporary journal file on disk and to the history window. Observing these commands is a good way to become familiar with Cubit’s internal command language. Copying and pasting selected commands to a text editor is an ideal method for building a parameterized journal file. Journal files may be built up and played back to reproduce the entire process of building an analysis model.
A CUB file is Cubit’s database file. You may want to think of it as a snap-shot of the current state of the model. While journal files record the process for creating the model, a CUB file stores only the end state. It can include both geometry in its native format and any mesh information as well as attributes and boundary condition information. Restoring a CUB file will write over any existing data you currently have defined.