In addition to loading the analysis code specific definitions for a MSC supplied interface as described in the previous section, the user can add analysis code specific definitions for his own analysis code. The rest of this chapter is dedicated to describing all the PCL callable functions needed to add definitions for a user defined interface.

There are three basic ways to manage the PCL functions which add the definitions for your new analysis code. The user can create a PCL function, “load_<analysis_code>”, which would in turn make all the appropriate PCL function calls to define the new analysis code. This function would be very similar to the PCL functions delivered by MSC (e.g., “load_marck5”, “load_ansys,” etc.) In fact, the user could compile this function into p3patran.plb, giving universal access to the function. Alternatively, the user can create a session file which contains the appropriate calls to define the new analysis code. The example at the end of the chapter uses this method. Lastly, the needed commands could be directly input to the Patran command line, though this method would, in most cases, be undesirable.

It is important to understand that “base.db” contains certain code specific definitions, namely the three analysis types listed in the description of db_create_analysis_type, 454, all the load type definitions listed in the description of db_create_lbc_type_defn, 555 and the associativity between these load type definitions and all the MSC supplied analysis interfaces. In other words, all Patran databases will contain these definitions and they need never be repeated.

There are other definitions which are relatively basic and can be added to “base.db” with one simple PCL function call, “load_generics()” is completely options and is intended solely as a short cut. The user can call “load_generics()” and then reference any of the definitions loaded by this function without going through the labor defining all of them himself. All the MSC supplied interface loading functions, (e.g., “load_mscnastran()”) described in the previous section use “load_generics().” So, a database which contains definitions for any MSC supported interface will also contain all the definitions loaded by “load_generics().” If the definitions added by “load_generics()” already exist, they need not be repeated, but repeating them will also not cause any problems.

Due to the size of “template.db,” it is strongly recommended that the user develop his new template database from “base.db” instead of “templated.db.” But, if he wishes to use “template.db” he should note that all definitions detailed in the rest of this chapter exist in “template.db.” In this case, none of the documented definitions need be repeated and the repetition of certain definitions will create errors. In other words, it is impossible to modify the definitions for an analysis code once defined. In fact, even when redefinition does not create an error, the command will not be obeyed, but instead simply ignored.

Lastly, the way that the analysis interfaces recognize data is through the definitions described in this chapter. If two interfaces recognize the same set of definitions, then a model will easily transfer from one analysis code to the other. If there are differences in the sets of definitions recognized by the two analysis codes, then data is likely to be lost when transferring a model from analysis code to analysis code. So, in order to maintain consistency with the MSC supplied interfaces, it behooves the user to use the definitions documented in this chapter (which are the definitions used by the MSC supplied interfaces) as much as possible, instead of making unique definitions of his own. Most of these definitions are identified by an integer ID. When users or third-parties add new definitions, the IDs for these should be in the range 20000 to 29999 to avoid conflict with MSC-defined ID’s.