XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''"> Overview
MSC.SuperModel File Manager is a software system composed of multiple components that work together to provide a user-friendly layer on top of the UNIX file system. A thorough understanding of all of its components assists you to install and maintain MSC.SuperModel. This overview includes an introduction to the philosophy behind File Manager as well as the architecture of the software system.
Philosophy
The interface and operation of File Manager may be very familiar to you because it is similar to most other file systems, some underlying principles make it unique and you need to read about these differences. Specifically, File Manager introduces the concept of Logical Files.
A logical file is a collection of related files that share a common cause. The best example of this is familiar to MSC.Patran users.
The MSC.Patran database is generally accompanied by a journal file. This file provides a record of the commands issued in MSC.Patran that could assist in the reconstruction of the database. The MSC.Patran application expects these files to always be found together and issues a warning message to the user when this expectation is not met.
File Manager deals with this situation by treating the two files as one. It does this in a very simple way: it collectively operates on all files of the same base name (i.e., a file name minus any extension). This is important from an administrative standpoint because you may be required to provide files to the system under certain circumstances, such as defining a new file type.
File Manager anticipates that all files at a given location with the same base file name are to be treated as one. This assumption is always followed, in the repository, in local and remote workspaces, and even when dealing with other UNIX directories.
When a distinction must be made, the individual files that make up this type of collection are referred to throughout this document as physical files. In general, however, when a file or files are referenced they are understood to be addressing a logical file.
Although file extensions are ignored by File Manager, there are several which are reserved in order to support the standard operations of the software. These are outlined in
Table A‑1.
Caution: | You should avoid introducing files into the system with the extensions listed in Table A‑1 that do not adhere to the intended use! Doing so can result in the disruption of File Manager services such as maintaining file histories. |
The following table lists the Reserved File Extensions used by the File Manager:
Table A‑1
Reserved File Extension | Description |
• .hst | History File. Every logical file introduced into the File Manager system has a history file generated. This is an automatic procedure and this file’s existence is imperative to the basic functionality of File Manager. |
• .db | MSC.Patran database file. This is the conventional file used to hold FEM data for use in the MSC.Patran application. Both submodel and supermodel file types contains a file with this extension. |
• .db.jou | MSC.Patran database journal file. This file is the counterpart to the database and is generally expected to exist although this is not a firm requirement by MSC.Patran or File Manager. |
• .db_m | MSC.Patran database marker file. This file is only used when the repository, or a portion of it, is housed on an NFS mounted directory with respect to the client installations. |
In addition to
Table A‑1, the MSC SuperModel module of MSC.Patran has identified additional extensions which should be considered reserved if you are using File Manager in conjunction with MSC SuperModel as follows:
SuperModel Related Reserved File Extension | Description |
• .gnl | Reduced Stiffness Matrix (RSM) or Reduced Mass Matrix (RMM) file. These files are used to contain the MSC.Nastran required input data for generating ASET and DMIG entries used in an analysis. |
• .gnl.def | RSM definition file. Contains information required to reconstruct the RSM or RMM file. |
• .jdf | Job Definition file. Instruction sets for creating a supermodel are stored in this file. Although File Manager does not enforce the existence of this file for every supermodel, the functionality in MSC SuperModel does expect it in this file. |
• .xdb | MSC Nastran direct access results file. |
Finally, several extensions are reserved for future use by the File Manager in anticipation of added capabilities or in an effort to avoid the introduction of vague extensions which could cause problems with customization activities as follows:
Reserved File Extension (For Future Use) | Description |
• .txt | General text data. |
• .bin | General binary data. |
File extensions not listed above are available for customization at your local site. As the administrator of the system, it is important to work with any groups that wish to introduce additional file types and extensions into the system in order to avoid conflicts.
Architecture
This section provides the working details of the system. The system architecture is divided into four principle components:
1. Client & server software.
2. Database maintaining information about all files in the system.
3. Repository (i.e., directory structure) for housing the user files.
4. Local & remote workspaces that provide disk resources for working with files accessed from
the system.
These are collectively depicted in body A‑1 in a graphic representation of a system. This is comprised of a server, two clients, workspaces, repository, and a dumb terminal that hosts an additional user from one of the clients.
Figure A‑1
Client / Server
File Manager utilizes a client/server architecture in order to provide a central controlling agent for the files being generated and accessed by your user community. A single machine (the server) is responsible for maintaining information about the files location (as well as other pieces of data) and for providing that information to each machine (client) which requests access.
Note: | This architecture does not preclude a user from accessing files while on the server machine. In this instance the server machine is actually also a client and behaves in exactly the same fashion as any other (it actually calls itself and answers back). |
The clients and server communicate via a mechanism called Remote Procedure Calls (RPC). Essentially, an application on a client machine calls the server machine and requests access to another resident application. The server checks to see if the requested application is running, if not, it starts it and establishes a connection between the two. This connection provides the means for the two applications to exchange information. In the case of File Manager, the two applications are:
• An MSC.Patran customization (FM Module) that provides the client side.
• An executable named smdl_fm_server that provides the server side.
For future discussions, we refer to these as the client and server, with the understanding that we are really talking about the applications involved.
Multiple clients are supported by the server on a first-come, first-served basis. Therefore, it is possible for a large volume of server requests to generate a queue of pending requests and result in a performance degradation. In general, every effort has been made to reduce the number of requests that each client makes to the server.
Because the File Manager relies on network connections and must share the limited network resources with other applications (e.g., ftp, rcp, and telnet), its performance is in direct relation to the performance of the network.
Server
As previously mentioned, the server is an executable which can be started automatically by the hosting machine. Its sole responsibility is to process requests from the clients with regard to the logical files contained in the repository. It does this by accessing and modifying the database.
A few of the requests that the server responds to are given. This is not a comprehensive list, but does help to convey the responsibility of the server.
• Lists all the files at a particular location in the hierarchy.
• Gives a file description and returns the base filename and UNIX path.
• Determines the physical/security state of a given file.
• Registers a file as Locked by a given user.
Caution: | It is important to understand that the server does not manipulate the physical files in any way. It provides information about the file to the client and registers changes to that data on behalf of the client. |
• Client
Unlike the server (which answers questions), the client takes a very active role in fulfilling the desires of the user.
The most apparent assistance that is provided is the user interface which takes information that is meaningful to the user and processes it into the correct server requests to fulfill a useful task (e.g., opening a file for modification).
Not as apparent, but equally important are the operations that the client performs behind the scenes. These include:
• Copying the physical files between the repository and workspaces.
• Ensuring that the physical files are in a workable state (e.g., uncompressed).
• Providing for the customization of many of File Manager’s features by spawning scripts.
Note: | This workload may seem excessive, but remember that the server may be busy handling information requests from every client. |
Database
In order to maintain information about all of the files generated by users, File Manager utilizes a database especially designed for this job. While very different in architecture, it is based on the same technology as the MSC.Patran database and therefore requires no additional licensing.
Note: | A possible point of confusion arises when discussing databases. It is important to note that the database associated with File Manager is not an MSC Patran database. Instead, it actually contains information about where to find MSC Patran databases. |
The following table provides an overview of the information contained in the File Manager database. This is presented only to help you understand the overall system. You are not required to interface directly with the database at any time during your position as administrator
Files | Information is maintained about a file’s: • Name (80 character description) • Location (full pathname to directory) • Type (see file types below) • Physical state (provides resource management) • Security (provides access restrictions) |
Hierarchy | Information about the hierarchy is maintained: • Level labels (customizable at installation) • Branch labels (customizable at any time) |
File Types | Information that provides for categorizing all of the files in the system is maintained and may be customized at any time. |
Associations | A list of file associations is maintained. This provides cross-referencing files that are related. Additional associations may be added at any time. |
Users | For every user who accesses the system, a record of where they were last is maintained. This provides a means of returning them to the same location the next time they need to work in File Manager. |
Repository
The file repository is a collection of UNIX directories where the user files are stored. A directory exists for every branch of the hierarchy that you create following the installation of the File Manager software. However, the correlation between the directory name and the branch label is not discernible. Instead, the database maintains this relationship in order to eliminate some potential problems associated with path name lengths under UNIX.
The directories for the repository are hidden from the casual user of the system in order to provide a degree of security. This is accomplished via the hidden file naming convention allowed under UNIX. Every repository directory is named following the convention .nX where X is an integer value assigned at the time the directory is created. This convention alleviates the path length problem and serves to hide the directory structure (through the ambiguity of the name and the use of the “.” prefix) to make it invisible to conventional listings.
As administrator, you are required to specify a location (directory path) which serves as the base of the repository structure. From this point, the server manages the directory structure for you. During certain situations it may be necessary for you to intervene in this process. If the physical disk that hosts the repository becomes exhausted, it is necessary to expand the directory structure to provide additional space. This process is outlined under General Customization (p. A‑359).
Workspaces (Local & Remote)
In order to provide concurrent access to the files in the repository, File Manager establishes workspaces (with your help) for every client machine. A workspace is a reserved directory location that can be used to hold working copies of a file being accessed from the repository.
After the client has established the location of a file (through a request to the server), the file is copied to the local workspace. This copy is named so that its origin and owner can be distinguished in the event that the software is interrupted. This naming convention is evident in the banner of the modeling window for the cases when an MSC.Patran database is copied and is also presented:
<user name>-<file id>.<file extension>
where,
<user name> | System name of the user who has requested the file. |
<file id> | Unique integer identifier that the server uses to refer to this file. |
<file extension> | Any of a number of extensions used to denote the intended use of the physical file (see the previous discussion on the philosophy of the File Manager). |
