General Customization

SuperModel > File Manager Administrator’s Guide > General Customization

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''">

File Manager provides for a great deal of customizing both during and after the installation process. This distinction is an important one and serves as the primary organization for this section.

Some features of File Manager can be customized either before or after installation, and the procedures may be slightly different. These features are identified by a notice (similar to the one shown here) at the start of each subsection. It is important that you reference the correct section in order to ensure that your changes are recognized by File Manager.


Note:	Following installation, customization should be accomplished by the method outlined in Post-Installation Customization.

Regardless of the degree of customizing that you anticipate for your installation of File Manager it is important to review all of the options available and to have a well-thought-out plan for implementing this system at your site. In some instances, after the system is in use, you cannot return to the previous installation without a great deal of effort.

Pre-Installation Customization

This section covers areas of customization that should be addressed following the software load but prior to the actual installation. The critical nature of the timing has to do with the fact that the database, that File Manager uses to maintain information on the file system, must be initialized during installation to match the specific architecture that you desire for your site.

Hierarchy Layout


Caution:	This step of customizing cannot be changed after installation!

The hierarchy layout refers to the depth of the tree structure where your users operate as well as the generic labels that each of these levels contain. File Manager allows up to ten levels in depth to be defined and used for file storage.

Customizing is controlled using a configuration file which can be found in the installation directory after you load the software. This file is called:

P3_HOME/Filemanager/install/smdl_fm_hierarchy

The general rules for editing this file are:

• Each line contains the label to be assigned to the next level in the hierarchy.

• Levels proceed from top (most general) to bottom (most specific).

• Comment lines may be entered by starting the line with a dollar sign ($) and can occur throughout the file (although partial line comments are not supported).

The following is a sample customization file that establishes the default hierarchy.

$: FileManager Hierarchy Definition

$:

$: This file provides the mechanism for customizing the hierarchy

$: layout for your installation of FileManager.  You may change

$: the number of levels and the labels for each to best suit your

$: needs (up to a maximum of 10 levels).

$:

$: Replace the default configuration below with the desired levels!

$:

$: Entry format: (example shows a three deep hierarchy structure)

$:	<level-label>

$:	<next_level-label>

$:	<last_level-label>

$:

$: Reminders:

$:	YOU ARE LIMITED TO TEN (10) LEVELS FOR YOUR HIERARCHY!

$:	ONCE INSTALLATION IS COMPLETE CHANGES CANNOT BE MADE WITHOUT

$:	RE-INSTALLING AND THUS DESTROYING THE EXISTING SYSTEM!

$:

Project

Configuration

Component

Team

Administrative Privileges


Note:	Following installation, customization should be accomplished by the method outlined at the Section Post-Installation Customization.

Several functions provided under File Manager are restricted from use by the general user community. These are found through the Admin... option from the File Manager menu. In general, these operations can make drastic changes to the system and its files and should be performed only by a select group of users that have a thorough understanding of the system. These users are referred to as administrators and are recognized by the system through the use of two configuration files. Prior to installation, the file:

P3_HOME/Filemanager/install/smdl_fm_administrators

can be used to identify users who are allowed access to the additional capabilities listed under Function Summary.

The general rules for editing this file are:

1. Each line contains the user-name (not user-ID) of an administrator.

2. Comment lines may be entered by starting the line with a dollar sign ($) and can occur throughout the file (although partial line comments are not supported).

Note that root is always given administrator privileges and there is no need to include it in the customization file.

The following is a sample customization file that establishes the user big_kahuna as the sole administrator.

$: FileManager Administrative User List

$:

$: To permit a user to have access to administrative functions

$: within FileManager, include their user-id on a separate line.

$:

$: Changes to this list may be made post-installation, HOWEVER they

$: must be made on the version which is placed with the FileManager

$: database! (located in <smdl_fm_repository>/smdl_fm_administors)

$:

$:  Entry format: <user-id>

big_kahuna

As mentioned in the header of this file, after installation the copy resident in the installation directory is no longer the official version. This is because the file must be copied to a location that is globally available to every client that starts File Manager. To accomplish this, the installation process copies the file to:

	<smdl_fm_repository>/smdl_fm_administrators

