Remote Solve Manager (RSM) - Ansys

ANSYS Remote Solve Manager (RSM) 

ANSYS, Inc. 

ANSYS Release 13.0 

Southpointe 

275 Technology Drive 

November 2010 

Canonsburg, PA 15317 ANSYS, Inc. is 

ansysinfo@ansys.com 

certified to ISO 

http://www.ansys.com 

(T) 724-746-3304 

(F) 724-514-9494 

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 


of ANSYS, Inc. and its subsidiaries and affiliates.

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. 



1


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: 

2 

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). 



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). 



1.2.Typical RSM Workflows 

3



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 Manager’s 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. 


If the RSM Client and RSM Manager are on the same computer, the RSM Manager uses the RSM Client’s 

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. 


If the Compute Server is running on the same machine as the RSM Manager, then the job runs directly 

in the RSM Manager’s 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 account’s 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 PC’s 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 Client’s 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 Manager’s marker, it uses that location rather 

than copying files unnecessarily. While this leverages operating system level drivers optimized for network 

4 



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. 




5

6 



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. 



7


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: 

Protocol Type 

Installation Requirements 

Data Transfer Efficiency 

Platform Support 

Native communication 

Uses standard TCP/IP to communicate 

with Compute Servers 

Requires RSM to be installed and running 

on the Compute Server (see 

Starting RSM Manager and Compute 

Server Services Manually) 

Most efficient data transfer for solution 

process launch and retrieval of results 

Supported on Windows & Linux only 

SSH communication 

Uses SSH service to execute commands and 

copy data to/from Compute Servers 

Requires installation of SSH client (Putty 

SSH) on the RSM Client machines (see Appendix 

A). 

Communication overhead slows solution 

process launch and retrieval of results 

Supported on all platforms 

ANSYS recommends that you use native communication where possible, and use SSH where platform support 

or IT policy requires it. 




9


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. 

10 

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). 



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 user’s 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: 

• 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. 

14 



• 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. 

... 

 

 

 

 

 

 

 

... 

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 computer’s 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: 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 

Menu Bar 

Description 

Provides access to the following menus: File, Options, View, Tools, and Help. 



17


Interface Element 

Toolbar 

Tree View 

List View 

Progress Pane 

Status Bar 

3.2. Menu Bar 

Description 

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. 

Displays configured queues and servers for one or more RSM Managers. 

Displays current jobs.You can delete jobs from this area. 

Displays the job progress and log messages. 

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. 

The Menu Bar provides the following functions: 

Menu 

File 

Options 

View 

18 

Selections 

Close 

Always On Top 

Hide When Minimized 

All Owner Jobs 

Progress Pane 

Refresh Now 

Update Speed 

Function 

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. 

Main window remains in front of all other windows unless 

minimized. 

If checked, RSM will not appear in the task bar when minimized; 

it only appears as a tray icon (Windows only). 

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). 

Displays or hides the Progress Pane. 

Forces the List View to update immediately, regardless of the 

update speed setting. 

Provides the following submenu selections: 

• 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. 



Menu 

Tools 

Help 

3.3. Tree View 

Selections 

Desktop Alert 

Remove 

Submit a Job 

Options 

ANSYS Remote Solve 

Manager Help 

About ANSYS Remote 

Solve Manager 

Function 

Enables/disables the Desktop Alert window. 

Deletes the selected job or jobs. 

Displays the manual job submit dialog box. 

Displays the Solve Manager options dialog box. 

Displays the Help system in the ANSYS Help Viewer. 

Provides information about the program. 

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. 



3.3.Tree View 

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 



3.9. Windows RSM System Tray Icon and Context Menu 

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 

Options 

Help 

About 

All Owner Jobs 

Desktop Alert 

Open Job Status 

Exit 

Description 

Displays the Options dialog box. 

Displays the Help system in another browser window. 

Provides information about the program. 

Displays or hides jobs that belong to other owners. 

Enables/disables the Desktop Alert window (see Desktop Alert). 

Displays the RSM main window. 

Exits the RSM application. 

3.9.Windows RSM System Tray Icon and Context Menu 



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 “Bob’s 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. 


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 



Note 

If you do not have full permissions to the Compute Server working directory, Compute Server 

tests will fail. 



5.4.Testing a Compute Server 

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: 

 

 

ServerTestCode.xml 

TRUE 

TRUE 

 

*.in 

 

 

*.out 

 

 



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: 

 

 

 

ServerTest.cs 

 

 

 

 

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. 


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: 

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, :\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. 

3. 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


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, :\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 :\Documents and Settings\\My Documents\id_rsa.ppk). 

h. Click OK. 

i. Reboot the computer for environment changes to take effect. 

4. Test the configuration by running the following from the command prompt (quotes around %KEYPATH% 

are required): 

plink -i “%KEYPATH%” unixlogin@unixmachinename pwd 

a. If plink prompts you to store the key in cache, select Yes. 

b. If plink prompts you to trust the key, select Yes. 

5. 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. 

40 



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: 

44 

C:\>rsh unixmachine -l unixaccount ls -l 



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 job’s 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. 


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 



Index 

A 

accounts, 25–26 

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 


adding a Compute Server, 30 

Compute Server properties, 30 

defining, 1 


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 


Windows, 8 

E 

EKM Servers, 11 

Explicit Dynamics systems, 13 

F 


I 

installing RSM, 7 

prerequisites, 7 

standalone installation, 7 

uninstalling, 8 

J 

job 

defining, 1 

manually submitting jobs, 36 

script customization, 35 

job template, 35 

L 

Linux 

configuration, 8 

Explicit Dynamics systems, 13 

installation, 7 

native mode, 9 

remote computing, 9 

starting services at boot time, 11 


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 

Q 

queue 

creating, 29 

defining, 1 

R 

remote computing 


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 




55

Index 


defining, 1 


remotely connecting to an RSM Manager, 14 

solve manager properties, 30 


RSM user interface 

Accounts dialog box, 22 

context menu, 23 

Desktop Alert dialog box, 22 

List View, 17, 20 

main window, 17 

Menu Bar, 17–18 

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 


Compute Server, 11 

EKM Servers, 11 

RSM Manager, 11 

T 

terminology, 1 

U 

UNIX/Linux Path considerations, 13 

user interface, 17 

W 

Windows 


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

Remote Solve Manager (RSM) - Ansys

Create successful ePaper yourself

Delete template?

Save as template?