Ansys Remote Solve Manager v13

ANSYS Remote Solve Manager (RSM)
ANSYS, Inc.
Southpointe
275 Technology Drive
Canonsburg, PA 15317
ansysinfo@ansys.com
http://www.ansys.com
(T) 724-746-3304
(F) 724-514-9494
ANSYS Release 13.0

November 2010
ANSYS, Inc. is
certified to ISO
9001:2008.
Copyright and Trademark Information

2010 SAS IP, Inc. All rights reserved. Unauthorized use, distribution or duplication is prohibited.
ANSYS, ANSYS Workbench, Ansoft, AUTODYN, EKM, Engineering Knowledge Manager, CFX, FLUENT, HFSS and any and
all ANSYS, Inc. brand, product, service and feature names, logos and slogans are registered trademarks or trademarks
of ANSYS, Inc. or its subsidiaries in the United States or other countries. ICEM CFD is a trademark used by ANSYS, Inc.
under license. CFX is a trademark of Sony Corporation in Japan. All other brand, product, service and feature names
or trademarks are the property of their respective owners.
Disclaimer Notice
THIS ANSYS SOFTWARE PRODUCT AND PROGRAM DOCUMENTATION INCLUDE TRADE SECRETS AND ARE CONFIDENTIAL
AND PROPRIETARY PRODUCTS OF ANSYS, INC., ITS SUBSIDIARIES, OR LICENSORS. The software products and documentation are furnished by ANSYS, Inc., its subsidiaries, or affiliates under a software license agreement that contains provisions concerning non-disclosure, copying, length and nature of use, compliance with exporting laws, warranties,
disclaimers, limitations of liability, and remedies, and other provisions. The software products and documentation may
be used, disclosed, transferred, or copied only in accordance with the terms and conditions of that software license
agreement.
ANSYS, Inc. is certified to ISO 9001:2008.
U.S. Government Rights

For U.S. Government users, except as specifically granted by the ANSYS, Inc. software license agreement, the use, duplication, or disclosure by the United States Government is subject to restrictions stated in the ANSYS, Inc. software
license agreement and FAR 12.212 (for non-DOD licenses).
Third-Party Software
See the legal information in the product help files for the complete Legal Notice for ANSYS proprietary software and
third-party software. If you are unable to access the Legal Notice, please contact ANSYS, Inc.
Published in the U.S.A.
Table of Contents
1. Overview ................................................................................................................................................. 1
1.1. RSM Roles and Terminology .............................................................................................................. 1
1.2. Typical RSM Workflows ...................................................................................................................... 2
1.3. File Handling .................................................................................................................................... 4
2. Installation and Configuration ............................................................................................................... 7
2.1. Installation ....................................................................................................................................... 7
2.1.1. Prerequisites for Installing RSM ................................................................................................. 7
2.1.2. Installing Standalone RSM Services on Linux ............................................................................. 7
2.1.3. Installing Standalone RSM Services on Windows ....................................................................... 7
2.1.4. Uninstalling RSM Services on Windows ..................................................................................... 8
2.2. Configuration ................................................................................................................................... 8
2.2.1. Configuring RSM on Windows .................................................................................................. 8
2.2.1.1. Starting RSM Services at Boot Time .................................................................................. 8
2.2.1.2. Configuring RSM for Mapped Drives ................................................................................ 8
2.2.2. Configuring RSM on Linux ........................................................................................................ 8
2.2.2.1. UNIX/Linux Path Configuration Requirements .................................................................. 9
2.2.2.2. Configuring RSM to Use a Remote Computing Mode ........................................................ 9
2.2.2.2.1. Configuring a Linux Machine to Use Native Mode .................................................. 10
2.2.2.3. Using RSM Startup Scripts .............................................................................................. 10
2.2.2.4. Starting RSM Manager and Compute Server Services Manually ....................................... 11
2.2.2.4.1. Starting the RSM Manager Manually ...................................................................... 11
2.2.2.4.2. Starting the Compute Server Manually .................................................................. 11
2.2.2.4.3. Starting XmlRpcServer Manually (Required for EKM Servers Only) .......................... 11
2.2.2.5. Starting RSM Services at Boot Time ................................................................................ 11
2.2.2.6. Removing the RSM Automatic Startup Capability ........................................................... 12
2.2.2.7. Additional UNIX/Linux Considerations ........................................................................... 13
2.2.2.7.1. Explicit Dynamics Systems .................................................................................... 13
2.2.2.8. RSH and SSH Job Limitations ......................................................................................... 13
2.2.3. Configuring a Multi-User RSM Manager or Compute Server ..................................................... 13
2.2.4. Configuring RSM Services for a Remote Computing Environment ............................................ 14
2.2.4.1. Adding a Remote Connection to an RSM Manager .......................................................... 14
2.2.4.2. Adding a Remote Connection to a Compute Server ........................................................ 14
2.2.4.3. Configuring Computers with Multiple Network Interface Cards (NIC) .............................. 15
3. User Interface ........................................................................................................................................ 17
3.1. Main Window ................................................................................................................................. 17
3.2. Menu Bar ........................................................................................................................................ 18
3.3. Tree View ........................................................................................................................................ 19
3.4. List View ......................................................................................................................................... 20
3.5. Progress Pane ................................................................................................................................. 21
3.6. Options Dialog Box ......................................................................................................................... 21
3.7. Desktop Alert ................................................................................................................................. 22
3.8. Accounts Dialog Box ....................................................................................................................... 22
3.9. Windows RSM System Tray Icon and Context Menu .......................................................................... 23
4. User Accounts and Passwords ............................................................................................................... 25
4.1. Caching an Account Password ......................................................................................................... 25
4.2. Manually Running the Password Application ................................................................................... 25
4.3. Adding Alternate Accounts ............................................................................................................. 26
4.4. Configuring UNIX/Linux Accounts When Using RSH/SSH .................................................................. 26
5. Administration ...................................................................................................................................... 29
5.1. Creating a Queue ............................................................................................................................ 29
ANSYS Release 13.0 - SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.
iii
ANSYS Remote Solve Manager (RSM)

5.2. Modifying RSM Manager Properties ................................................................................................ 30
5.3. Adding a Compute Server ............................................................................................................... 30
5.4. Testing a Compute Server ............................................................................................................... 32
6. Job Script Customization ...................................................................................................................... 35
6.1. Customizing an Existing Job ............................................................................................................ 35
6.2. Manually Submitting Jobs ............................................................................................................... 36
7. Integration with ANSYS Client Applications ......................................................................................... 37
7.1. RSM Supported Solvers ................................................................................................................... 37
7.2. RSM Integration with Workbench .................................................................................................... 37
A. Integrating Windows with UNIX/Linux using SSH/SCP .............................................................................. 39
B. Integrating Windows with UNIX/Linux using RSH/RCP .............................................................................. 43
C. Integrating Windows with Platform LSF Cluster ........................................................................................ 45
D. Integrating with Microsoft HPC ............................................................................................................... 47
E. Integrating UNIX/Linux with LSF and PBS Clusters ................................................................................... 51
Index .......................................................................................................................................................... 55
iv
Chapter 1: Overview
The Remote Solve Manager (RSM) is a job queuing system that distributes tasks that require computing resources. RSM enables tasks to be run in background mode on the local machine, sent to a remote machine
for processing, or tasks can be broken into a series of jobs for parallel processing across a variety of computers.
Computers with RSM installed are configured to manage jobs using three primary services: The RSM Client
service, the RSM Manager service, and the Compute Server service. You use the RSM Client interface to
manage jobs.
RSM Clients submit jobs to a queue, and the RSM Manager dispatches these jobs to idle Compute Servers
that run submitted jobs. These services and their capabilities are explained in RSM Roles and Terminology (p. 1)
The following topics are discussed in this overview:
1.1. RSM Roles and Terminology
1.2.Typical RSM Workflows
1.3. File Handling
1.1. RSM Roles and Terminology

