XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''"> File Types and States
Each file in the hierarchy is uniquely identified by two methods:
1. The combination of hierarchy location and file description.
2. A numerical file-ID.
Usually, the user does not need to be concerned with the file-ID and interacts with all files via the description.
File Descriptions
File descriptions are user-supplied text strings of up to 80 characters. They are presented in the user interface to identify each logical file. Because the user’s view of the file system is based on the hierarchy, these descriptions must be unique in any given branch.
File IDs
The file-ID is valuable to the user when performing system diagnostics. File-IDs help the MSC SuperModel administrator identify and resolve any problems. The file-ID is presented in the banner of the modeling window as part of the working copies name. Files may be accessed through the user interface by their ID. See the Workspace section for information on working copies.
File Types
File types are typically differentiated by providing unique extensions to the name (e.g. *.db, *.db.jou, *.ses). File Manager provides a slightly more flexible mechanism by allowing for the definition of types with full text descriptions. Each file in File Manager is associated with one of these defined types and can be easily filtered based on the type.
The File Manager is installed with four default file types: Submodels, SuperModels, Job Definitions, and General Elements. Additional file types may be added by the system administrator. Each file type is associated with one or more supporting template files, one of which is used as the basis for opening a new file.
Default File Types
The four default file types installed with the File Manager are described in the following table.
Submodel | The file type that you will most frequently encounter is the submodel. This logical file is composed of a MSC Patran database, journal file, and an additional history file. It is used for most general modeling needs. |
SuperModel | SuperModel file type is similar to a submodel with the addition of a Job Definition file and the inclusion of results in the MSC Patran database. This file type cannot be explicitly created by the user, but instead is the result of submitting an analysis using the SuperModel Job Definition functionality. Modifications to a SuperModel are prohibited in order to ensure the model and its results remain consistent. |
Job Definition | A Job Definition contains the information required to assemble, configure and submit a SuperModel analysis. After completion, the Job Definition file is part of the SuperModel and provides a means of reconstructing the analysis. |
General Element | General Element files contain MSC.Nastran specific definitions of either reduced stiffness matrices, reduced mass matrices, or both. |
Nastran XDB | MSC Nastran direct access results file. |
Template Files
Each file type — Submodel, SuperModel, Job Definition, and General Element — is associated with one (or more) supporting template files. The template file serves as the starting point for the user when a new file of a given type is requested. This process is transparent to the user, but is important to understand because it influences the appearance and contents of new files.
When a request for a new file is received by File Manager, a search is initiated for a template that matches the file type desired. This search begins in the current branch of the hierarchy and proceeds up the hierarchy tree until a suitable template is found. If the search fails, a default template is used. This process is transparent to the average user. Important information (e.g., common model data such as geometry and materials) can be part of a template file and ultimately contained in a newly-opened file; this provides an automated mechanism for data sharing. The administrator of the File Manager is able to create a template file for any given type at any location in the hierarchy. In this way, it is within the administrator’s power to provide common data and default settings that can be utilized for all models of a given type in a subsection of the hierarchy tree. For further information about this type of customization please refer to the
File Manager Administrator’s Guide (p. A‑337).
File States
Physical State
The physical state of any file can be thought of as a combination of ON/OFF switches that record how and where a file is currently stored in the repository. Any combination of the states listed below can be applied to a file.
Compression | Compression addresses the “how” aspect of the physical state. Files may be in either an uncompressed or compressed state. Additionally, the state may be by any number of different methods (e.g., compress, gzip, etc). Compressed files can be directly accessed and File Manager can implicitly uncompress them for the user (and recompress them when the user finishes with the file). |
Online | Online describes if the file currently resides in the hierarchy or offline in an alternative storage media. This is useful to save space in limited disk resource situations. The offline storage technique is completely customizable. |
The action associated with each of these states can be completely customized by the administrator through a series of state scripts. Default scripts are provided with the system that implement the standard compression algorithm used by UNIX as well as an FTP mechanism for archival. Please refer to the
File Manager Administrator’s Guide (p. A‑337) for further details regarding the customization of state scripts.
Security States
Several file security states are supported and are mutually exclusive. Unlike physical states these cannot be combined. Every file in the File Manager system is in one of the following security states
Unlocked | An unlocked file is available to all users for WRITE access. |
Locked | A locked file is available to all users for READ access and only available to the owner for READ/WRITE access. |
Released | A released file is available to all users for READ access only. The release mechanism is intended to provide the ability to freeze the engineering data. |
Working | Although not a true security state, the term working is used to describe any files that are not released. This provides a filtering mechanism as a convenient means of identifying all locked and unlocked files. |
The locked/unlocked security states are controlled indirectly by the user through requests to retrieve files with either Read Only or Write privileges. The system validates the availability (i.e., current security state of the file) and proceeds accordingly. The ability to change the security state to released is provided through the user interface. This operation is restricted to File Manager administrators.
Additional security states cannot be added to the File Manager, but the release mechanism does provide for customization. This customization is in the form of a release script that can be modified by the administrator. The intent of this script is to allow for a connection to be established between the File Manager and a Product Data Management (PDM) system. This topic is more fully discussed in the
File Manager Administrator’s Guide (p. A‑337).