where, <smdl_fm_repository> is the directory name that you provide during the installation procedure for holding the database and directory structure known collectively as the repository.

File Associations


Note:	Following installation, customization should be accomplished by the method outlined at the Section Post-Installation Customization.

File associations (the ability to relate two files to one another) are an important part of the File Manager system. After established, an association allows a user to get to one file based on the relationship it has to another.

For example, the File Manager could be configured to hold not only FEM related files (such as MSC.Patran databases), but also the geometry files typically used as the starting point for FEM modeling (like CATIA or Unigraphics files). By also providing an association labeled Parent Geometry, the user would be able to link the geometry file imported to the FE model file that received the data. This provides traceability to the engineering process (and potential support for automating updates between related files).

Customization is controlled through a configuration file which can be found in the installation directory after you load the software. That file is called:

P3_HOME/Filemanager/install/smdl_fm_associations

The general rules for editing this file are:

• Each line contains three fields delimited by colons (:). These fields hold information about a single association:

1. Association ID - a unique integer number assigned to this association.

2. Association label - the text string by which users refer to this association.

3. Association strength.

• Comment lines may be entered by starting the line with a dollar sign ($) and can occur throughout the file (although partial line comments are not supported).

Association strength provides a means of defining associations which are unavailable to the user community, but can be relied on by other software customizations.
Two options are available: Strong and Weak.

Strong associations are reserved for software customizations that must rely on their existence (i.e., the user is never allowed to build or break these associations except throughout the intended customization software). In addition, file deletions are prohibited on files that have these types of relationships because this would presumably render the customized software useless. These are designated in the configuration file by entering the string Strong in the third field.

Weak associations are those to which the users have direct access. They may be built and broken through the conventional File Manager interface and have no affect on file deletion. These are designated in the configuration file by entering the string Weak in the third field.

A sample customization file is shown, that establishes two file associations. The first follows the example previously given and allows the user community to establish pointers between FEM files and geometry files. The second is intended to be used by a software add-on that provides a simple fastener strength check based on inputs associated with the FEM model. The input file for this analysis can be stored in File Manager and related to the FEM file from which the data was gathered.

$: FileManager Association Customization File

$:

$: Changes to this list may be made post-installation, HOWEVER they

$: must be made on the version which is placed with the FileManager

$: database, located in <smdl_fm_repository>/smdl_fm_associations.

$:

$: Entry format <assoc-id>:<assoc-label>:<assoc-strength>