The following terms are essential to understanding RSM uses and capabilities:
Job
A job consists of a job template, a job script, and a processing task submitted from a client application
such as ANSYS Workbench. The job template is an XML file that specifies input and output files of the
client application. The job script runs an instance of the client application on the Compute Server(s)
used to run the processing task.
Client Application
A client application is the ANSYS application used to submit jobs to RSM, and then solve those jobs as
managed by RSM. Examples include ANSYS Workbench, ANSYS FLUENT, ANSYS CFX, etc.
Queue
A queue is a list of Compute Servers available to run jobs. When a job is sent to a queue, the RSM
Manager selects an idle Compute Server in the list.
Compute Server
Compute Servers are the machines on which jobs are run. In most cases, the Compute Server refers to
a remote machine, but it can also refer to your local machine ("localhost").
The Compute Server can be a Windows-based computer or a Linux system equipped with Mono, the
open source development platform based on the .NET framework. The job script performs a processing
task (such as running a finite element solver). If the job script requires a client application to complete
that task, that client application must be installed on the Compute Server.
Once Compute Servers are configured, they are added to a queue (which can contain multiple Compute
Servers). Jobs must specify a queue when they are submitted to an RSM Manager.
Chapter 1: Overview
RSM Manager
The RSM Manager is the central RSM service that dispatches jobs to computing resources. It contains a
configuration of queues (lists of Compute Servers available to run jobs).
RSM Clients submit jobs to one or more queues configured for the RSM Manager, and their jobs are
dispatched to Compute Servers as resources become available.
The RSM administrator decides if users should use the RSM Manager on their local machine or a central
RSM Manager, depending on the number of users and compute resources.
RSM Client
The RSM Client is a computer that runs both RSM and a client application such as ANSYS Workbench.
RSM enables this computer to off-load jobs to a selected queue.
Compute Proxy
Proxy settings are used by job scripts to integrate with third-party job schedulers (for example, LSF, PBS,
Microsoft HPC) and UNIX/Linux machines (when native RSM service is not available).
Code Template
A code template is an XML file containing code files (for example, C#, VB, JScript), references, and support
files required by a job.
1.2. Typical RSM Workflows

Any computer with RSM installed can act as the RSM Client, RSM Manager, Compute Server, or any simultaneous combination of these three functions. This section provides an overview of several configurations of
these functions as they are typically seen in RSM workflows . For specific instruction regarding RSM configurations, refer to Configuration (p. 8).
The most effective use of RSM is to designate one computer as the RSM Manager for central management
of compute resources. All RSM Clients submit jobs to a queue(s) configured for that RSM Manager, and the
RSM Manager dispatches jobs as compute resources become available on Compute Servers.
The following list shows several typical RSM usage workflows:
1.
The RSM Client submits jobs using RSM (running locally) directly to itself so that the job runs locally
in background mode. Here, the RSM Client, the RSM Manager, and the Compute Server are all on the
local machine. This capability is available automatically when you install ANSYS Workbench.
2.
The RSM Client submits jobs to the RSM Manager running locally on the same machine. You can assign
a remote Compute Server to run the job or split the job between multiple Compute Servers, optionally
including your local machine (as depicted in the second workflow below). A remote Compute Server
requires RSM and the client application to be installed (the client application is typically installed with
ANSYS Workbench, which also includes RSM).
1.2.Typical RSM Workflows
3.
An RSM Client machine submits jobs to an RSM Manager running on a remote machine (refer to Adding
a Remote Connection to an RSM Manager (p. 14)). The remote machine also acts as the Compute Server.
This configuration is available automatically when both machines have ANSYS Workbench installed.
4.
An RSM Client machine submits jobs to an RSM Manager running on a remote machine. The RSM
Manager then assigns the job to a remote Compute Server(s). The RSM Client and the Compute Servers
must have ANSYS Workbench installed. You can install ANSYS Workbench on the RSM Manager, or
choose to install only standalone RSM software, as described in Installation (p. 7).
Chapter 1: Overview
1.3. File Handling

Input files are generally transferred from the RSM Client working directory, to the RSM Manager project
directory, and then to the Compute Server working directory where the job is run. Output files generated
by the job are immediately transferred back to the RSM Managers project storage when the job finishes.
The files are stored there until the client application downloads the output files. This section provides more
details about how RSM handles files.
Client Application
The location of files on the RSM Client machine is controlled by the client application (for example, ANSYS
Workbench). When the RSM Client submits a job to an RSM Manager, it specifies a directory where inputs
are found and where output files are placed. Refer to the client application documentation to determine
where input files are placed when submitting jobs to RSM.
Input files are copied to the RSM Manager immediately when the job is submitted.
RSM Manager
If the RSM Client and RSM Manager are on the same computer, the RSM Manager uses the RSM Clients
file location. Otherwise, the RSM Manager creates a project directory that contains all the inputs and
outputs for the job when a job is submitted. The base project directory location is controlled with the
Manager Properties dialog box (see Modifying RSM Manager Properties (p. 30)). All job files are stored
in this location until the RSM Client releases the job. Jobs can also be deleted manually in the RSM user
interface.
Compute Server
If the Compute Server is running on the same machine as the RSM Manager, then the job runs directly
in the RSM Managers project directory as an optimization. Otherwise, the Compute Server creates a
temporary directory in the location defined in the Working Directory field (see Adding a Compute
Server (p. 30)). When this property is blank, the system TMP variable is used. When the job is complete,
output files are immediately copied back to the RSM Manager's project directory and the temporary
directory is deleted.
Compute Proxies
Compute Proxy files are handled as follows:
UNIX Integration
If the RSH/SSH mechanism uses a remote UNIX compute resource, the Working Directory field in
the lower portion of the Compute Server Properties dialog box determines where files are located.
If this field is empty, the accounts home directory is used as the default location. In either case, a
unique temporary directory is created.
Third-party Schedulers
When using the RSM job scripts that integrate with third-party schedulers such as LSF, PBS, Microsoft
HPC (previously known as Microsoft Compute Cluster), etc., the file handling rules listed in this section
apply to the extent that RSM is involved. When the third-party scheduler runs its job, it may be necessary for it to copy files to/from the cluster node that was selected by that scheduler.
Network File Systems
Examples of network file systems include Windows shared folders or directories on UNIX computers
shared to PCs with SAMBA. Shared folders can be used to minimize file transfers. RSM places marker
files in the RSM Client, RSM Manager, and Compute Server directories to uniquely identify the job. If the
RSM Manager finds (by recursively searching subfolders) the RSM Clients marker in the project storage
area, it uses that folder rather than copying the files to a separate folder. Similarly, if the Compute
Server finds (by recursively searching subfolders) the RSM Managers marker, it uses that location rather
than copying files unnecessarily. While this leverages operating system level drivers optimized for network
1.3. File Handling

file manipulation, files are located on remote hard drives so there is significant network traffic. Each
customer must determine the RSM configuration that best utilizes network resources.
Chapter 2: Installation and Configuration

A general overview of RSM installation and configuration is presented in this chapter. Tutorials featuring
step-by-step instructions for specific configuration scenarios are available on the Download Center at https://www1.ansys.com/customer/.
2.1. Installation
RSM is automatically installed with ANSYS Workbench products. You can also install RSM by itself if desired.
For example, you may want to install RSM by itself on a computer that acts as a dedicated RSM Manager;
an RSM Manager requires only an RSM installation for connectivity with remote RSM Clients and Compute
Servers. RSM Clients and Compute Servers require ANSYS Workbench, the ANSYS applications you want to
run, and RSM. Administrator privileges are not required to install or uninstall RSM on RSM Client machines.
The following RSM installation topics are discussed in this section:
2.1.1. Prerequisites for Installing RSM
2.1.2. Installing Standalone RSM Services on Linux
2.1.3. Installing Standalone RSM Services on Windows
2.1.4. Uninstalling RSM Services on Windows
2.1.1. Prerequisites for Installing RSM

RSM is supported on Windows platforms and UNIX/Linux platforms equipped with Mono. Mono permits
Windows and Linux installations to freely interact without additional configuration (for example, RSH or
SSH).
RSM supports UNIX/Linux systems via compute proxy settings of the Compute Server and customized job
scripts. Built-in job scripts for the ANSYS solvers use RSH and SSH network communication protocols. Support
for other protocols is possible using customized job scripts (see Job Script Customization (p. 35)).
Support of Third-party job schedulers such as LSF, PBS, and Microsoft HPC are supported using compute
proxy settings and custom job scripts. Built-in job scripts for the ANSYS solvers integrate with LSF (Windows
and Linux), PBS (Linux only), and Microsoft HPC in this way. Additional job schedulers can be integrated via
customized job scripts (see Job Script Customization (p. 35)).
2.1.2. Installing Standalone RSM Services on Linux

To install RSM and its related services without ANSYS Workbench on Linux, locate the RSM.TGZ file on the
distribution media. This is a tar formatted file for use on Linux computers. Extract the files to a desired location,
maintaining the directory structure.
2.1.3. Installing Standalone RSM Services on Windows

To install the RSM Manager and Compute Server services on Windows:
1.
Log into a Windows account with administrative privileges.
2.
Ensure that Ans.Rsm.* processes are not running in the Windows Task Manager.

3.
Open a command prompt in the [RSMInstallDir]\bin directory.
4.
Run the command, AnsConfigRSM.exe mgr -svr
Note
Windows Vista and Windows 7 users may need to select the Run as Administrator option.
2.1.4. Uninstalling RSM Services on Windows

RSM is automatically removed when ANSYS Workbench is uninstalled. To uninstall standalone RSM services,
run AnsUnconfigRSM.exe. The RSM installation directory can be deleted after services have been unregistered.
2.2. Configuration
The following RSM configuration topics are discussed in this section:
2.2.1. Configuring RSM on Windows
2.2.2. Configuring RSM on Linux
2.2.3. Configuring a Multi-User RSM Manager or Compute Server
2.2.4. Configuring RSM Services for a Remote Computing Environment
2.2.1. Configuring RSM on Windows

The following RSM Windows configuration topics are discussed in this section:
2.2.1.1. Starting RSM Services at Boot Time
2.2.1.2. Configuring RSM for Mapped Drives

To configure Windows to start RSM services automatically at startup, install (or uninstall, and then reinstall)
RSM services as described in Installing Standalone RSM Services on Windows (p. 7).
2.2.1.2. Configuring RSM for Mapped Drives

If RSM is used to solve local or remote jobs on mapped network drives, you may need to modify security
settings to allow code to execute from those drives because code libraries may be copied to working directories within the project.
You can modify these security settings from the command line using the CasPol utility, located under the
.NET Framework installation (e.g., C:\Windows\Microsoft.NET\Framework\v2.0.50727 for a 32bit machine). In the example below, full trust is opened to files on a z:\ mapped drive to enable software
to run from that share:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CasPol.exe -q -machine -ag 1.2 -url "file://z:/*"
FullTrust -name "Mapped Drive Work Dir"
For more information on configuring RSM Clients and Compute Servers using a network installation, please
refer to Network Installation and Product Configuration.

The following RSM Linux configuration topics are discussed in this section:
8

2.2.2.1. UNIX/Linux Path Configuration Requirements
2.2.2.2. Configuring RSM to Use a Remote Computing Mode
2.2.2.3. Using RSM Startup Scripts
2.2.2.4. Starting RSM Manager and Compute Server Services Manually
2.2.2.6. Removing the RSM Automatic Startup Capability
2.2.2.7. Additional UNIX/Linux Considerations
2.2.2.8. RSH and SSH Job Limitations
2.2.2.1. UNIX/Linux Path Configuration Requirements

The RSM job scripts that integrate with UNIX/Linux using SSH and RSH (keywords "PSSH" and "RSH") require
you to set AWP_ROOT130 in the user's environment variables. If the job is not running properly, check the
job log in the Progress Pane for "Command not found". Remote command clients like RSH and PuTTY
SSH use the remote account's default shell for running commands. For example, if the account's default
shell is CSH, the following line needs to be added to the .cshrc file (path may be different for your environment):
setenv AWP_ROOT130 /ansys_inc/v130
Note
~ (tilde) representation of the home directory is not supported for use in RSM paths (for example, the working directory in Compute Server properties).
Different shells use different initialization files than the account's home directory and may
have a different syntax than shown above. Refer to the UNIX/Linux man page for the specific
shell or consult the machine administrator.
2.2.2.2. Configuring RSM to Use a Remote Computing Mode

When RSM is installed on a Linux/UNIX-based platform, you can select either native (TCP/IP) communication
mode or SSH communication mode for RSM to communicate with remote machines. The differences between
these two modes are detailed below:
Native communication
SSH communication
Protocol Type
Uses standard TCP/IP to communicate

with Compute Servers
Uses SSH service to execute commands and

copy data to/from Compute Servers
Installation Requirements
Requires RSM to be installed and running on the Compute Server (see

Starting RSM Manager and Compute
Server Services Manually)
Requires installation of SSH client (Putty

SSH) on the RSM Client machines (see Appendix A).
Data Transfer Efficiency
Most efficient data transfer for solution

process launch and retrieval of results
Communication overhead slows solution

process launch and retrieval of results
Platform Support
Supported on Windows & Linux only
Supported on all platforms
ANSYS recommends that you use native communication where possible, and use SSH where platform support
or IT policy requires it.
2.2.2.2.1. Configuring a Linux Machine to Use Native Mode

On the Linux Compute Server:
1.
Run the ./rsmmanager and ./rsmserver scripts to manually start the RSM Manager and Compute
Server services. Refer to Starting RSM Manager and Compute Server Services Manually (p. 11) for more
information.
2.
Configure RSM to start the RSM Manager and Compute Server services at boot, as described in Starting
RSM Services at Boot Time (p. 11)
3.
On the RSM Client machine, configure the Computer Server Properties as shown below, substituting
a valid hostname and working directory (refer to Adding a Compute Server (p. 30) for more information
on configuring Compute Server properties):
2.2.2.3. Using RSM Startup Scripts

A set of convenient shell scripts are located in RSMInstallDir/RSM/Config/tools/linux. These
scripts include:
rsmadmin
Starts the RSM user interface.
rsmpassword
Starts the RSM password caching application.
rsmutils
Starts the RSM utility application.
Note
These shell scripts are dependent on their relative location in the Workbench installation so they
cannot be moved. This is not the case with the daemon scripts (rsmmanager and rsmserver).
10
2.2.2.4. Starting RSM Manager and Compute Server Services Manually

RSM Managers and Compute Servers must have RSM services (daemons) running in order to manage or run
jobs. If you are submitting jobs to an RSM Manager or Compute Server on a remote machine, use the scripts
detailed in this section to manually start RSM services. These scripts include:
rsmmanager - Starts the RSM Manager service.
rsmserver - Starts the Compute Server service.
XmlRpcServer - Starts the XmlRpcServer service (required for EKM servers only).
These scripts are located in RSMInstallDir/RSM/Config/tools/linux. If for some reason these

scripts were not generated during installation, run the rsmconfig script to manually generate the scripts.
Copy these scripts to /etc/init.d to start them automatically at boot time. Refer to Starting RSM Services
at Boot Time (p. 11) for details.
2.2.2.4.1. Starting the RSM Manager Manually

The RSM Manager script is called rsmmanager.
To start the service manually:
./rsmmanager start
To stop the service:

./rsmmanager stop
2.2.2.4.2. Starting the Compute Server Manually

The Compute Server script is named rsmserver.
./rsmserver start

./rsmserver stop
2.2.2.4.3. Starting XmlRpcServer Manually (Required for EKM Servers Only)

The xmlrpc server script required for EKM is named rsmxmlrpc.
./rsmxmlrpc start

./rsmxmlrpc stop

You can configure the RSM services to start automatically at system boot time. If the services are not configured to start automatically at boot, they will have to be started manually. The table below contains platform-
11

specific instructions to start services automatically when the system is rebooted. Replace rsmscriptname
with the actual script name as given in Starting RSM Manager and Compute Server Services Manually (p. 11).
Note
The procedure described in this section starts a service as root. It is not essential that the RSM
services run as root user.
Table 2.1 Automatic Startup Instructions

Platform
Linux: Red
Hat
Instructions
1.
Remove any existing startup information for the same version.
2.
Edit the file /etc/rc.d/rc.local and delete the RSM lines.
Note
Non-root user cannot save changes to this file.
3.
Issue the new startup instructions:

cp [RSMInstallDir]/v130/RSM/Config/tools/linux/rsmscriptname /etc/init.d
chmod 555 /etc/init.d/rsmscriptname
chkconfig --add rsmscriptname
chkconfig rsmscriptname on
Linux: SUSE
1.
Remove any existing startup information for the same version.
2.
Edit the file /etc/rc.d/boot.local and delete the RSM lines.
Note
Non-root user cannot save changes to this file.
3.
Issue the new startup instructions:

cp [RSMInstallDir]/v130/RSM/Config/tools/linux/rsmscriptname /etc/init.d
chmod 555 /etc/init.d/rsmscriptname
chkconfig --add rsmscriptname
chkconfig rsmscriptname on
After you have completed the procedure to start a service automatically at boot time, reboot the system to
verify that the automatic boot procedure is working correctly. After the system has rebooted, check to see
that services are running by typing the appropriate ps command and looking for Ans.Rsm in the resulting
display; for example:
ps aux | grep Ans.Rsm
2.2.2.6. Removing the RSM Automatic Startup Capability

To remove RSM automatic startup capabilities from a Linux machine, issue the following commands:
12

/etc/init.d/rsmscriptname stop
chkconfig --del rsmscriptname
rm /etc/init.d/rsmscriptname
2.2.2.7. Additional UNIX/Linux Considerations

You need to be aware of the following considerations when running RSM on Linux:
2.2.2.7.1. Explicit Dynamics Systems
2.2.2.7.1. Explicit Dynamics Systems

RSM does not support UNIX/Linux connections for Explicit Dynamics systems. Only Windows-to-Windows
connections are currently supported.
2.2.2.8. RSH and SSH Job Limitations

File Size Limitation The Windows RCP and PuTTY SCP clients have file size limitations that RSM circumvents
by splitting and joining very large files (greater than 2GB). The Windows Compute Server and the UNIX/Linux
compute proxy machine may also have file system limitations beyond the control of RSM. You must configure
the UNIX/Linux machine with large file support, and the Windows file system must be NTFS in order to
transfer files larger than approximately 2GB. If any job output file is not successfully retrieved, all job output
files are left on the compute proxy machine. Consult the job log for the temporary directory name used for
the job. These files can then be retrieved manually and loaded by the ANSYS Workbench Mechanical Application. See Writing and Reading the Mechanical APDL Application Files in the Mechanical User's Guide for
details.
RCP Client Issues The Windows RCP client has exhibited hanging behavior under some conditions. Other
third-party clients are available if this becomes a problem. The supplied RSH job scripts assume rsh.exe
and rcp.exe are in the users path, so they made need to be customized to use another RSH/RCP client
(see Job Script Customization (p. 35)).
Note
Before customizing job scripts, consult ANSYS Technical Support or your ANSYS Software
Distributor to check if new job scripts have been made available after release.
The RSH protocol is not officially supported at 13.0 and will be completely removed from
future releases. Windows Server 2008, Windows Vista, and Windows 7 do not include the
RSH client. It may be possible to use a third-party RSH client on these Windows versions with
some customization; however, PuTTY SSH is the recommended alternative.

When configuring RSM on a single machine used by multiple users to submit RSM jobs, follow these guidelines:
All RSM users should have write access to the RSM working directory. The default working directory
may not function properly if write permissions are not enabled for all applicable users.
All RSM users should cache their account password (refer to Caching an Account Password (p. 25)). If all
users do not cache their password, only the user that started RSM on the machine can submit jobs.
When installing RSM to a multi-user Linux machine, ANSYS strongly recommends that you set up RSM
as a daemon (refer to Starting RSM Manager and Compute Server Services Manually (p. 11)). Running RSM
13

as a daemon allows you to maintain consistent settings. If RSM is not run as daemon, the settings vary
depending on which user first starts RSM processes.
If you are running ANSYS Workbench on a multi-user RSM machine, My Computer, Background (see
Using Solve Process Settings in the Mechanical User's Guide) will likely not function as expected with
Rigid Dynamics or Explicit Dynamics due to write permissions for RSM working directories. As a workaround for this issue, follow these guidelines:
Ensure that RSM Manager and Compute Server (ScriptHost) processes always run under the same
user account. This will ensure consistent behavior.
Do not use the built-in My Computer or My Computer Background solve process settings.
Add a Remote Solve Process Setting that specifies that the Solution Manager name is the machine
name, rather than localhost. Refer to Using Solve Process Settings in the Mechanical User's Guide
for more information.
To run more than one job simultaneously, adjust the Max Running Jobs property in the Compute
Server Properties dialog box.

You must configure RSM Clients to work with RSM Managers and Compute Servers on remote computers.
If RSM services are run across multiple computers, refer to the following RSM configuration procedures:
2.2.4.1. Adding a Remote Connection to an RSM Manager
2.2.4.2. Adding a Remote Connection to a Compute Server
2.2.4.3. Configuring Computers with Multiple Network Interface Cards (NIC)
Note
When communicating with a remote computer, whether RSM Client to RSM Manager or RSM
Manager to Compute Server, RSM services must be installed on those computers.
2.2.4.1. Adding a Remote Connection to an RSM Manager

RSM Clients can monitor and configure multiple RSM Managers. The following steps describe how to add a
remote connection to an RSM Manager on a remote computer:
1.
Launch RSM.
2.
In the RSM main window select Tools > Options. The Options dialog box appears.
3.
In the Name field, enter the name of a remote machine with the RSM Manager service installed.
4.
Select the Add button and then OK. The RSM Manager and all of its queues and Compute Servers
appear in the Tree View.
5.
Passwords are cached on the RSM Manager machine, so you must set the password again. Refer to
Caching an Account Password (p. 25) for this procedure.
2.2.4.2. Adding a Remote Connection to a Compute Server

To use compute resources on a remote Compute Server, the RSM Manager machine must add a new Compute
Server as described in Adding a Compute Server (p. 30), and then configure remote Compute Server connections with the following considerations:
14
If the Compute Server is running Windows, only the machine name is required in the Friendly Name
field in the Compute Server Properties dialog box.
If the Compute Server involves integration with a Linux/UNIX machine or another job scheduler, refer
to Appendix A (p. 39) or Appendix B (p. 43) for integration details.
Ensure that you have administrative privileges to the working directory of the new Compute Server.
Always test the configuration of a connection to a new remote Compute Server after it has been created,
as described in Testing a Compute Server (p. 32).
2.2.4.3. Configuring Computers with Multiple Network Interface Cards (NIC)

RSM occasionally requires additional configuration to establish desired RSM Client-Compute Server communications with multi-NIC computers. This section describes RSM configuration for multi-NIC computers.
Compute Server Side Configuration
To configure a multi-NIC Compute Server:
1.
Locate Ans.Rsm.JMHost130.exe.config and Ans.Rsm.SHHost130.exe.config in Program

Files\Ansys Inc\V130\RSM\bin.
2.
Open both files in a text editor, and add machineName=ip_address to the TCP channel configuration as shown below, substituting a valid IP address for "ip_address". Do not change any other
information in the string.
...
<channels>
<channel ref="tcp" port="9012" secure="false" machineName="ip_address">
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full"/>
</serverProviders>
</channel>
</channels>
...
Note
To determine the correct IP address to use, use the ping utility at the command prompt
from a separate computer using the multi-NIC computers DNS name. For example:
C:\>ping multiNICmachine
Pinging multiNICmachine.mycompany.com [10.2.10.32] with 32 bytes of data:
Reply from 10.2.10.32: bytes=32 time=56ms TTL=61
In this example, the IP address 10.2.10.32 represents the network that RSM Clients have
identified.
3.
Save and close both files.
4.
Restart both the Ansys JobManager Service V13 and Ansys ScriptHost Service V13 services in the
Windows Services dialog box. To launch the Windows Services dialog box, Windows XP users can
open this dialog box by selecting Control Panel > Administrative Tools > Services. Windows 7 and
Vista users can open the dialog box by selecting Control Panel > System and Security > Administrative Tools > Services. To restart these services, right-click on the desired service, then select Restart.
RSM Client Side Configuration

If the Compute Server side configuration does not resolve an RSM Client-Compute Server communication
difficulties, it is possible that the RSM Client has multiple NICs and requires additional configuration. For
15

example, a virtual NIC used for a VPN connection on an RSM Client computer can cause a conflict even if
not connected.
To configure a multi-NIC RSM Client:
1.
Using a text editor, create a file named Ans.Rsm.ClientApi.dll.config in Program Files\Ansys

Inc\V130\RSM\bin. If this file does not exist, RSM uses a default configuration.
2.
Copy and paste the contents below into Ans.Rsm.ClientApi.dll.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="tcp" port="0" secure="true" machineName="ip_address">
<clientProviders>
<formatter ref="binary" typeFilterLevel="Full"/>
</clientProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
3.
Replace the contents of "ip_address" with a valid IP address.
4.
Save and close the file.
16
Chapter 3: User Interface

This chapter describes the following features of the RSM user interface:
3.1. Main Window
3.2. Menu Bar
3.3.Tree View
3.4. List View
3.5. Progress Pane
3.6. Options Dialog Box
3.7. Desktop Alert
3.8. Accounts Dialog Box
3.9. Windows RSM System Tray Icon and Context Menu
3.1. Main Window

To launch the RSM application main window:
Windows users select Start > All Programs > ANSYS 13.0 > Utilities > Remote Solve Manager
Linux users run the rsmadmin script.
The main window displays as shown below:
The RSM main window interface elements are described in the table that follows.
Interface Element
Description
Menu Bar
Provides access to the following menus: File, Options, View, Tools, and Help.
17

Interface Element
Description
Toolbar
Contains the following tools:
Show displays a list that filters jobs. Filter options include: All Jobs, Completed,
Running, Queued, and Failed.
Delete deletes a currently selected job or jobs. The function is the same as using
the Remove option of the List View context menu or the Delete key.
All Owner Jobs displays or hides jobs that belong to owners other than yourself.
The function is the same as using View > All Owner Jobs in the Menu Bar.
Progress Pane displays or hides the Progress Pane. The function is the same as
using View > Progress Pane in the Menu Bar.
Tree View
Displays configured queues and servers for one or more RSM Managers.
List View
Displays current jobs.You can delete jobs from this area.
Progress Pane
Displays the job progress and log messages.
Status Bar
Located at the bottom of the interface window, it contains two panes:
The Information Pane shows the status of the RSM application.
The Job Count Pane displays the number of jobs displayed in the List View.
3.2. Menu Bar

The Menu Bar provides the following functions:
Menu
Selections
Function
File
Close
Hides the main window. RSM continues to run in the tray. Right
click the system tray icon and select the Exit option in the
Context Menu to exit RSM.
Options
Always On Top
Main window remains in front of all other windows unless

minimized.
Hide When Minimized
If checked, RSM will not appear in the task bar when minimized;
it only appears as a tray icon (Windows only).
All Owner Jobs
Displays or hides jobs that belong to owners other than yourself

(if checked, shows your jobs and other owners, otherwise displays only jobs that you own).
Progress Pane
Displays or hides the Progress Pane.
Refresh Now
Forces the List View to update immediately, regardless of the

update speed setting.
Update Speed
Provides the following submenu selections:
View
18
High - updates the display automatically every 2 seconds.
Normal - updates the display automatically every 4

seconds.
Low - updates the display automatically every 8 seconds.
Paused - the display does not automatically update.
3.3.Tree View
Menu
Selections
Function
Tools
Desktop Alert
Enables/disables the Desktop Alert window.
Remove
Deletes the selected job or jobs.
Submit a Job
Displays the manual job submit dialog box.
Options
Displays the Solve Manager options dialog box.
ANSYS Remote Solve

Manager Help
Displays the Help system in the ANSYS Help Viewer.
About ANSYS Remote

Solve Manager
Provides information about the program.
Help
3.3. Tree View

The Tree View contains a list of Compute Servers, queues, and RSM Managers. Compute Servers and queues
that display may be set up on either your local machine (shown as My Computer) or a remotely on an RSM
Manager. You can set passwords and configure queues and servers via the context (right-click) menus of
the tree nodes. All of these tasks are explained in detail in Administration (p. 29).
When an RSM Manager node is selected, Properties, Accounts..., and Set Password options are available
in the context menu.
When a Queues node is selected, only the Add... option is available in the context menu.
When a queue is selected, the Properties... and Delete... options are available in the context menu.
19
When a Compute Server is selected under a Queues node or under a Compute Servers node, the Properties...
and Test Server... options are available. The Delete... option (not shown) becomes available if a Compute
Server that is not assigned to any queue is selected under a Compute Servers node.
When a Compute Servers node is selected, only the Add... option is available.
For more information on using the Tree View context menu options, see Administration (p. 29).
3.4. List View

You can sort the displayed fields by selecting the appropriate column. You can delete jobs that belong to
you by selecting the Delete button in the toolbar, by selecting Remove in the context menu, or by pressing
the delete key. You can also select and delete multiple jobs in the List View by performing these actions.
20

If you delete a job, the job may not be removed from the List View immediately, but it disappears the next
time the List View is refreshed.
Note
If a job is running you cannot remove it. Use the Cancel option in the List View context menu,
then wait for the job to complete. Sending a cancel command to a job allows it to cleanup processes spawned by the job. There may also be a job stopping option in the client application that
submitted the job (for example, ANSYS Workbench Mechanical Stop Solution command).
The List View context menu provides the following options:
Inquire
Inquire about a running job. This action depends on the type of job being run. Generally, the Inquire
command will run some additional job script code to perform some action on a running job. It can also
bring back intermediate output and progress files.
Cancel
Cancel a running job. The job script implements cancel code to cleanup spawned process and perform
any necessary cleanup.
Remove
Deletes the selected job or jobs.
Set Priority
When jobs are submitted they have a default priority of Normal. To change the priority of a Queued
job, right-click on the job name, choose Set Priority, and change the priority. The higher priority jobs
in a queue run first. Changing the priority of a job that is in any state except Queued has no effect. Only
RSM administrators can change a job priority to the highest level.
Bottom Option
Allows job add-ins to provide specific functionality for that type of job (if available). A job add-in may
display specific information about the running job, such as an output file (Inquire may be required to
update the file). The add-in functionality allows for more detailed information about a job without running
the RSM Client software that submitted the job. The add-in can also be used on a different computer
than where the job was originally submitted.
3.5. Progress Pane

The Progress Pane provides log messages about the job. You can copy the log messages using the context
menu or the copy (Ctrl+C) key combination. The log automatically scrolls to keep the most recent messages
in view. To stop automatic scrolling, select one or more lines in the log. To resume automatic scrolling
Ctrl-select the selected line(s) so that no lines are selected.
Note
When making a support call concerning RSM functionality, the complete contents of the Progress
Pane should be sent.

From the Menu Bar, select Tools > Options to open Options dialog box. the Use the Options dialog box
to configure RSM Managers or set up desktop alert settings.
21
The Options dialog box contains the following
Solve Managers - Lists available RSM Manager machines. You can Add or Delete RSM Managers, or
Change machine names in the list.
Desktop Alert Settings - Contains check boxes to configure the following desktop alerts:
Show Running Jobs
Show Pending Jobs
Show Completed Jobs
3.7. Desktop Alert

The Desktop Alert automatically appears when jobs are active. It displays the running, queued, and completed
jobs. The number of queued, running and completed jobs is also displayed in the window title. Tool tips
are available on the individual jobs that show the full name of the job. If all jobs are finished, the Desktop
Alert disappears automatically. If you wish to hide the Desktop Alert, use the menu options or tray context
(right-click on the RSM Tray Icon) menu to turn it off. If you close the Desktop Alert, it will not remain hidden
permanently. The Desktop Alert (as shown below) will display again as long as jobs are active unless the
alert is turned off. Hide finished jobs using the Options dialog box or the tray context menu.
3.8. Accounts Dialog Box

Right-click on the RSM Manager node in the Tree View and select Accounts to open the Accounts dialog
box. Alternate accounts are added when the password is set using the password application (see User Accounts
and Passwords (p. 25)). After adding the alternate account(s), use the Accounts dialog box to specify the
Compute Server(s) where that account should be used. You can also right-click on an account and select
Remove to remove that account.
22

The RSM system tray icon loads in the Windows system tray by default. Double-click on the system tray icon
( ) to open the RSM user interface. The system tray icon changes based on the status of jobs (for example,
no jobs running, at least one job is running, at least one job has failed). A tool tip is available on the tray
icon to display the current status of jobs.
The RSM system tray icon context menu is a duplication of most options available via the main menu. Rightclick the RSM system tray icon to open this menu as displayed below:
Menu Option
Description
Options
Displays the Options dialog box.
Help
Displays the Help system in another browser window.
About
Provides information about the program.
All Owner Jobs
Displays or hides jobs that belong to other owners.
Desktop Alert
Enables/disables the Desktop Alert window (see Desktop Alert).
Open Job Status
Displays the RSM main window.
Exit
Exits the RSM application.
23
24
Chapter 4: User Accounts and Passwords

The following topics are discussed in this section.
4.1. Caching an Account Password
4.2. Manually Running the Password Application
4.3. Adding Alternate Accounts
4.4. Configuring UNIX/Linux Accounts When Using RSH/SSH
4.1. Caching an Account Password

If an RSM Client is sending jobs to an RSM Manager running on a remote machine, the RSM Client must
cache its password with that RSM Manager.
If an RSM Client's account password has not been cached with an RSM Manager, [Set Password] will appear
next to the RSM Manager in the Tree View. This message will not appear if the RSM Client and Manager
operate on different platforms.
RSM caches account passwords so that it can run jobs on a Compute Server on behalf of the user. The
passwords are encrypted and stored by the RSM Manager. Each RSM Manager has a list of registered accounts.
Any time a password changes, it must be updated in RSM.
Note
It is not necessary to cache your password with the RSM Manager if you are using RSM only for
local background jobs. Additional configuration may be required to use remote compute resources.
To cache an account password:
1.
In the Tree View, right-click on the RSM Manager and select Set Password. In a Windows environment,
this opens a command window. In a Linux environment, the password application runs in the terminal
where the RSM user interface was started. If the RSM user interface was not started in a terminal, you
can run the password application manually (see Manually Running the Password Application (p. 25)).
2.
Press Enter at the username prompt to set the password for the currently logged-in user.
3.
Type the password and confirm.
4.
Press any key to exit the command window.
4.2. Manually Running the Password Application

It is usually unnecessary to manually run the password application; however, you may find it useful in certain
circumstances. For example, it may be necessary to manually run the password application on a Linux machine
if the terminal used to start the RSM user interface is not available. The password application is run in the
original terminal used to start the RSM user interface, and it if it is closed, the output and prompts will not
be visible.
25
Chapter 4: User Accounts and Passwords

Additionally, there is a known issue at 13.0 on UNIX/Linux systems, where the SetPassword command can
cause RSM to hang or crash if rsmadmin is running in the background. You can manually run the password
application as a workaround for this problem.
In both instances, a simpler alternative would be to stop and restart the RSM interface. The instructions
provided in this section are included in the event that a general solution is desired.
The password application is named Ans.Rsm.Password.exe and is located in the [RSMInstall]\bin
directory. On Windows, you run the password application directly. On Linux, you must run the password
application using the Mono runtime (installed with the ANSYS Workbench Framework). An example script
named rsmpassword is located in [RSMInstall]/Config/tools/linux. You must edit this script
to specify the ANSYS Workbench Framework path and platform.
Running the password application with no arguments shows the usage as follows:
Usage: Ans.Rsm.Password.exe [-m manager][-a account][-o owner][-p password]
-m manager: RSM Manager machine (default = localhost).
-a account: Target account. If no -o owner, this is a primary account.
-o owner:
Account owner. Setting password for an alternate account
specified with -a.
-p password: Account password.
-? or -h:
Show usage.
NOTES: If no -a or -p, this is normal interactive mode.
Accounts can be entered as username or DOMAIN\username.
4.3. Adding Alternate Accounts

Alternate accounts allow an RSM Client user to run jobs under alternate accounts on a specific Compute
Server. Alternate accounts may be necessary if you are attempting run a job on a remote machine that is
unable to recognize the client account name. For example, an RSM Client running Windows with the account
name ANSYS\johnd would need an alternate account to run jobs on a Linux machine acting as a Compute
Server, because the Linux machine would be unable to recognize this account name.
The owner account is considered to be the account communicating with RSM. This is typically the account
used with the client application (e.g., ANSYS Workbench). Alternate accounts are added to the owner account.
In the example below, ANSYS\johnd is the owner account and johndoe is an alternate account to be used
on a Compute Server specified in the Accounts dialog box.
Setting password for primary (default), alternate or new alternate account.
Existing alternate accounts:
johndoe
Enter user name (ANSYS\johnd):johndoe
Enter password for ANSYS\johnd: ********
Re-enter password: ********
Password set for johndoe:
Your password has been encrypted and stored.
It can only be decrypted and used to run jobs on behalf of ANSYS\johnd.

If the Windows and UNIX account names are the same (for example, DOMAIN\johnd on Windows and johnd
on UNIX) then no additional configuration is required. If the account name is different, specify the account
in the Compute Server properties proxy section. Client applications may also have a mechanism to specify
an alternate account name. For example, you can specify a UNIX account in the ANSYS Workbench Solve
Process Settings Advanced dialog box. Remember that RSH/SSH must be configured for password-less
access (see Appendix E (p. 51)). RSM does not store UNIX passwords for use with RSH/SSH.
26
Note
The RSH protocol is not officially supported at 13.0 and will be completely removed from future
releases. Windows Server 2008, Windows Vista, and Windows 7 do not include the RSH client. It
may be possible to use a third-party RSH client on these Windows versions with some customization, however, PuTTY SSH is the recommended alternate.
27
28
Chapter 5: Administration
Users with RSM administrator privileges can perform a variety of additional tasks. For instance, RSM administrators can create and modify RSM Managers and Compute Servers, manage queues, set jobs to highest
priority, and delete jobs of any user.
RSM administrators must fulfill one of the following requirements:
RSM administrator is a Windows administrator on the RSM Manager machine (they are in the local or
domain administrators group).
RSM administrator has been made a member of the RSM Admins group on the RSM Manager machine.
In this case, the RSM services (ANSYS JobManager Service V13 and ANSYS ScriptHost Service V13)
may need to be restarted for administrator privileges to take effect.
The following RSM administration tasks are discussed in this section:

5.1. Creating a Queue
5.2. Modifying RSM Manager Properties
5.3. Adding a Compute Server
5.4.Testing a Compute Server
5.1. Creating a Queue

A queue is a list of Compute Servers available to run jobs. To create a queue:
1.
In the Tree View, right-click on the Queues node for a desired RSM Manager.
2.
Select Add. The Queue Properties dialog box appears:
3.
Configure the Queue Properties described below, then select OK.
Queue Properties:
Name
This field should contain a descriptive name for the queue. Examples of queue names include
Local Queue, Linux Servers, or HPC Cluster. If the Compute Server(s) in the queue has a
Start/End Time specified you may want to use a name that indicates this to users (e.g., "Night Time
Only").
29
Enabled
If True, the RSM Manager dispatches queued jobs to available Compute Servers. If False, jobs remain
in a "Queued" state until the queue is enabled.
Priority
This value can be Low, Below Normal, Normal, Above Normal, or High. When determining the
next job to run, the RSM Manager pulls jobs from the highest priority queue first. Priority settings
are commonly used to create a separate, higher priority queue for smaller jobs, so that they are
processed before running large jobs that tie up the computing resource for a long period of time.
Assigned Servers
Check the Compute Servers that are used in this queue. A queue can contain more than one
Compute Server. A Compute Server can also be a member of more than one queue.
5.2. Modifying RSM Manager Properties

To modify RSM Manager Properties:
1.
In the Tree View, right-click on an RSM Manager node.
2.
Select Properties. The Solve Manager Properties dialog box appears:
3.
Modify Solve Manager Properties described below, and then select OK.
Solve Manager Properties:

Job Cleanup Period
The time in HH:MM:SS format (hours:minutes:seconds) that the job remains in the list after its status
is "Released".
Project Directory
The base location where the RSM Manager stores input and output files for a job. A unique subdirectory is created for each job. This location can be on the local disk of the RSM Manager computer
or it could be a network share (for example, \\fileserver\RSMProjects).
Compression Threshold (MB)
The threshold at which files are compressed prior to transfer. There is always a trade-off between
the time it takes to compress/decompress versus the time to transfer. The appropriate value depends
on the specific network environment. Enter a value of 0 to disable compression.

To add a Compute Server:
1.
In the Tree View, right-click on the Compute Servers node for the desired Compute Server.
2.
Select Add. The Compute Server Properties dialog box appears:
30
3.
Configure Compute Server Properties described below, then select OK. Optionally, you can test a
Compute Server after it has been created.
Compute Server Properties:
1. General
Friendly Name
Any descriptive name for the Compute Server. This is intended as an easy-to-remember
alternative to the Machine Name. Examples of friendly names include Bobs Computer,
or My Computer to Linux Proxy.
The Friendly Name is initialized to Server (date time) to guarantee its uniqueness.
Machine Name
The name of a computer that has RSM and the client application installed. Use "localhost"
for the local machine or the network machine name to identify a remote machine.
Enabled
If True, this Compute Server can accept jobs.
Working Directory
The directory on the Compute Server where the job is run. Job scripts, input files, and
output files are located in this directory. If blank, the system temporary directory is used,
which is defined by the TMP environment variable. RSM users must have write access and
full permissions to this directory.
Logging Enabled
If True, a log file is created in the Working Directory on the RSM Manager machine. The
file name has the form RSM_machine.log.
Max Running Jobs
The maximum number of simultaneous jobs this Compute Server is allowed to run. This is
required to prevent collisions, which can occur because RSM cannot detect the number of
cores on a machine. In previous versions, to run multiple jobs on one Compute Server it
was necessary to create duplicate servers differing only in name and add them to the same
queue. This is no longer necessary. This is especially useful when the job is simply forwarding
the work to a proxy job scheduler (for example, LSF, PBS).
31
Important
Max Running Jobs applies to only the current instance of RSM. If more than
one version (e.g., 11.0, 12.1, etc.) of RSM is used to submit jobs, collisions between
jobs can occur. RSM cannot detect jobs being assigned to a Compute Server by
differing versions of RSM.
Start Time
Time (in 24-hour HH:MM:SS format) at which the Compute Server can accept jobs. Use
00:00:00 for both Start Time and End Time for 24 hour availability. Start Time is very
useful if a Compute Server or application licenses are only available at certain times of the
day.
End Time
Time (in 24-hour HH:MM:SS format) at which time the Compute Server stops accepting
jobs. Jobs already running at the end time continue to run. Use 00:00:00 for both Start
Time and End Time for 24 hour availability.
2. Compute Proxy
Keyword
Keywords invoke customized job scripts. For example, the standard code template for an
ANSYS Solver job is AnsysCode.xml. If the keyword RSH is entered, the code template
AnsysCode_RSH.xml is used, which contains a different set of code files designed to
communicate with another computer using the RSH/RCP protocol. The remaining proxy
settings are used exclusively by the custom job script.
Machine Name
Use this proxy setting to specify a non-Windows compute proxy machine. This value is accessed with the Task.ProxyMachine property in the job script. Custom job scripts can
use this setting for any purpose.
Account Name
Use this proxy setting to specify an account name on a non-Windows compute proxy machine. This value is accessed with the Task.ProxyAccount property in the job script.
Custom job scripts can use this setting for any purpose. A blank entry is allowed.
Working Directory
Use this proxy setting to specify a working directory on the non-Windows compute proxy
machine. This value is accessed with the Task.ProxyPath property in the job script.
Custom job scripts can use this setting for any purpose. A blank entry is allowed.
Custom 1
Use this reserved field to send parameters to a customized job script. The value is accessed
with the Task.Custom1 property.
Custom 2
Use this reserved field to send parameters to a customized job script. The value is accessed
with the Task.Custom2 property.
5.4. Testing a Compute Server

To test a Compute Server configuration, right-click on the Compute Servers node in the Tree View and
select Test Server. This runs a test job using the settings provided. The Progress Pane displays a log message
that shows if the test finished or failed. If the test finishes, you can successfully run jobs on the Compute
Server.
32
5.4.Testing a Compute Server
Note
If you do not have full permissions to the Compute Server working directory, Compute Server
tests will fail.
33
34
Chapter 6: Job Script Customization

Before embarking on job script customization, consult ANSYS Technical Support or your ANSYS Software
Distributor to check if new job scripts have been made available.
The following RSM job script customization topics are detailed in this section:
6.1. Customizing an Existing Job
6.2. Manually Submitting Jobs
6.1. Customizing an Existing Job

Job templates, code templates, and code for the Mechanical application are included with the RSM installation
and located in:
[RSMInstallDir]\RSM\Config\xml and \scripts
Visual Studio projects are supplied in the scripts folder to aid in editing.
The job script files are delivered in the C# language. Theoretically, it is possible to use other .NET-supported
languages (for example, Visual Basic, Jscript), but this has not been officially tested. C++ may also be supported
in future release.
Keywords
Keywords are used to invoke specialized scripts to integrate with non-native operating systems (for example,
UNIX, Linux) and third-party job schedulers (for example, LSF, Microsoft HPC). The keyword is appended to
the base job code template name. For example, if the code template is named ServerTestCode.xml
and the keyword is LSF, RSM will first look for ServerTestCode_LSF.xml. Keywords are the best way
to invoke custom scripts without affecting the existing jobs.
Job Templates
Job templates define the code template, inputs, and outputs of a job. Job template files are located in
[RSMInstallDirectory]\Config\xml on the RSM Manager machine.
The job template for a server test job is shown below:
<?xml version="1.0" ?>
<JobTemplate>
<script>ServerTestCode.xml</script>
<debug>TRUE</debug>
<cleanup>TRUE</cleanup>
<inputs>
<file type="ascii">*.in</file>
</inputs>
<outputs>
<file type="ascii">*.out</file>
</outputs>
</JobTemplate>
35
Chapter 6: Job Script Customization
Code Templates
Code templates contain sections for the actual code files, referenced assemblies (.dlls), and support files
(such as localized strings). These files are transferred to the Compute Server and processed by the
ScriptHostService on that computer. Code templates are located in [RSMInstallDirectory]\Config\xml on the RSM Manager machine.
A code template for a server test job is shown below:
<?xml version="1.0" ?>
<codeDefinition>
<codeFiles>
<codeFile>ServerTest.cs</codeFile>
</codeFiles>
<references/>
<supportFiles/>
</codeDefinition>
6.2. Manually Submitting Jobs

To manually submit jobs, select an RSM Manager to submit the job to in the Tree View, then select Tools
> Submit a Job. The Submit Job dialog box appears as shown:
The following items are required to manually submit a job:

Queue
This drop down list is pre-loaded with all the queues currently defined for the selected RSM Manager.
Template
The job template file path relative to the RSM Manager machine. If an RSM Manager is being used on a
remote machine, a customized job template will have to be copied to that machine into a known location.
In the case of an RSM Manager on a remote machine, the Browse option is meaningless.
Working Directory
The directory where the job input files are located.
36
Chapter 7: Integration with ANSYS Client Applications

This section discusses RSM compatibility and integration topics related to ANSYS client applications.
For client application-specific RSM instruction, integration, or configuration details, refer to the following
resources:
Submitting Solutions for Local, Background, and Remote Solve Manager (RSM) Processes in the Workbench
User's Guide
RSM specific tutorials featuring step-by-step instructions for specific configuration scenarios on the
Download Center at https://www1.ansys.com/customer/
The client application documentation
The following topics are discussed in this section.

7.1. RSM Supported Solvers
7.2. RSM Integration with Workbench
7.1. RSM Supported Solvers

RSM supports the following solvers:
Mechanical (excluding the SAMCEF solver)
Mechanical APDL
CFX
FLUENT
Polyflow
7.2. RSM Integration with Workbench

Many ANSYS Workbench applications enable you to use RSM; however, the following considerations may
apply:
Some applications may not always work with remote Compute Servers or RSM Managers.
When a client application is restricted to the RSM Client machine, RSM enables the client application
to run in the background.
When a client application can send jobs to remote Compute Servers, the job may be run completely
on one Compute Server, or the job may be broken into pieces so that each piece can run in parallel on
multiple Compute Servers (possibly including the RSM Client machine). In the case where a job is being
run in parallel on multiple machines, you need to ensure that the software that controls the parallel
processing is supported on all of the Compute Servers.
37
38
Appendix A. Integrating Windows with UNIX/Linux using SSH/SCP

RSM supports using SSH/SCP (secure shell, secure copy) in custom job scripts. The built-in job scripts for the
ANSYS Solver have been tested using the PuTTY SSH client (http://www.chiark.greenend.org.uk/~sgtatham/putty).
PuTTY SSH Configuration

To send RSM jobs to a remote UNIX/Linux machine using SSH, you must configure SSH to allow access from
a Windows machine. SSH configuration involves creating a cryptographic key on the Windows RSM Manager
machine, and placing public portions of the key on the UNIX/Linux machine. The following steps describe
how to set up and configure PuTTY SSH:
1.
Download and install PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

If this link is invalid, perform a web search for "putty".
2.
Create a cryptographic key:
3.
a.
Run PuTTYGen (puttygen.exe). The Putty Key Generator dialog box appears.
b.
Select Generate.
c.
Follow the on-screen instructions.
d.
Change the key comment to include your machine name and Windows username.
e.
Save the private key file without passphrase, for example, <drive>:\Program
Files\Putty\id_rsa.ppk. Using a pass phrase results in jobs being hung at a prompt to
enter the pass phrase. Be sure to secure the private key file using some other means. For example,
if the key is only being used by you, save it to the My Documents folder where only you and administrators have access to the file. If multiple users share the same key, allow the owner full
control, then create a group and allow only users in that group to read this file.
f.
Move the public portion of the key to the UNIX machine. This requires you to edit the
~/.ssh/authorized_keys file on the UNIX machine. Edit the file in a telnet session on the
Windows machine. Copy all the text from the box under "Public key for pasting" and paste it
into ~/.ssh/authorized_keys. All of this text should be one line. If the authorized_keys
file does not exist, create one. Alternately, paste it into a text file and move that file to the UNIX
machine for editing.
g.
Modify permissions to allow read and execute by running chmod 600 .ssh/authorize_keys.
Modify system environment variables:

a.
Open the Windows System Properties dialog box. Windows XP users select Control Panel >
System. Windows Vista and Windows 7 users select Control Panel > System and Security >
System > Advanced.
b.
In the Advanced tab, select Environment Variables. The Environment Variables dialog box
appears.
c.
In the Environment Variables dialog box, locate the Path variable in the System variables pane.
39
4.
d.
Select the Path variable then click the Edit button. The Edit System Variable dialog box appears.
e.
Add the PuTTY install directory to the Variable value field (for example, C:\Program Files\putty),
then click OK.
f.
In the Environment Variables dialog box, click the New button. The New System Variable dialog
box appears.
g.
In the New System Variable dialog box, create a new environment variable named KEYPATH
with a value containing the full path to the private key file (for example, <drive>:\Program
Files\Putty\id_rsa.ppk). Use a user variable if the key file is used only by you. Use a system
variable if other users are sharing the key file. For example, if a Windows XP user has a key file in
My Documents, the variable value should be %USERPROFILE%\My Documents\id_rsa.ppk
(this expands to <drive>:\Documents and Settings\<user>\My Documents\id_rsa.ppk).
h.
Click OK.
i.
Reboot the computer for environment changes to take effect.
Test the configuration by running the following from the command prompt (quotes around %KEYPATH%
are required):
plink -i %KEYPATH% unixlogin@unixmachinename pwd
5.
40
a.
If plink prompts you to store the key in cache, select Yes.
b.
If plink prompts you to trust the key, select Yes.
Add a new Compute Server in RSM using the Keyword "PSSH" as shown below. Refer to Adding a
Compute Server (p. 30) for more information.
6.
On the Linux Compute Server machine, ensure that the ANSYS Product environment variable
AWP_ROOT130 is set to the location of your ANSYS product installation. This is done by adding the
environment variable definition to your .cshrc resource file.
7.
Use Test Server to verify the configuration.
41
42
Appendix B. Integrating Windows with UNIX/Linux using RSH/RCP

RSM supports the use of RSH/RCP (remote shell/remote copy) in custom job scripts. The built-in job scripts
for the ANSYS Solver have been tested using the RSH client (rsh.exe) provided by Windows.
Note
The RSH protocol is not officially supported at 13.0 and will be completely removed from future
releases. Windows Server 2008, Windows Vista, and Windows 7 do not include the RSH client. It
may be possible to use a third-party RSH client on these Windows versions with some customization; however, PuTTY SSH is the recommended alternate.
RSH Configuration
In order to send jobs to a remote UNIX/Linux machine using RSH, RSH must be configured to allow access
from a specific user and a specific machine. Edit the .rhosts file in the home directory of the UNIX/Linux
account where the job runs to allow access. The entry is of the form:
windows_machine_name windows_username
or
windows_machine_IP windows_username
For example, if the Windows domain account is COMPANY\johnd and the Windows Compute Server is
named jdoexp06, the .rhosts entry would be:
jdoexp06 johnd
43
Appendix B. Integrating Windows with UNIX/Linux using RSH/RCP

In some network environments it is necessary to use the fully qualified name of the Windows computer:
jdoexp06.company.com johnd
Along with the Test Server feature, use the troubleshooting commands below to verify the RSH configuration.
These commands are executed at the Windows command prompt on the RSM Manager that communicates
directly with the UNIX/Linux Compute Server.
1.
If Windows and UNIX/Linux account names match, the following command lists the home directory
on the remote machine:
C:\>rsh unixmachine ls -l
2.
If the Windows and UNIX/Linux account names are different, the following command lists the home
directory of unixaccount on the remote machine:
C:\>rsh unixmachine -l unixaccount ls -l
44
Appendix C. Integrating Windows with Platform LSF Cluster

To integrate RSM with a Windows-based LSF cluster, RSM must be installed on at least one node of the
cluster, and that node must be an LSF submission host ( that is, bsub and lsrcp [requires RES service] commands must be available). Add a Compute Server as shown below, where lsfClusterNode1 is the name of
the node on which RSM is installed. If this machine is also the RSM Manager, replace lsfClusterNode1 in
the Machine Name field with "localhost".
The Working Directory and Proxy Working Directory values are the same physical location. The network
share representation is the staging area for job inputs and outputs and is accessed from the LSF execution
host. This directory and share must exist on all nodes. In this example, there must be a D:\RSMTemp
and share \\nodename\RSMTemp on all nodes.
The RSM job script submits the job to LSF with the following bsub command. This code is located in the
file RSMInstallDir\RSM\Config\scripts\LSFUtilties.cs.
bsub q queue n numCPUs o stdout.out e stderr.out cscript.exe //nologo LSF_Job.js control.txt
The number of CPUs is dependent on the specific job. For example, for the ANSYS Solver, the number of
CPUs is parsed from the command line coming from ANSYS Workbench. The LSF job is a JScript named
LSF_Job.js located in RSMInstallDir\RSM\Config\scripts. This script does the following:
1.
Reads the control file containing paths, inputs and outputs.
2.
Makes temporary directories on all nodes assigned for the job.
3.
Copies inputs to the working directory of the execution host.
4.
Runs the command (for example, solver).
5.
Copies outputs to the staging folder on the submission host.
6.
Cleans up.
45
Appendix C. Integrating Windows with Platform LSF Cluster
Note
For a server test (RSMInstallDir\RSM\Config\scripts\TestServer_LSF.cs), the
queue is hard-coded to normal and the number of CPUs is set to 2. Edit this file if these default
settings are not appropriate.
To complete the configuration, create a new queue and add the Compute Server to it. The RSM queue
name must match the LSF queue name exactly. Jobs can now be submitted to this queue and then forwarded to the LSF queue for scheduling.
You can set the Max Running Jobs property to the value appropriate to your cluster. Note that the RSM
job could be in a Running state, but LSF may not yet be able to execute the job due to limited resources.
Refer to the Progress Pane to determine LSF job ID and state.
46
Appendix D. Integrating with Microsoft HPC

To integrate with Microsoft HPC, RSM must be installed on the head node. This allows you to use the RSM
Manager and Compute Server (also known as ScriptHost) services, or just use the Compute Server service.
If the latter is chosen, the RSM Manager runs on the RSM Client machine, or on a central, dedicated RSM
Manager machine.
Add a Compute Server as shown below, where msccHeadNode is the name of the cluster head node. If
you are using the RSM Manager on the head node, replace this with "localhost". The Working Directory and
Proxy Working Directory values are the same physical location. The network share representation is the
staging area for job inputs and outputs, and it is accessed from the node where Microsoft HPC chooses to
run the job. This directory and share must exist on all nodes. In this example, there must be a D:\RSMTemp
and share \\nodename\RSMTemp on all nodes.
The Microsoft HPC job is actually a JScript named MSCC_Job.js located in RSMInstallDir\RSM\Config\scripts. This script does the following:
1.
Reads a control file containing paths, inputs, and outputs.
2.
Makes temporary directories on all nodes assigned for the job.
3.
Copies inputs to the working directory of the execution host.
4.
Runs the command (for example, solver).
5.
Copies the outputs to the staging folder on the submission host.
6.
Cleans up.
Now create a new queue and add this Compute Server to it. Jobs can now be submitted to this queue and
then forwarded to the Microsoft HPC for scheduling.
The number of CPUs/nodes allocated by Microsoft HPC is controlled by the job script implementation. For
example, the Mechanical application contains a Max number of utilized processors setting that is passed
along on the solver command line. The command line is parsed in the job script and this information is
passed on to Microsoft HPC. The number of CPU requests is reported in the Progress Pane.
47
Passwords
RSM no longer requires users to manually cache their Windows password with Microsoft HPC. Each RSM job
runs the hpcutils.exe tool prior to submitting the job to the cluster. This tool programmatically does
the equivalent of cluscfg setcreds.
Mixed Domains
You can use RSM when the client computer and the cluster are different domains. The assumption is that
the client computer and user account are on the corporate domain and the cluster is its own domain. In
this case, the cluster domain must be configured to have a one-way trust with the corporate domain. That
is, the cluster domain trusts the corporate domain but not vice-versa. Corporate domain users must be able
to use cluster resources (login as CORPORATE\user into a cluster node). If the cluster administrator can add
corporate domain accounts as cluster users, then this trust has likely been configured when the cluster domain
was created.
Multiple Network Interface Cards

Cluster nodes, especially the head node, generally have multiple network interface cards (NIC) to facilitate
separate public and private networks. When configuring the network topology for Microsoft HPC with RSM,
be sure to select either Compute nodes isolated on a private network or "Compute nodes isolated on
private and application networks. Otherwise, client-server communication difficulties may arise and additional manual configuration will be required. Refer to Configuring Computers with Multiple Network Interface
Cards (NIC) (p. 15) for configuration instructions.
Network Path Configuration

If the RSM working directory or ANSYS software installation is referenced using a UNC path specification
(e.g. \\nodename\path), please refer to the Network Installation and Product Configuration for special considerations related to network drives. Note that both the working directory and ANSYS software installation
must be have Full Trust set on all compute nodes.
48
Troubleshooting
If RSM jobs submitted to a Microsoft HPC cluster are failing for unknown reasons, you can gain additional
diagnostic information by running the HPC Job Manager (supplied as part of the Microsoft HPC Pack), selecting
the failed job, and examining the output section of the jobs tasks.
Depending on the installed version of Microsoft HPC, registry modification may be required to enable the
execution of commands via UNC paths. Special configuration is required if the task shows the following error:
UNC paths are not supported. Defaulting to Windows directory.
Input Error: Can not find script file "C:\Windows\MSCC_job.js".
To resolve this issue, create a text file of the following contents and save to a file (e.g. commandpromptUNC.reg)
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"CompletionChar"=dword:00000009
"DefaultColor"=dword:00000000
"EnableExtensions"=dword:00000001
"DisableUNCCheck"=dword:00000001
Next, run the following command on the head node and all compute nodes in the cluster:
regedit -s commandpromptUNC.reg
The task of executing this on the compute nodes may be automated using the clusrun utility that is part
of the Microsoft HPC Pack installation.
49
50
Appendix E. Integrating UNIX/Linux with LSF and PBS Clusters

To integrate RSM with LSF and PBS clusters on Linux, first establish RSH or SSH connectivity to one node of
the cluster. Refer to Appendix A (p. 39) for instructions on how to configure client and cluster nodes for
password-less access. The selected cluster node must be an LSF submission host (that is, the BSUB command
must be available).
An example of RSM Compute Server properties are shown in the screen shot below. In this example, the
machine name in the top section is localhost because the RSM Manager and Compute Server are running
on the same machine (that is, the Compute Server is local with respect to the RSM Manager). Max Running
Jobs should be set to the maximum number of jobs that should be submitted to the cluster before queuing
jobs in RSM.
The Compute Proxy settings in this example control the integration as follows:
Keyword
Currently supported keywords are LSFSSH, LSFRSH (LSF cluster via SSH and RSH, respectively), PBSSSH,
and PBSRSH (PBS cluster via SSH and RSH, respectively). Additional third-party job schedulers may be
integrated in the future.
Machine Name
A cluster node previously configured for password-less access via SSH or RSH.
Working Directory
The file-staging path. The RSM job creates a temporary directory here (for example, /staging/dh3h543j.djn). Mount this directory on all execution hosts so that the LSF/PBS job has access.
Custom1
For this example, this field is being used to specify local scratch space on the execution nodes. This path
must exist on all nodes. The LSF/PBS job script creates temporary directories in this location on all assigned
nodes using the LSF/PBS job ID (for example, /scratch/Job1234).
51
Compute Server Testing

After the Compute Server is created, right-click Test Server in the server context menu to test the configuration.
Note
For a server test (...RSM\Config\scripts\TestServerUnixTP.cs), the queue is hardcoded to normal for LSF and workq for PBS. Also, the number of CPUs is set to 2. Edit this file
if these default settings are not appropriate.
Queue Creation
You must add the Compute Server to a new queue before submitting jobs from the client application (for
example, ANSYS Workbench). The name of the queue must match the name of the queue on the cluster.
RSM Job Script Customization (required)

An RSM job script ([RSMInstall]\Config\scripts\LSFUnixUtilities.cs or PBSUnixUtilities.cs) must be customized to enter the number of nodes and number of CPUs per node. This information
along with the number of CPUs requested is used to determine the job submission command (BSUB for
LSF or QSUB for PBS). The pertinent C# code in the script is shown below:
// CUSTOMIZE HERE: # of execution nodes available
// This variable will be modified below for the qsub select option
int numberClusterNodes = 3;
// CUSTOMIZE HERE: # of CPUs per node.
// If this varies use a value such that numberClusterNodes * numberCPUperNode
// doesn't exceed the actual CPUs available
int numberCPUperNode = 4;
General Details of the Integration

RSM essentially forwards the job to a third-party job scheduler. This RSM job must build and execute the
job submission command of the scheduler specified through the keyword. The RSM job does not really do
any real work; rather it monitors the status of the job it has submitted to LSF or PBS. Specific details for each
scheduler are discussed below.
The job sent to the Linux cluster is a shell script that performs the following tasks:
1.
Make a temporary directory in scratch directory and move there.
2.
Make temporary directories on other nodes assigned for the job.
3.
Copy inputs to the working directory of execution host.
4.
Run the command (for example, ANSYS Solver).
5.
Copy outputs back to the staging folder on the submission host.
6.
Clean up the temporary directories.
LSF Details
Shell scripts that are submitted to LSF are located in [RSMInstall]\Config\scripts. For a server test
the name is lsfjob_generic.sh. For an ANSYS Solver job the file is named lsfjob_ansys.sh. Any
52

additional solvers that are supported follow the same convention. These shell scripts are actually a generic
base portion that is appended to a dynamically generated top portion, resulting in a shell script for a specific
job (lsfJob.sh). The dynamic portion contains the variable values for the job, including the number of
processors requested, input file names, scratch location, etc.
The BSUB commands that follow are examples that you can chose in LSFUnixUtilities.cs. To use a
form of the command, remove the comment characters (//) from the beginning of the line. Only one line
should be used at a time. Customize the BSUB command as needed.
//string submitJobStr = string.Format("bsub -q {0} -n {1} -R \"span[hosts={2}]\"
-o stdout.out -e stderr.out ./lsfJob.sh", queue, numProcs, numberNodesRequested);
//string submitJobStr = string.Format("bsub -q {0} -n {1} -R \"span[ptile={2}]\"
-o stdout.out -e stderr.out ./lsfJob.sh", queue, numProcs, coresPerNode);
string submitJobStr = string.Format("bsub -q {0} -n {1} -o stdout.out -e stderr.out
./lsfJob.sh", queue, numProcs);
To monitor the job, the RSM job parses the output of the BJOBS command. Customize the default polling
frequency of 30 seconds in LSFUnixUtilities.cs.
PBS Details
Shell scripts that are submitted to PBS are located in [RSMInstall]\Config\scripts. For a server
test, the name is pbsJob_generic.sh. For an ANSYS Solver job, the file is named pbsJob_ansys.sh.
Any additional solvers that are supported follow the same convention. These shell scripts are actually a
generic base portion that is appended to a dynamically generated top portion resulting in a shell script for
a specific job (pbsJob.sh). The dynamic portion contains the variable values for the job, including number
of processors requested, input file names, scratch location, etc.
The following QSUB command is located in PBSUnixUtilities.cs. Customize the QSUB command as
needed.
string submitJobStr = string.Format("qsub -q {0}
-l select={1}:nCPUs={2}:mpiprocs={2}
-l place=scatter:excl -o stdout.out
-e stderr.out ./pbsJob.sh", queue, numberNodesRequested,
numProcs / numberNodesRequested);
To monitor the job, the RSM job parses the output of the QSTAT command. Customize the default polling
frequency of 30 seconds in PBSUnixUtilities.cs.
53
54
defining, 1
manually submitting jobs, 36
script customization, 35
job template, 35
Index
A
accounts, 2526
administration, 29
C
client application
defining, 1
file handling, 4
integration, 37
integration with Workbench, 37
supported solvers, 37
code template, 1, 35
Compute Proxy, 1, 4
Compute Server
adding a Compute Server, 30
Compute Server properties, 30
defining, 1
file handling, 4
remotely connecting to a Compute Server, 14
startup scripts, 11
testing, 32
configuring RSM, 8
Linux, 8
multi-user machines, 13
multiple network interface cards, 15
remote computing, 9, 14
starting Linux RSM services at boot time, 11
starting RSM services manually, 11
starting Windows RSM services at boot time, 8
startup scripts, 10
Windows, 8
Linux
configuration, 8
Explicit Dynamics systems, 13
installation, 7
native mode, 9
remote computing, 9
starting services at boot time, 11
startup scripts, 10
UNIX/Linux Path considerations, 13
LSF, 45, 51
M
mapped drives, 8
Microsoft HPC, 47
multi-user machines, 13
N
native mode, 9
Network File System, 4
O
overview, 1
P
passwords, 25
PBS Clusters, 51
EKM Servers, 11
Explicit Dynamics systems, 13
queue
creating, 29
defining, 1
file handling, 4
I
installing RSM, 7
prerequisites, 7
standalone installation, 7
uninstalling, 8
J
job
remote computing
configuration, 14
remotely connecting to a Compute Server, 14
remotely connecting to an RSM Manager, 14
RSH
integrating Windows with UNIX/Linux, 43
job limitations, 13
RSH/RCP configuration, 43
RSM Client
defining, 1
file handling, 4
55
Index
RSM Manager
defining, 1
file handling, 4
remotely connecting to an RSM Manager, 14
solve manager properties, 30
startup scripts, 11
RSM user interface
Accounts dialog box, 22
context menu, 23
Desktop Alert dialog box, 22
List View, 17, 20
main window, 17
Menu Bar, 1718
Options dialog box, 21
Progress Pane, 17, 21
Status Bar, 17
system tray icon, 23
Toolbar, 17
Tree View, 17, 19
S
SSH
integrating Windows with UNIX/Linux, 39
job limitations, 13
selecting a remote computing mode, 9
SSH/SCP configuration, 39
startup scripts, 10
Compute Server, 11
EKM Servers, 11
RSM Manager, 11
T
terminology, 1
U
UNIX/Linux Path considerations, 13
user interface, 17
W
Windows
configuration, 8
installation, 7
integration with Platform LSF Cluster, 45
integration with UNIX/Linux using RSH/RCP, 43
integration with UNIX/Linux using SSH/SCP, 39
starting services at boot time, 8
uninstallation, 8
workflows, 2
56

Ansys Remote Solve Manager v13

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ansys Remote Solve Manager v13

Uploaded by

Copyright:

Available Formats

ANSYS Remote Solve Manager (RSM)

ANSYS Release 13.0

Copyright and Trademark Information

U.S. Government Rights

ANSYS Remote Solve Manager (RSM)

1.1. RSM Roles and Terminology

1.2. Typical RSM Workflows

1.2.Typical RSM Workflows

1.3. File Handling

1.3. File Handling

Chapter 2: Installation and Configuration

2.1.1. Prerequisites for Installing RSM

2.1.2. Installing Standalone RSM Services on Linux

2.1.3. Installing Standalone RSM Services on Windows

Log into a Windows account with administrative privileges.

Chapter 2: Installation and Configuration

Open a command prompt in the [RSMInstallDir]\bin directory.

Run the command, AnsConfigRSM.exe mgr -svr

2.1.4. Uninstalling RSM Services on Windows

2.2.1. Configuring RSM on Windows

2.2.1.1. Starting RSM Services at Boot Time

2.2.1.2. Configuring RSM for Mapped Drives

2.2.2. Configuring RSM on Linux

2.2.2. Configuring RSM on Linux

2.2.2.1. UNIX/Linux Path Configuration Requirements

2.2.2.2. Configuring RSM to Use a Remote Computing Mode

Uses standard TCP/IP to communicate

Uses SSH service to execute commands and

Requires RSM to be installed and running on the Compute Server (see

Requires installation of SSH client (Putty

Data Transfer Efficiency

Most efficient data transfer for solution

Communication overhead slows solution

Supported on Windows & Linux only

Supported on all platforms

Chapter 2: Installation and Configuration

2.2.2.2.1. Configuring a Linux Machine to Use Native Mode

2.2.2.3. Using RSM Startup Scripts

2.2.2. Configuring RSM on Linux

2.2.2.4. Starting RSM Manager and Compute Server Services Manually

rsmmanager - Starts the RSM Manager service.

rsmserver - Starts the Compute Server service.

These scripts are located in RSMInstallDir/RSM/Config/tools/linux. If for some reason these

2.2.2.4.1. Starting the RSM Manager Manually

To stop the service:

2.2.2.4.2. Starting the Compute Server Manually

To stop the service:

2.2.2.4.3. Starting XmlRpcServer Manually (Required for EKM Servers Only)

To stop the service:

2.2.2.5. Starting RSM Services at Boot Time

Chapter 2: Installation and Configuration

Table 2.1 Automatic Startup Instructions

Remove any existing startup information for the same version.

Edit the file /etc/rc.d/rc.local and delete the RSM lines.

Issue the new startup instructions:

Remove any existing startup information for the same version.

Edit the file /etc/rc.d/boot.local and delete the RSM lines.

Issue the new startup instructions:

2.2.2.6. Removing the RSM Automatic Startup Capability

2.2.3. Configuring a Multi-User RSM Manager or Compute Server

2.2.2.7. Additional UNIX/Linux Considerations

2.2.2.7.1. Explicit Dynamics Systems

2.2.2.8. RSH and SSH Job Limitations

2.2.3. Configuring a Multi-User RSM Manager or Compute Server