XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''"> Preference Components
The Marc Preference includes all of the following items:
1. A PCL function contained in the p3patran.plb PCL library which will add Marc specific definitions to any Patran database (not already containing such definitions) at any time.
2. The PCL library called mscmarc.plb contained in the <installation_directory>, also referred to as P3_HOME which can be set and referred to as an environment variable ($P3_HOME). This library is used by Patran to display analysis code specific job parameters, solution parameters, etc. It is automatically accessed when the Analysis Preference is set to Marc.
3. Three executable programs call marcp3, marpat3 and pat3mar contained in the $P3_HOME/bin/exe directory. These programs translate information from Marc files into Patran databases or translate information from Patran into Marc input files. These programs can be run independent of Patran but typically run transparently to the user.
4. Script files, executables and/or shared libraries contained in the $P3_HOME/bin/exe or $P3_HOME/lib directory. These control the execution of the executable programs mentioned above plus the submittal of Marc analyses.
5. This MSC.Marc Preference Guide. An online version is also provided to allow the direct access to this information from within Patran.
The diagrams shown below indicate how the functions, scripts, programs, and files which constitute the Marc Preference affect the Patran environment. Site customization, in some cases, is indicated.
MSC.AFEA also includes Marc and Patran in addition to the Marc Preference and its components as described above. An example of an <installation _directory> for separately installed components of Patran and Marc might be:
c:\msc\patran200x
c:\msc\marc200x
and example of an MSC.AFEA installation might be:
c:\msc\afea\patran200x
c:\msc\afea\marc200x
The P3_HOME variable refers to the Patran portion of the installation, e.g., c:\msc\patran200x or c:\msc\afea\patran200x in the above examples.
Forward Translation and Analysis Execution
Figure 1‑1 shows the process of running an analysis. The
mscmarc.plb library defines the necessary input required by the
Analysis application in Patran. When a job is submitted for analysis, the forward translator,
pat3mar, is invoked and Patran operation is suspended as data is read from the database and the Marc input file, named
jobname.dat,
is
created. (A message file, named
jobname.msg, is also created to record the translation messages, but these messages also appear in the Patran command window.) If
pat3mar finishes successfully and the user has requested it, the shared library
marcmonitor.dll prepares the job and starts the
MarcSubmit program, which then controls the submittal of the analysis. Through
MarcSubmit and the
marcmonitor.dll shared library, the job can be monitored and controlled directly from the Marc Preference in Patran.
Figure 1‑1 Forward Translation and Analysis Execution
Note: | The MarcSubmit program is not used when the Patran Analysis Manager is used to submit and manage analysis jobs. The Patran Analysis Manager replaces the function of MarcSubmit and the marcmonitor.dll shared library. See the Patran Analysis Manager User’s Guide. |
Reverse Translation
Figure 1‑2 shows the process of accessing data from an Marc analysis results file back into Patran for postprocessing. When results are accessed, a job control file, named
jobname.jbr, is created. The results are then either directly imported into the Patran database or attached, in which case they remain in the results (POST) file. Results are imported via the
ResultsSubmit script and the
marpat3 executable where Patran is suspended while this conversion occurs. However, results are attached via routines in the
marcdra.dll dynamically linked library. This is called direct results access or DRA. While the POST file is attached, data is retrieved from it on an as-needed basis when postprocessing plots are made. If the POST file is deleted, detached, or renamed, the results will no longer be accessible in Patran. A message file is created to record the translation messages.
Figure 1‑2 Results Translation
Input File Import
Figure 1‑3 shows the process of reading model data from an Marc input file. When the
file is imported, Patran is suspended while this conversion occurs by running a program called
marcp3. Two files are created to record the translation messages.
marcp3 reads the data from the Marc input file and loads the Patran database directly. Any errors that occur are reported in the
jobnmane.err file and any Marc keywords and data not recognized or supported are dumped to the reject file,
jobname.rej. Information from the input file that ends up in the reject file can be included with a subsequent job setup via the Preference using the direct text input capability. This text will then be saved with the job directly in the Patran database. See
Job Parameters for more detail on this feature.
Figure 1‑3 Input File Translation
File Descriptions
The table below lists all files either used or created by MSC.AFEA or the Marc Preference. The occurrence of name or jobname in the definition should be replaced with the database name or jobname respectively, assigned by the user.
File Name | Description |
name.db | This is the Patran database from which the model data is read during translation, and into which model and/or results data is written during a read operation. |
name.db.jou
patran.ses.xx | A journal file records all commands issued in Patran (or MSC.AFEA) associated to a particular database. Also a separate session file, which gets versioned (.xx), is created each session. All commands during that session are recorded in this session file. The session files can be played back (File | Session | Play) or the journal file relayed to reproduce the model (File | Utilities | Rebuild). |
jobname.jba jobname.jbr | These are small control files used to pass certain information between Patran and the Marc Preference executables during translation. The user should never have a need to do anything with these files, except delete them as necessary. |
jobname.dat
#jobname.dat | This is the Marc input file created by MSC.AFEA or the Marc Preference for an analysis (or read to import model data). When domain decomposition is used, multiple files are produced where # is the domain number. |
jobname.t16
#jobname.t16 | This is the Marc binary results (POST) file created by an Marc analysis the contents of which can be imported or attached for postprocessing. When domain decomposition is used, multiple files are produced where # is the domain number. |
jobname.t19
#jobname.t19 | This is the Marc ASCII results (POST) file created by an Marc analysis the contents of which can be imported or attached for postprocessing. When domain decomposition is used, multiple files are produced where # is the domain number. |
jobname.log
#jobname.log | This is the log file from the Marc execution. Check it for any possible errors in the job. When domain decomposition is used, multiple files are produced where # is the domain number. |
jobname.sts | This is the Marc status file which is a tabular listing of step, increment, and iteration information. Check it during an analysis to monitor progress or completion. |
jobname.out
#jobname.out | This is the Marc output file. Most errors are reported in this file if a job is unsuccessful. When domain decomposition is used, multiple files are produced where # is the domain number. |
jobname.t08 | This is a restart file produced by Marc when a restart job is requested. To restart from a previous job, you must reference this file. |
marcp3*.msg | This file contains any error or informational messages from the may have occurred when importing data from an Marc input file (jobname.dat). |
jobname.rej | This file contains any keywords and data not recognized when importing data from an Marc input file (jobname.dat). |
jobname.msg | This message file contains any diagnostic output from the translation, either forward (when submitting an Marc analysis) or reverse (when accessing results). This is an important file to check if analysis execution is not successful. |
sgmps.log
nurbtrans.log | Check the contents of these files, If errors occur on translation of rigid bodies to the Marc input deck. |
metis* | These are various diagnostic files created when automatic domain decomposition is used (MARC_DEBUG environment variable set to YES). |
Template Databases
When you create a new model (or database) in Patran or with MSC.AFEA, you open a template database stored in the installation directory (referred to as P3_HOME). Three versions of the template Patran database are delivered as standard. They are located in P3_HOME and are named base.db, mscmarc_template.db, and template.db.
The former (base.db) is an Patran database into which no analysis code specific definitions, such as element types and material models, have been stored. The latter (template.db) is a version which contains many analysis code specific definitions already defined, which is the default used when creating a new database for Patran. Because definitions of other analysis codes are contained in this default template database, it is larger than needs to be if only Marc (or MSC.AFEA) is to be used.
If you wish to use a database that contains only Marc specific analysis code definitions, use the mscmarc_template.db template delivered in P3_HOME when creating a new database (or rename it to template.db such that it becomes the default).
Note: | Typical installations on Windows platforms of MSC.AFEA will only have Marc available as the analysis code in the default template database. |
In order to create a template database which contains only Marc specific definitions, follow these steps:
1. Open a new database under File|New in Patran but specify base.db as the template. This is done in the file browser that appears.
2. Enter load_mscmarc() into the command line. This command adds the Marc specific definitions into the database for Marc versions K7, 2000, 2001, and 2003.
3. Save this database under a name like marc.db to be your new Marc only template database or call it template.db and replace the original in P3_HOME.
4. From then on, if you have not replaced template.db, choose marc.db as your template when creating a new database.
For more details about adding analysis code specific definitions to a database and/or creating unique template databases, refer to
Modifying the Database Using PCL (Ch. 7) in the PCL and Customization or to the
Patran Installation and Operations Guide.
Analysis Submission Configuration
The MarcSubmit executable controls the execution of the Marc analysis code. It is located in the UNIX directory called:
$P3_HOME/bin/exe/MarcSubmit
or on Windows:
$P3_HOME\bin\MarcSubmit.exe
where P3_HOME is the installation directory (and the $ indicates its use as a variable). The information that MarcSubmit uses to perform its operations can be categorized as either specific to the job or the site. The job specific information is automatically supplied by Patran (or MSC.AFEA) at run time. The site specific information is set at the time of installation and should not have to be set or reset unless the physical location of Marc (or MSC.AFEA), is changed or possibly if the different components are installed separately. Site specific information is set up specific to the platform type. In most cases you should never have to modify them. However, if a change occurs, you simply edit the UNIX site setup file:
$P3_HOME/site_setup
or the Windows site file:
$P3_HOME\P3_TRANS.INI
Note: | The explanations in this section do not apply if you are using the Patran Analysis Manager to submit and manage analysis jobs from Patran (or MSC.AFEA). The Patran Analysis Manager must be separately configured and will override any settings here. If you have the Patran Analysis Manager installed but wish to use this method of submittal you can type analysis.manager.disable() in the Patran command line or include it in startup session file script. To re-enable Patran Analysis Manager, use analysis.manager.enable(). See the Patran Analysis Manager User’s Guide. |
UNIX Site Setup
The site_setup file contains the following environment variables corresponding to the parameters in the MarcSubmit program:
setEnv MSCP_MARC_HOST7 <machine name where MARC K7 resides>
setEnv MSCP_MARC_HOST2000 <machine name where MSC.Marc 2000 resides>
setEnv MSCP_MARC_HOST2001 <machine name where MSC.Marc 2001 resides>
setEnv MSCP_MARC_HOST2003 <machine name where MSC.Marc 2003 resides>
setEnv MSCP_MARC_SCRATCHDIR <path of scratch directory>
setEnv MSCP_MARC_CMD7 <your MARC K7 solver command path>
setEnv MSCP_MARC_CMD2000 <your Marc 2000 solver command path>
setEnv MSCP_MARC_CMD2001 <your Marc 2001 solver command path>
setEnv MSCP_MARC_CMD2003 <your Marc 2003 solver command path>
The MSCP_MARC_HOST# parameter defines the machine that is used to perform the Marc analysis. When this parameter is set to LOCAL, the analysis is performed on the same machine as the Patran (or MSC.AFEA) session. (pat3mar translations are always performed on the same machine as the session. This only affects where Marc is run.)
The SCRATCHDIR parameter defines the directory on the host machine that temporarily holds the analysis files as they are created. The advantage of having a scratch directory is that the contents of the analysis scratch files are never transferred across the network. This benefit is not achieved when the HOST parameter is set to LOCAL, so the SCRATCHDIR parameter is ignored for this condition.
The MSCP_MARC_CMD#, parameter defines the path and file name of the scripts that run the K7, 2000, 2001, or 2003 versions of the Marc analysis code. MarcSubmit uses this parameter to point to MARC K7, Marc 2000, Marc 2001, or Marc 2003 installations, respectively.
As an example, for a local installation of Marc 2001, you would need at a minimum, the following:
setEnv MSCP_MARC_HOST2001 LOCAL
setEnv MSCP_MARC_CMD2001 /msc/marc2001/tools/run_marc
For a remote host you would need the following as an example:
setEnv MSCP_MARC_HOST2001 baytown
setEnv MSCP_MARC_SCRATCHDIR /tmp
setEnv MSCP_MARC_CMD2001 /msc/marc2001/tools/run_marc
Note: | All of the above parameters can also be set as environment variables. If the system detects that one of more of these environment variables has been set, they override the settings in site_setup. This way you can temporarily change settings without editing the site_setup file. |
Windows
The same information is needed on the Windows platform as for UNIX as described above. However, on the Windows platform, the site specific parameters are found in the $P3_HOME\P3_TRANS.INI file. The run_marc command on Windows must be specified by its full file name which is run_marc.bat.
As an example, for a local installation of Marc 2001, you would need at a minimum, the following under the [MscMarc] section of the P3_TRANS.INI file:
[MscMarc]
Host=LOCAL
Hosttype=Windows
Acommand2001=c:\msc\marc2001\tools\run_marc.bat
For a remote host (UNIX) submittal you would need the following as an example:
[MscMarc]
Host2001=dallas
Hosttype=UNIX
Scratchdir=/tmp/marctmp
Acommand2001=/msc/marc2001/tools/run_marc
Outputfiles=out,log,t16,t19,*
OutputTypes= a, a, b, a,b
The last two entries, determine which output files, by their suffix names, will be transferred back to the submitting host when the job is completed and the type of file it is (ASCII=a or binary=b). A wild card (*) can be used to specify all output files.
Note: | Patran versions prior to 2003 used a script or executable (on Windows) called MarcExecute(.exe). This has been obsoleted in this version, however, if you wish to continue to use it, set the environment variable MARCEXECUTE to YES. With this method of remote submittal from a Windows machine to any other machine requires a remote shell service running on your Windows machine(s). For more information on this see Module and Preference Setup (p. 14) in the Patran Installation and Operations Guide |
Remote Submittal Program
Remote submittal (not via the Patran Analysis Manager) is accomplished using a separately spawned program called MarcSubmit and can be executed independently of Patran, however this should never be necessary. This section is included for completeness. Only UNIX to UNIX or Windows to UNIX remote submittal is supported. (For more complex remote submittals use the Patran Analysis Manager.) Simply typing the name of the program at the command prompt will list all the necessary or acceptable input arguments. For example:
$P3_HOME/bin/MarcSubmit
will result in:
MarcSubmit -j jobname -m marcversion [-h host] [-s scratchdir]
[-v] [-l logfile] -c command_file
Arguments:
-j -job Required - job name
-m -marcversion Required - Marc Version
-v -verbose Have the program print out every command executed
and its status at completion.
-l logfile Logfile to output results of commands to.
-c command_file
File which contains the list of input files,
the command to be issued, and the list of
expected output files. This is an xml-like file
of the form (in any order):
<inputfiles>input file names</inputfiles>
<command>command</command>
<outputfiles>output file names</outputfiles>
<host>host computer</host>
<hosttype>host type - UNIX or windows</hosttype>
<scratchdir>scratch directory</scratchdir>.
Arguments with brackets around them are optional. An example might be:
$P3_HOME/bin/MarcSubmit -j s4 -m 2001 -c s4.cmd
At a minimum, the jobname, marcversion and command_file need to be supplied. The other arguments are optional and obtained from different sources such as UNIX environment variables or through the site_setup or P3_TRANS.IN files. If provided as command arguments, they take precedent over any other settings. The command_file is created by the marcsubmit.dll when the job is submitted and deleted at job completion. An example is shown here:
<command>/solvers/marc2001/tools/run_marc -j s4 -b yes -v no</command>
<host>tavarua</host>
<hosttype>UNIX</hosttype>
<scratchdir>/tmp/marctmp</scratchdir>
<inputfiles>s4.dat;</inputfiles>
<outputfiles>s4.dat;s4.log;s4.sts;s4.out;s4.t16;</outputfiles>
<compiletime>300</compiletime>
<command> is the actual submittal command to execute on the remote <host> called tavarua which of <hosttype> UNIX and should execute in <scratchdir> /tmp/marctmp. The input files to copy to the remote host and output file to copy back are listed, separated by semicolons.
If a user subroutine is used, <compiletime> sets the compile and link time before checking for a time out. If the time is not sufficient, then the monitoring of the job (which is run by the MarcSubmit executable) starts looking for files and progress in the run. If it does not get any in 5 minutes, then it assumes that something is wrong and brings all the files back which essentially kills the job. So by default, the process allows for about 10 minutes to compile and run to the first job iteration (zeroth increment).
If this is not sufficient there is a PCL command that can be issued at the command prompt or included in a startup file such as p3epilog.pcl or init.pcl, that will extend this:
marc_set_compile_time( minutes )
The allowable range is an integer between 1 and 60 minutes.
Note: | MSC.AFEA only supports local submittals. The above documented command_file is only used for remote submittals. To manually submit an Marc job locally, just use the run_marc script directly as explained in the Marc documentation. |
Submittal to LSF Queues
There is some basic support for submittals of Marc to LSF queues. LSF (Load Sharing Facility) is a widely used, load management software utility available from Platform Computing, headquartered in Ontario, Canada. LSF is particularly useful in a network of computers for determining least loaded CPUs. From this information, domain decomposition (parallel) jobs can be run most efficiently since LSF automatically chooses the least loaded hosts. This also eliminates the need for the user to prepare and decide (ahead of time) which machines to submit to.
In order to submit Marc jobs to an LSF queue via Patran, the following limitations and requirements exist:
1. Only submission to a cluster of UNIX machines is supported. The submittal machine must also be a UNIX machine. Windows is not supported at this time.
2. Both local and remote submittals are supported. That is, you may submit a job from a machine that is not configured with LSF to a machine that is configured with LSF. This is considered a remote submittal. A job submitted locally with LSF configured on the local machine is considered a local submittal.
3. The job must be submitted from a shared directory. In other words, all machines that will or could potentially run Marc parallel jobs, must be able to see the directory from which the job is submitted. (Files are not copied to local directories and then back to the submittal directory.)
4. Marc must be seen from all machines that potentially will run in parallel mode in exactly the same way. For example, if on machine A, the run_marc command is in /msc/marc2001/tools/run_marc, then it must be also on machine B. If this is not the case, then you must set up symbolic links to make it so. This could be done by putting symbolic links on all machines in the LSF network such that a link /usr/bin/run_marc points to whereever run_marc is located on each machine. You will need root access to do this.
5. The LSF command bsub is used to submit a job. It must be seen in the user’s path. The LSF environment is setup by sourcing the LSF C-shell script cshrc.lsf. See the LSF documentation for more details on the LSF operating environment. You may also create a symbolic link in /usr/bin to point to whereever the LSF bsub command is located since this is usually in the user’s path. You’ll need root access to do this.
6. Only homogeneous machines are supported. Example: if you submit to an HP machine, then only HP machines will be chosen as valid machines to run the parallel job.
In the
site_setup file (see
UNIX Site Setup), you will need to define one additional variable. This can be done in the
site_setup file and can also be done by defining the environment variable manually or via a startup script or other mechanism. The variables necessary in the
site_setup file for LSF submittal are at a minimum one of:
setEnv MSCP_MARC_HOST2001 LOCAL
setEnv MSCP_MARC_HOST2003 LOCAL
or for remote submittal:
setEnv MSCP_MARC_HOST2001 <machine with LSF for 2001 submittals>
setEnv MSCP_MARC_HOST2003 <machine with LSF for 2003 submittals>
This variable should NOT be set as the shared directory must be used. Make sure you have enough disk space in the shared directory.
setEnv MSCP_MARC_SCRATCHDIR <path of scratch directory>
To enable the LSF submittal, this variable must be set to yes:
setEnv MSCP_MARC_USE_LSF yes
If you wish to change the queue name to which a job is submitted, you must define this variable, otherwise all jobs are submitted to the default queue, which is generally called normal.
setEnv MSCP_MARC_LSF_QUEUE normal
If you require additional or more advanced submittal access and you are proficient with LSF, you may include additional items onto the submittal line by defining them in this variable, which is used to build up the LSF resource string:
setEnv MSCP_MARC_LSF_RESSTR <additional items>
For example if you wanted to only submit to machines with a certain amount of memory and swap available, you would define, say:
setEnv MSCP_MARC_LSF_RESSTR (mem>15)&&(swp>50)
Any string that can legally be placed in the LSF resource string can be defined by this variable. The above would submit a local job with
bsub -q normal -R "select[(mem>15)&&(swp>50)]" <run_marc>
where <run_marc> is the run_marc command plus all of its necessary arguments.