$: (for more info refer to the File Manager Administrators Guide

$:

$: Warning: EXISTING ENTRIES SHOULD NOT BE CHANGED!

$:          =======================================

$:

1 : Parent Geometry : WEAK

2 : Fastener Check : STRONG


Caution:	The File Manager stores information about associations based on the association-ID. These should never be changed after established. You may add additional IDs and even change association-labels and association-strengths, but a change to the ID may render the system unusable!

As mentioned in the header of this file, after installation has occurred the copy resident in the installation directory is no longer the official version. This is because the file must be copied to a location that is globally available to every client that starts File Manager. To accomplish this, the installation process copies the file to:

<smdl_fm_repository>/smdl_fm_associations

where, <smdl_fm_repository> is the directory name that you provide during the installation procedure for holding the database and directory structure known collectively as the repository.

Post-Installation Customization

This section covers areas of customization that can be addressed following the installation of File Manager. Many of these operations are also configurable prior to installation, and doing so alleviates some of the confusion associated with finding the correct configuration files.

Repository

Following installation, any administrator is capable of adding and removing branches to the hierarchy being managed by File Manager. This must be accomplished through the user interface described in the section Function Summary.

The UNIX directory structure, used to hold the user files and referred to as the repository, should not be changed without first consulting your MSC.Software Application Engineer for guidance. File Manager starts with the directory name which is supplied at initialization and builds subdirectories in a very regimented manner. Relocating any of these UNIX directories makes it impossible for File Manager to recognize any of the files being moved.

Administrative Privileges


Note:	Prior to installation, customization should be accomplished by the method outlined at the Section Pre-Installation Customization.

Following installation, the file:

<smdl_fm_repository>/smdl_fm_administrators

where, <smdl_fm_repository> is the directory name that was provided during the installation procedure, can be used to identify users who should be allowed access to the additional functions listed under Function Summary. As with pre-installation customization, additional administrators can be registered by adding their user names to the file.

The following is a sample customization file that establishes the user big_kahuna as the sole administrator.

$: FileManager Administrative User List

$:

$: To permit a user to have access to administrative functions

$: within FileManager, include their user-id on a separate line below.

$:

$: Changes to this list may be made post-installation, HOWEVER they

$: must be made on the version which is placed with the FileManager

$: database! (located in <smdl_fm_repository>/smdl_fm_administors)

$:

$:  Entry format: <user-id>

big_kahuna

File Associations


Note:	Prior to installation, customization should be accomplished by the method outlined at the Section Pre-Installation Customization

Following installation, the file:

<smdl_fm_repository>/smdl_fm_associations

where, <smdl_fm_repository> is the directory name that was provided during the installation,
can be used to identify the file associations supported for use by both the user community and
customized software.

The following is a sample customization file that establishes two file associations. The first allows the user community to establish pointers between the FEM files and geometry files. The second is intended to be used by a software add-on that provides a simple fastener strength check based on inputs associated with the FE model. The input file for this analysis can be stored in File Manager and related to the FEM file from which the data was gathered.

$: FileManager Association Customization File

$:

$: Changes to this list may be made post-installation, HOWEVER they

$: must be made on the version which is placed with the FileManager

$: database, located in <smdl_fm_repository>/smdl_fm_associations.

$:

$: Entry format <assoc-id>:<assoc-label>:<assoc-strength>

$: (for more info refer to the File Manager Administrators Guide

$:

$: Warning: EXISTING ENTRIES SHOULD NOT BE CHANGED!

$:          =======================================

$:

1 : Parent Geometry : WEAK

2 : Fastener Check : STRONG

Scripts

Several scripts are provided for you to modify in order to customize the behavior of File Manager functionality. The following table lists each of the scripts available for modification and the subsequent sections give details. Scripts provide the ability to do and undo an operation. These are listed together in the following table with the undo script in parenthesis.


Script Name	Description
compress_XX (uncompress_XX)	Allow for site specific resource management through file compression.
offline_XX (online_XX)	Allow for site specific resource management through file archival, via an offline procedure.
release (unrelease)	Provide a mechanism for connecting File Manager to a commercial PDM.

The first two scripts (those associated with compression and offline) actually provide for multiple pairs of scripts. This is done by appending a numerical ID to the script name allowing for improved methods to be implemented in the future without losing the ability to deal with legacy operations.

For example, you may decide to utilize a new compression utility that is more efficient at saving disk space. Both the original and new utility must be supported (until you are absolutely certain that all files in the system are no longer compressed with the old one). These scripts would be named compress_1 and compress_2 respectively. In conjunction with an environment variable (see the following section) the user may choose either method. In addition, the system automatically knows which undo script is required to revert a file back to the original.

After established, the numerical IDs must not be changed because File Manager maintains information about each file’s state based on these values. Changing the number on the script results in the inability to undo changes made to files in the system. Of course, you can also add new scripts and associated IDs.

Environment Variables

The following table describes the environment variables that can be used to influence the operation of the File Manager.


Environment Variable	Default	Description
SMDL_FM_LIST_DELAY	10	Delay in seconds between refreshes of file listings. This influences overall performance.
SMDL_FM_COMPRESS_MODE	1	Default mode of compression to use. Unless altered, the default method associated with a value of 1, is the UNIX compress/uncompress utility.
SMDL_FM_ARCHIVE_MODE	1	Default mode of archival to use. Unless altered, the default method associated with a value of 1, is the UNIX tar utility.
SMDL_FM_DEBUG	<none>	If set (to any value) turns on additional text output to the XTERM which echoes the operations being performed.

As originally installed, the default values provided by the system are sufficient to allow users to begin using the system and all of it’s features. If you provide any customization to the scripts previously mentioned, it may be necessary to ensure that all users define the two MODE settings in order to get the correct functionality.

Hierarchy Directory Structure