ANSYS Remote Solve Manager - Guide

ANSYS Remote Solve Manager User's Guide
ANSYS, Inc.
Southpointe
2600 ANSYS Drive
Canonsburg, PA 15317
ansysinfo@ansys.com
http://www.ansys.com
(T) 724-746-3304
(F) 724-514-9494
Release 16.0
January 2015
ANSYS, Inc. is
certified to ISO
9001:2008.
Copyright and Trademark Information

2014-2015 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, AIM
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. RSM Overview ......................................................................................................................................... 1
1.1. RSM Roles and Terminology .............................................................................................................. 1
1.2. Typical RSM Workflows ...................................................................................................................... 2
1.3. File Handling .................................................................................................................................... 4
1.4. RSM Integration with ANSYS Client Applications ................................................................................ 5
1.4.1. RSM Supported Solvers ............................................................................................................ 5
1.4.2. RSM Integration with Workbench ............................................................................................. 5
1.5. RSM Supported Third-Party Job Schedulers/Commercial Batch-Queuing Systems .............................. 6
2. RSM Installation and Configuration ....................................................................................................... 7
2.1. RSM Software Installation ................................................................................................................. 7
2.1.1. Installing a Standalone RSM Package ........................................................................................ 7
2.2. Using the RSM Setup Wizard ............................................................................................................. 8
2.3. RSM Service Installation and Configuration ....................................................................................... 9
2.3.1. Installing and Configuring RSM Services for Windows ............................................................... 9
2.3.1.1. Installing RSM Services for Windows .............................................................................. 10
2.3.2. Installing and Configuring RSM Services for Linux ................................................................... 11
2.3.2.1. Configuring RSM to Use a Remote Computing Mode for Linux ........................................ 11
2.3.2.2. Installing RSM Services for Linux .................................................................................... 12
2.3.2.2.1. Starting RSM Services Manually for Linux ............................................................... 12
2.3.2.2.1.1. Manually Running RSM Service Scripts for Linux ............................................ 13
2.3.2.2.2. Starting RSM Services Automatically at Boot Time for Linux ................................... 13
2.3.2.2.2.1. Installing RSM Automatic Startup (Daemon) Services for Linux ...................... 14
2.3.2.2.2.2. Working with RSM Automatic Startup (Daemon) Services for Linux ................ 15
2.3.2.3. Additional Linux Considerations .................................................................................... 16
2.3.3. Configuring a Multi-User RSM Manager or Compute Server ..................................................... 16
2.3.4. Configuring RSM for a Remote Computing Environment ......................................................... 17
2.3.4.1. Adding a Remote Connection to an RSM Manager .......................................................... 17
2.3.4.2. Adding a Remote Connection to a Compute Server ........................................................ 18
2.3.4.3. Configuring Computers with Multiple Network Interface Cards (NIC) .............................. 18
2.3.5. Configuring a Network Installation ......................................................................................... 19
2.4. Setting Up RSM File Transfers .......................................................................................................... 19
2.4.1. Operating System File Transfer Utilizing Network Shares ......................................................... 19
2.4.1.1. Windows-to-Windows File Transfer ................................................................................. 21
2.4.1.2. Linux-to-Linux File Transfer ............................................................................................ 22
2.4.1.3. Windows-to-Linux File Transfer ...................................................................................... 22
2.4.1.3.1. Additional Windows-to-Linux Configuration When Using Alternate Accounts ......... 23
2.4.1.4. Verifying OS Copy File Transfers ...................................................................................... 25
2.4.2. Eliminating File Transfers by Utilizing a Common Network Share ............................................. 25
2.4.3. Native RSM File Transfer .......................................................................................................... 27
2.4.4. SSH File Transfer ..................................................................................................................... 27
2.4.5. Custom Client Integration ...................................................................................................... 27
2.5. Accessing the RSM Database Configuration File ............................................................................... 27
2.6. Uninstalling RSM ............................................................................................................................. 28
2.6.1. Uninstall a Standalone RSM Package Manually ........................................................................ 28
2.6.1.1. Uninstalling RSM Services for Windows .......................................................................... 28
2.6.1.2. Manually Uninstalling RSM Services for Linux ................................................................. 29
2.6.1.2.1. Uninstalling RSM Automatic Startup (Daemon) Services for Linux .......................... 29
3. RSM User Interface ................................................................................................................................ 31
3.1. RSM Main Window .......................................................................................................................... 32
3.2. Menu Bar ........................................................................................................................................ 32
Release 16.0 - SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information
of ANSYS, Inc. and its subsidiaries and affiliates.
iii
Remote Solve Manager (RSM)

3.3. Toolbar ........................................................................................................................................... 34
3.4. Tree View ........................................................................................................................................ 34
3.5. List View ......................................................................................................................................... 37
3.6. Status Bar ....................................................................................................................................... 39
3.7. Job Log View .................................................................................................................................. 39
3.8. Options Dialog Box ......................................................................................................................... 40
3.9. Desktop Alert ................................................................................................................................. 41
3.10. Accounts Dialog ............................................................................................................................ 42
3.11. Test [computeserver] Dialog ........................................................................................................... 43
3.12. RSM Notification Icon and Context Menu ....................................................................................... 43
4. RSM User Accounts and Passwords ....................................................................................................... 47
4.1. Types of RSM User Accounts ............................................................................................................ 49
4.2. Required Permissions for Creating and Modifying User Accounts ..................................................... 49
4.3. Adding a Primary Account .............................................................................................................. 50
4.4. Adding Alternate Accounts ............................................................................................................. 52
4.5. Working with Account Passwords .................................................................................................... 54
4.5.1. Setting an Account Password ................................................................................................. 54
4.5.2. Changing an Account Password ............................................................................................. 56
4.5.3. Manually Running the Password Application .......................................................................... 57
4.6. Configuring Linux Accounts When Using SSH .................................................................................. 57
5. RSM Administration .............................................................................................................................. 59
5.1. Automating Administrative Tasks with the RSM Setup Wizard .......................................................... 59
5.2. Working with RSM Administration Scripts ........................................................................................ 60
5.3. Creating a Queue ............................................................................................................................ 61
5.4. Modifying RSM Manager Properties ................................................................................................ 62
5.5. Adding a Compute Server ............................................................................................................... 64
5.5.1. Compute Server dialog box Properties .................................................................................... 65
5.5.1.1. Properties on the General Tab ........................................................................................ 65
5.5.1.2. Properties on the Remote Tab ........................................................................................ 70
5.5.1.3. Properties on the Cluster Tab ......................................................................................... 71
5.5.1.4. Properties on the File Management Tab ......................................................................... 72
5.6. Testing a Compute Server ............................................................................................................... 73
6. Customizing RSM .................................................................................................................................. 75
6.1. Understanding RSM Custom Architecture ........................................................................................ 75
6.1.1. Job Templates ........................................................................................................................ 75
6.1.2. Code Templates ..................................................................................................................... 75
6.1.3. Job Scripts ............................................................................................................................. 76
6.1.4. HPC Commands File ............................................................................................................... 76
6.1.5. Job Configuration File ............................................................................................................ 77
6.2. Custom Cluster Integration Setup .................................................................................................... 78
6.2.1. Customizing Server-Side Integration ....................................................................................... 79
6.2.1.1. Configuring RSM to Use a Cluster-Specific Code Template .............................................. 80
6.2.1.2. Creating Copies of Standard Cluster Code Using A Custom Cluster Keyword ................... 82
6.2.1.3. Modifying the Job Configuration File for a New Cluster Type ........................................... 83
6.2.1.4. Modifying the Cluster-Specific HPC Commands File ........................................................ 83
6.2.2. Customizing Client-Side Integration ....................................................................................... 85
6.2.2.1. Configuring RSM to Use a Cluster-Specific Code Template on the Client Machine ............ 86
6.2.2.2. Creating Copies of Sample Code Using a Custom Client Keyword ................................... 88
6.2.2.3. Modifying the Job Configuration File for a New Cluster Type ........................................... 89
6.2.2.4. Modifying the Cluster-Specific HPC Commands File ........................................................ 90
6.2.3. Configuring File Transfer by OS Type and Network Share Availability ........................................ 91
6.2.3.1. Windows Client to Windows Cluster ............................................................................... 91
iv
Remote Solve Manager (RSM)

6.2.3.1.1. Windows-to-Windows, Staging Visible ................................................................... 92
6.2.3.1.2. Windows-to-Windows, Staging Not Visible ............................................................. 92
6.2.3.2. Windows Client to Linux Cluster ..................................................................................... 92
6.2.3.2.1. Windows-to-Linux, Staging Visible ......................................................................... 92
6.2.3.2.2. Windows-to-Linux, Staging Not Visible .................................................................. 93
6.2.3.3. Linux Client to Linux Cluster ........................................................................................... 94
6.2.3.3.1. Linux-to-Linux, Staging Visible ............................................................................... 94
6.2.3.3.2. Linux-to-Linux, Staging Not Visible ........................................................................ 94
6.3. Writing Custom Code for RSM Integration ........................................................................................ 95
6.3.1. Parsing of the Commands Output ........................................................................................... 95
6.3.1.1. Commands Output in the RSM Job Log .......................................................................... 95
6.3.1.2. Error Handling ............................................................................................................... 96
6.3.1.3. Debugging .................................................................................................................... 96
6.3.2. Customizable Commands ....................................................................................................... 96
6.3.2.1. Submit Command ......................................................................................................... 96
6.3.2.2. Status Command ........................................................................................................... 97
6.3.2.3. Cancel Command .......................................................................................................... 98
6.3.2.4. Transfer Command ........................................................................................................ 98
6.3.2.5. Cleanup Command ........................................................................................................ 99
6.3.3. Custom Integration Environment Variables ............................................................................. 99
6.3.3.1. Environment Variables Set by RSM ................................................................................. 99
6.3.3.2. Optional Environment Variables Set by Customer ......................................................... 101
6.3.4. Providing Client Custom Information for Job Submission ...................................................... 102
6.3.4.1. Defining the Environment Variable on the Client .......................................................... 102
6.3.4.2. Passing the Environment Variable to the Compute Server ............................................. 103
6.3.4.3. Verify the Custom Information on the Cluster ............................................................... 104
7. RSM Troubleshooting .......................................................................................................................... 105
A. ANSYS Inc. Remote Solve Manager Setup Wizard .................................................................................... 109
A.1. Overview of the RSM Setup Wizard ............................................................................................... 109
A.2. Prerequisites for the RSM Setup Wizard ......................................................................................... 111
A.3. Running the RSM Setup Wizard ..................................................................................................... 113
A.3.1. Step 1: Start RSM Services and Define RSM Privileges ............................................................ 113
A.3.2. Step 2: Configure RSM .......................................................................................................... 114
A.3.3. Step 3: Test Your RSM Configuration ...................................................................................... 115
A.4. Troubleshooting in the Wizard ...................................................................................................... 116
B. Integrating Windows with Linux using SSH/SCP ..................................................................................... 119
B.1. Configure PuTTY SSH .................................................................................................................... 120
B.2. Add a Compute Server .................................................................................................................. 123
C. Integrating RSM with a Linux Platform LSF, PBS Pro, TORQUE with Moab, or UGE (SGE) Cluster .................. 129
C.1. Add a Linux Submission Host as a Compute Server ........................................................................ 129
C.2. Complete the Configuration ......................................................................................................... 132
C.3. Additional Cluster Details .............................................................................................................. 133
D. Integrating RSM with a Microsoft HPC Cluster ........................................................................................ 135
D.1. Configure RSM on the HPC Head Node .......................................................................................... 135
D.2. Add the HPC Head Node as a Compute Server ............................................................................... 136
D.3. Complete the Configuration ......................................................................................................... 139
D.4. Additional HPC Details .................................................................................................................. 140
Glossary ................................................................................................................................................... 143
Index ........................................................................................................................................................ 147
vi
Chapter 1: RSM 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 (sometimes called the Solve Manager), and the Compute Server
service. You use the RSM Client interface to manage jobs.
RSM Clients submit jobs to a queue, and the 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.4. RSM Integration with ANSYS Client Applications
1.5. RSM Supported Third-Party Job Schedulers/Commercial Batch-Queuing Systems
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, and so on.
Queue
A queue is a list of Compute Servers available to run jobs. When a job is sent to a queue, the 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.
RSM Overview
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 a Manager.
RSM Manager
The RSM Manager (also called the Solve 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.
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. For more information on code templates, see Job Templates.
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 RSM Service Installation and Configuration (p. 9).
The most effective use of RSM is to designate one computer as the RSM Manager for central management
of compute resources. All RSM Clients submit jobs to a queue(s) configured for that RSM Manager, and
the RSM Manager dispatches jobs as compute resources become available on Compute Servers.
The following list shows several typical RSM usage workflows:
1. The RSM Client submits jobs using RSM (running locally) directly to itself so that the job runs locally in
background mode. Here, the RSM Client, the RSM Manager, and the Compute Server are all on the local
machine. This capability is available automatically when you install ANSYS Workbench.
2. The RSM Client submits jobs to the RSM Manager running locally on the same machine. You can assign a
remote Compute Server to run the job or split the job between multiple Compute Servers, optionally including your local machine (as depicted in the second workflow below). A remote Compute Server requires
RSM and the client application to be installed (the client application is typically installed with ANSYS
Workbench, which also includes RSM).
Typical RSM Workflows
3. An RSM Client machine submits jobs to an RSM Manager running on a remote machine (refer to Adding a
Remote Connection to an RSM Manager (p. 17)). 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 RSM Software Installation (p. 7).
RSM Overview
1.3. File Handling

Input files are generally transferred from the RSM Client working directory to the RSM Manager project
directory, and then to the Compute Server working directory where the job is run. Output files generated
by the job are immediately transferred back to the RSM Managers project storage when the job finishes.
The files are stored there until the client application downloads the output files. This section provides
more details about how RSM handles files.
Client Application
The location of files on the RSM Client machine is controlled by the client application (for example, ANSYS
Workbench). When the RSM Client submits a job to an RSM Manager, it specifies a directory where inputs
are found and where output files are placed. Refer to the client application documentation to determine
where input files are placed when submitting jobs to RSM.
Input files are copied to the RSM Manager immediately when the job is submitted.
RSM Manager
The RSM Manager creates a project directory as defined in the project directory input from the RSM UI.
However, when the RSM Manager is local to the client (that is, when it is on the same machine as the RSM
Client), it ignores the RSM UI setting and creates the directory where the job is saved. The base project
directory location is controlled with the Solve Manager Properties dialog box (see Modifying RSM Manager
Properties (p. 62)). All job files are stored in this location until the RSM Client releases the job. Jobs can
also be deleted manually in the RSM user interface.
Compute Server
If the Working Directory Location property on the General tab of the Compute Server Properties dialog
box is set to Automatically Determined, the Compute Server reuses the RSM Managers project directory
as an optimization. Otherwise, the Compute Server creates a temporary directory in the location defined
in the Working Directory Path field on the General tab of the Compute Server Properties dialog box.
If the Working Directory Path property is left 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. If the Delete
Job Files in Working Directory check box of the Compute Server Properties dialog is selected (default),
the temporary directory is then deleted.
Linux SSH
When Windows to Linux SSH file transfer is required by security protocols, the Linux Working Directory
property on the SSH tab of the Compute Server Properties dialog box determines where files are located.
If this field is empty, the accounts home directory is used as the default location. In either case, a unique
temporary directory is created.
Third-Party Schedulers
When using the RSM job scripts that integrate with third-party schedulers such as LSF, PBS Pro, TORQUE
with Moab, Microsoft HPC (previously known as Microsoft Compute Cluster), UGE (SGE), and so on, the file
handling rules listed in this section apply to the extent that RSM is involved. For more information on integrating RSM with various third-party schedulers, see:
Properties on the Cluster Tab (p. 71)
Integrating RSM with a Linux Platform LSF, PBS Pro, TORQUE with Moab or UGE (SGE) Cluster
Integrating RSM with a Microsoft HPC Cluster
RSM Integration with ANSYS Client Applications

File Transfer Methods
ANSYS Remote Solve Manager offers different methods of transferring files. The preferred method is OS
File Transfer and involves using existing network shares to copy the files using the built-in operating system
copy commands. Other methods include native RSM file transfer, SSH file transfer, and complete custom
integration. You can also reduce or eliminate file transfers by sharing a network save/storage location.
For more information, see Setting Up RSM File Transfers (p. 19).
1.4. RSM 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 Processes in the Workbench User's
Guide
For tutorials featuring step-by-step instructions for specific configuration scenarios, go to the Downloads
page of the ANSYS Customer Portal. For further information about tutorials and documentation on the
ANSYS Customer Portal, go to http://support.ansys.com/docinfo.
The client application documentation
The following topics are discussed in this section.
1.4.1. RSM Supported Solvers
1.4.2. RSM Integration with Workbench
1.4.1. RSM Supported Solvers

RSM supports the following solvers:
CFX
Fluent
Mechanical (excluding the Samcef and ABAQUS solvers)
Mechanical APDL
Polyflow
1.4.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
RSM Overview
on multiple machines, you need to ensure that the software that controls the parallel processing is supported
on all of the Compute Servers.
1.5. RSM Supported Third-Party Job Schedulers/Commercial BatchQueuing Systems

RSM supports the following commercial batch-queuing systems on the specified operating systems:
Platform LSF
Operating systems: Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise (SLES)
PBS Professional
TORQUE with Moab
Univa Grid Engine (UGE/SGE)
Windows HPC
Operating systems: Microsoft Windows HPC Server 2008 R2, Windows Server 2012 R2 (Standard) with
Microsoft HPC Pack 2012 R2
RSM can also manage server resources directly, without the involvement of a commercial batch-queuing
system.
Some stand-alone ANSYS applications support a slightly different list of third-party job schedulers.
Chapter 2: RSM Installation and Configuration

This chapter presents a general overview of RSM installation and configuration:
2.1. RSM Software Installation
2.2. Using the RSM Setup Wizard
2.3. RSM Service Installation and Configuration
2.4. Setting Up RSM File Transfers
2.5. Accessing the RSM Database Configuration File
2.6. Uninstalling RSM
For tutorials featuring step-by-step instructions for specific configuration scenarios, go to http://support.ansys.com/docinfo on the ANSYS Customer Portal.
2.1. RSM Software Installation

RSM Clients and Compute Servers require ANSYS Workbench, the ANSYS applications you want to run,
and RSM. As RSM is automatically installed with ANSYS Workbench products, you can use the standard
ANSYS product installation for your RSM Client and your Compute Servers.
An RSM Manager requires only an RSM installation for connectivity with remote RSM Clients and Compute
Servers. For the RSM Manager, while you could use the standard ANSYS product installation, you can
also install RSM by itself (see Installing a Standalone RSM Package (p. 7)).
Administrator privileges are not required to install or uninstall RSM on RSM Client machines.
2.1.1. Installing a Standalone RSM Package

In addition to the default method of installing Remote Solve Manager along with Workbench, it is
possible to install a standalone RSM package (that is, to install everything necessary to run RSM services
and the RSM interface, but without ANSYS Workbench or applications such as ANSYS Mechanical, ANSYS
Fluent, and so on). You can install the standalone RSM package on either a Windows or a Linux machine
via the ANSYS Product Installation Wizard, as follows:
1. Run the wizard as described in Installing ANSYS, Inc. Products.
2. On the Select the products to install page:
a. Under ANSYS Additional Tools, select the ANSYS Remote Solve Manager Standalone Services
check box.
b. Deselect all the other check boxes.
RSM Installation and Configuration

3. Continue the installation process as directed.
Note
When you install a standalone RSM package, this does not mean that RSM services are installed
at the same time; you still need to install or start up necessary RSM services. For instructions,
see Installing RSM Services for Windows or Installing RSM Services for Linux.
2.2. Using the RSM Setup Wizard

The ANSYS Remote Solve Manager Setup Wizard is a new utility that guides you through the process
of setting up and configuring Remote Solve Manager; instead of using manual setup processes, you
can launch the wizard and follow its instructions for each part of the setup. Depending on the RSM
Layout you intend to use, you may need to run the wizard on multiple machines. The wizard will walk
you through the following setup tasks:
1. Start RSM services.
Note
The creation of shared directories needed for use with a commercial cluster is performed
as part of the Wizard configuration.
To start RSM services when UAC is enabled on Windows 7, you must launch the wizard
using the right-click Run as administrator menu option. For instructions on enabling
or disabling UAC, see RSM Troubleshooting (p. 105).
2. Configure the machines to be included in your RSM Layout.

3. Perform various cluster configuration tasks.
4. Integrate RSM with the following third-party job schedulers (without requiring job script customization):
LSF (Linux only)
PBS Pro (Linux only)
TORQUE with Moab (Linux only)
Microsoft HPC (Windows only)
UGE (SGE) (Linux only)
5. Create and share RSM directories (Project Directory, Working Directory, and where applicable, Shared
Cluster Directory).
6. Define queues.
7. Create accounts.
8. Test the final RSM configuration.
RSM Service Installation and Configuration

To launch the RSM Setup Wizard:
For Windows: Select Start > All Programs > ANSYS 16.0 > Remote Solve Manager > RSM Setup
Wizard 16.0. Alternatively, you can navigate to the [RSMInstall]\bin directory and double-click
Ans.Rsm.Wizard.exe.
For Linux: Open a terminal window in the [RSMInstall]\Config\tools\linux directory and
run rsmwizard.
1. Log into the machine that will serve as the RSM Manager. If you are configuring a cluster, this is the
head node of the cluster.
For Windows, you must either have Windows administrative privileges on the RSM Manager, have
RSM administrative privileges (as a member of the RSM Admins user group), or launch the wizard
via the right-click Run as administrator menu option.
For Linux, you must log in with root privileges or have non-root administrative privileges. (Nonroot administrative privileges means that you are a member of the rsmadmins user group. Before
you run the wizard, your IT department must create the rsmadmins user group and manually add
any users who will be starting/running non-daemon services.)
2. Launch the wizard:
Note that the wizard requires different privileges for different parts of the RSM setup process. For details
on necessary permissions, see Prerequisites for the RSM Setup Wizard (p. 111).
For detailed information on the wizards requirements, prerequisites, and capabilities, see Appendix A (p. 109).
For a quick-start guide on using the wizard, see the Readme file. To access this file:
For Windows: Select Start > All Programs > ANSYS 16.0 > Remote Solve Manager > Readme - RSM
Setup Wizard 16.0.
For Linux: Navigate to the [RSMInstall]\Config\tools\linux directory and open
rsm_wiz.pdf.
For more detailed information on the wizards capabilities, prerequisites, and use, see Appendix A (p. 109).
2.3. RSM Service Installation and Configuration

This section includes instructions for installing and configuring RSM services for Windows or Linux machines.
2.3.1. Installing and Configuring RSM Services for Windows
2.3.2. Installing and Configuring RSM Services for Linux
2.3.3. Configuring a Multi-User RSM Manager or Compute Server
2.3.4. Configuring RSM for a Remote Computing Environment
2.3.5. Configuring a Network Installation
2.3.1. Installing and Configuring RSM Services for Windows

The following RSM configuration topics for Windows are discussed in this section:
2.3.1.1. Installing RSM Services for Windows
2.3.1.1. Installing RSM Services for Windows

On a Windows machine, you can configure RSM services to start automatically at boot time by running
the RSM startup script for Windows. You can also uninstall and restart the services by running the script
with the appropriate command line options.
Note
RSM services cannot be started from a network installation. It is recommended that you install
RSM on a local machine.
For GPU requirements when Windows is installed as a service, see Requirements for the GPU
Accelerator in Mechanical APDL in the ANSYS, Inc. Installation Guide for Windows.
RSM Command Line Options for Windows

By adding the following command line options to the end of an RSM service script, you can specify
what service or services you want to configure.
-mgr
Command line option for applying the command to the RSM Manager service.
-svr
Command line option for applying the command to the Compute Server service.
If you use both options with the selected script, the script will be applied to be both services.
Configuring RSM Services to Start Automatically at Boot Time for Windows

To configure RSM services to start automatically at boot time, run the AnsConfigRSM.exe script.
1. Log into a Windows account with administrative privileges.
2. Ensure that Ans.Rsm.* processes are not running in the Windows Task Manager.
3. Open a command prompt in the [RSMInstall]\bin directory.
4. Enter the AnsConfigRSM.exe script into the command line, specifying the service by using the appropriate command line options. The examples below show how to configure both services, the RSM Manager
service only, or the Compute Server service only.
AnsConfigRSM.exe -mgr -svr
AnsConfigRSM.exe -mgr
AnsConfigRSM.exe -svr
5. Run the command.
Note
Windows 7 users may need to select the Run as administrator option.
10

If the RSM services have been removed, you can also use the above sequence of steps to reconfigure
the services.
Important
If you change any system environment variables, you must restart the RSM services in order
for the changes to take effect. If you change your user environment variables, make sure
that you end your Ans.Rsm.UPHost.exe processes (if any) on the affected machine before
trying to run jobs again.
2.3.2. Installing and Configuring RSM Services for Linux

The following RSM configuration topics for Linux are discussed in this section:
2.3.2.1. Configuring RSM to Use a Remote Computing Mode for Linux
2.3.2.2. Installing RSM Services for Linux
2.3.2.3. Additional Linux Considerations
2.3.2.1. Configuring RSM to Use a Remote Computing Mode for Linux

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

commands and copy data to/from
Compute Servers
Uses an external SSH application to

execute commands and copy data to/from
Compute Servers
Installation
Requirements
Requires RSM to be installed and

running on the Compute Server (see
Starting RSM Services Manually for
Linux (p. 12))
Requires installation of SSH client (Putty

SSH) on the RSM Client machines (see
Appendix B (p. 119))
Data Transfer
Efficiency
Most efficient data transfer for

solution process launch and retrieval
of results
Communication overhead slows solution

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

In RSM, it is possible to configure a Linux machine for native mode communications. For performance
reasons, native mode is the recommended method for cross-platform RSM communications; SSH should
only be used if your IT department requires it.
With native mode, a Linux Compute Server has RSM installed and running locally, so the SSH protocol
isnt needed to provide communications between a Windows Compute Server and a Linux Compute
Server. You can configure native mode communications by performing either of the following options
on the Linux machine:
11

OPTION A: Run the ./rsmmanager and ./rsmserver scripts to manually start the RSM Manager and
Compute Server services. Refer to Starting RSM Services Manually for Linux (p. 12) for more information.
OPTION B: Configure RSM to start the RSM Manager and Compute Server services at boot, as described in
Starting RSM Services Automatically at Boot Time for Linux (p. 13).
Adding Common Job Environment Variables for Native Jobs

Before installing and starting the RSM service on Linux, you can edit the rsm_env_profile file under
the [RSMInstall]/Config/tools/linux directory. In this file, you can add any common job
environment variables for native jobs to run. For example, you can use this file to source environment
variables specific to a batch-queuing system, or you can append a cluster-specific PATH. Once defined,
RSM service and native jobs should inherit these environments when any job is run. It is useful to be
able to set common environment variables in a single place instead of having to set them up on each
job user's .cshrc or .profile file from the users $HOME directory.
The following shows the content of rsm_env_profile file:
#!/bin/sh
# The following examples show loading environment settings specific to batch system (for example, LSF, SGE/UGE).
# If defined, RSM service and jobs should then inherit this environment when a job is run.
# . /home/batch/lsf7.0/conf/profile.lsf
# . /home/batch/SGE6.2u2/default/common/settings.sh
2.3.2.2. Installing RSM Services for Linux

When installing RSM services, you must determine if you want to install the RSM services as daemons
that will start the service automatically when the machine is booted, or if you want to start the RSM
services manually via startup scripts. Use only one of these methods.
When RSM services are started manually, the RSM services run as a process for the user who initiated
the services. RSM services that were started manually are stopped each time the machine is rebooted;
after a reboot, before you submit any jobs to RSM you must first restart the RSM services by running
the appropriate startup scripts. For security reasons, it is recommended that you do not start and run
RSM service processes manually as the "root" user.
If you want to install RSM on a multi-user Linux machine or if you would prefer to start RSM services
automatically when the machine is booted, you can configure daemons as described in Starting RSM
Services Automatically at Boot Time for Linux (p. 13).
The following related topics are discussed in this section:
2.3.2.2.1. Starting RSM Services Manually for Linux
2.3.2.2.2. Starting RSM Services Automatically at Boot Time for Linux
2.3.2.2.1. Starting RSM Services Manually for Linux

RSM Manager and Compute Server machines must have RSM services running in order to manage or
run jobs. If you are submitting jobs to an RSM Manager or Compute Server on a remote machine, you
can start RSM services manually by running the scripts detailed in this section. These scripts include:
rsmmanager
Starts the RSM Manager service.
12

rsmserver
Starts the Compute Server service.
rsmxmlrpc
Starts the XmlRpcServer service (required for EKM servers only).
These scripts are generated as part of the RSM installation process and are located in the WBInstallDir/RSM/Config/tools/linux directory. If for some reason these scripts were not generated
during installation or are for other reasons not available, you can generate them yourself. For instructions,
see Generating RSM Service Startup Scripts for Linux (p. 105) in the RSM Troubleshooting (p. 105) section.
2.3.2.2.1.1. Manually Running RSM Service Scripts for Linux

You can run the RSM service scripts to manually start, stop, check the status of, and restart RSM services.
Starting an RSM Service Manually
You can start any of the three RSM services manually by running the appropriate service script with the
command line option start. The examples below illustrate how to start each of the RSM services manually:
./rsmmanager start
./rsmserver start
./rsmxmlrpc start
Stopping an RSM Service Manually

You can stop any of the three RSM services manually by running the appropriate service script with the
command line option stop. The examples below illustrate how to start each of the RSM services manually:
./rsmmanager stop
./rsmserver stop
./rsmxmlrpc stop
Checking the Status of an RSM Service Manually

You can check the status of any of the three RSM services manually by running the appropriate service
script with the command line option status. The examples below illustrate how to check the status of
each of the RSM services manually:
./rsmmanager status
./rsmserver status
./rsmxmlrpc status
Restarting an RSM Service Manually

You can restart any of the three RSM services manually by running the appropriate service script with the
command line option restart. The examples below illustrate how to restart each of the RSM services
manually:
./rsmmanager restart
./rsmserver restart
./rsmxmlrpc restart
2.3.2.2.2. Starting RSM Services Automatically at Boot Time for Linux

You can configure RSM services to start automatically when the machine is booted by configuring them
as daemon services (if the services are not configured to start automatically, they must be started
manually, as described in Starting RSM Services Manually for Linux (p. 12)). Daemon services are scripts
13

or programs that run persistently in the background of the machine, and which are usually executed
at startup by the defined runlevel.
The following related topics are discussed in this section:
2.3.2.2.2.1. Installing RSM Automatic Startup (Daemon) Services for Linux
2.3.2.2.2.2. Working with RSM Automatic Startup (Daemon) Services for Linux
2.3.2.2.2.1. Installing RSM Automatic Startup (Daemon) Services for Linux

Security Requirements for Daemon Service Configuration
To install RSM services as daemons, you must have system administrative permissions (that is, you must
be logged in and installing as a root user or sudoer).
For security reasons, it is recommended that you do not run RSM services as the root user. Many Linux
versions allow only root users to listen to specific ports, so the ports that are required by the RSM
Manager and Compute Server services may be blocked by system administration. For these reasons,
the RSM daemon service installation will create a non-root user account with no logon called rsmadmin;
the account is a member of the rsmadmins user group, and has a home directory of /home/rsmadmin.
The RSM daemon service will then be run by the rsmadmin user.
Note
The RSM daemon service installation will only create the rsmadmin user account if the account
does not already exist. The same is true for the rsmadmins user group if the group name does
not exist. The account/group will be created locally on the computer on which the RSM service(s)
will be run. If you want the account/group to be managed in the master server by Network Information Service (NIS), you need to ask your IT department to create an rsmadmin user account
and rsmadmins group from NIS before running RSM daemon service scripts.
When an RSM package is installed under a directory, make sure that all its parent directories (not
the files in the directory) have both read and execution permissions so that the RSM service executable can be started by a non-root user.
Daemon Service Installation Methods

There are two ways to install RSM services as daemons: by running the rsmconfig script, or by running
the install_daemon script. The difference between the two methods is that whereas the rsmconfig
script always generates fresh service scripts before starting the service installation, the install_daemon
script assumes that the service scripts are always available in the WBInstallDir/RSM/Config/tools/linux directory and uses the existing scripts for service installation, allowing the system
administrator to perform advanced script customizations before the services are installed.)
Both scripts are located in the RSM/Config/tools/linux directory and have the same command
line options.
tools/linux#> ./rsmconfig -help
Options:
-mgr: Install RSM Job Manager service.
-svr: Install RSM Compute Server service.
-xmlrpc: Install RSM XML-RPC Server.
tools/linux# ./install_daemon
Usage: ./install_daemon [-mgr] [-svr] [-xmlrpc]
Options:
14

-mgr: Install RSM Job Manager service.
-svr: Install RSM Compute Server service.
-xmlrpc: Install RSM XML-RPC Server.
Installing RSM Services as Daemons

To install RSM services as daemon services, run either the rsmconfig script or the install_daemon
script, as follows:
1. Log into a Linux account with administrative privileges.
2. Ensure that Ans.Rsm.* processes are not running.
3. Open a terminal window in the RSM/Config/tools/linux directory.
4. Enter the script into the terminal window.
5. Add the appropriate command line options (-mrg, -svr, or -xmlrpc).
6. Run the command.
The two examples below show the command line used to configure the RSM Manager and Compute
Server service daemons via either the rsmconfig or the install_daemon script.
tools/linux#> ./rsmconfig -mgr -svr
tools/linux#> ./install_daemon -mgr -svr
Once the daemon service is installed, the RSM service will be started automatically without rebooting.
The next time when the machine is rebooted, the installed RSM service will be started automatically.
Verifying the RSM Daemon Installation
To verify that the automatic boot procedure is working correctly, reboot the system and check to see
that the services are running by typing the appropriate ps command and looking for Ans.Rsm in the
resulting display:
ps aux | grep Ans.Rsm
2.3.2.2.2.2. Working with RSM Automatic Startup (Daemon) Services for Linux
Once an RSM daemon service is configured, any user can check the status of the service. System administrators can also start or restart the service.
Stopping the Daemon Service
To stop the daemon service:
./etc/init.d/rsmmanager160 stop
Checking the Status of the Daemon Service

To check the status of the daemon service:
./etc/init.d/rsmmanager160 status
Restarting the Daemon Service

To restart the daemon service:
15

./etc/init.d/rsmmanager160 restart
Important
If you change any system environment variables, you must restart the RSM services in order
for the changes to take effect. If you change your user environment variables, make sure
that you end your Ans.Rsm.UPHost.exe processes (if any) on the affected machine before
trying to run jobs again.
2.3.2.3. Additional Linux Considerations

When running RSM on Linux, the following considerations apply:
Linux Path Configuration Requirements

The RSM job scripts that integrate with Linux using PuTTY SSH require you to set AWP_ROOT160 in
the user's environment variables. If the job is not running properly, check the job log in the Job Log
view for "Command not found". Remote command clients like 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_ROOT160 /ansys_inc/v160
Note
~ (tilde) representation of the home directory is not supported for use in RSM paths (for example,
the Working Directory Path in the Compute Server Properties dialog box).
Different shells use different initialization files than the account's home directory and may have
a different syntax than shown above. Refer to the Linux man page for the specific shell or consult
the machine administrator.
RSH/SSH Settings for Inter/Intra-Node Communications

The Use SSH protocol for inter- and intra-node communication (Linux only) property, located on
the General tab of the Compute Server Properties dialog box, determines whether RSM and solvers
use RSH or SSH for inter-node and intra-node communications on Linux machines. When Fluent, CFX,
Mechanical, and Mechanical APDL are configured to send solves to RSM, their solvers will use the same
RSH/SSH settings as RSM.
Explicit Dynamics Systems

RSM does not support Linux connections for Explicit Dynamics systems. Only Windows-to-Windows
connections are currently supported.
2.3.3. Configuring a Multi-User RSM Manager or Compute Server

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

All RSM users should cache their account password (refer to Working with Account Passwords (p. 54)). 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 (see Starting RSM Services Automatically at Boot Time for Linux (p. 13)). Running RSM 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, the My Computer, Background option
that is available for ANSYS Mechanical (see Using Solve Process Settings in the ANSYS 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 RSM Manager name is the machine name,
rather than localhost. For more information, see Using Solve Process Settings in the ANSYS Mechanical
User's Guide.
To run more than one job simultaneously, adjust the Max Running Jobs property in the Compute Server
Properties dialog box.
2.3.4. Configuring RSM for a Remote Computing Environment

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.3.4.1. Adding a Remote Connection to an RSM Manager
2.3.4.2. Adding a Remote Connection to a Compute Server
2.3.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.3.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
Working with Account Passwords (p. 54) for this procedure.
17
2.3.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. 64), 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 Display Name
property on the General tab of the Compute Server Properties dialog box.
If the Compute Server involves integration with a Linux machine or another job scheduler, refer to
Appendix B (p. 119) 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. 73).
2.3.4.3. Configuring Computers with Multiple Network Interface Cards (NIC)

When multiple NIC cards are used, RSM may require additional configuration to establish desired communications between tiers (in other words, the RSM Client, RSM Manager, and Compute Server machines).
You will most likely need to configure the RSM Manager and/or Compute Server machine(s) depending
on which one has multiple NIC cards installed.
1. On the machine that has multiple NIC cards installed, open a text editor, then open the
Ans.Rsm.AppSettings.config file. This file is located in the RSM\Config folder where ANSYS
products are installed.
2. Locate the Global appSettings section, and for the following value enter the machines correct
IP address:
<add key="RemotingMachineNameAttribute" value=""
/>
The correct IP address is the address seen in the output of a ping program from any remote machine
to this machine using the Fully Qualified Domain Name (FQDN).
3. Save the file.
4. Restart the following services: ANSYS JobManager Service V16.0 and ANSYS ScriptHost
Service V16.0.
For Windows: On your Administrative Tools or Administrative Services page, open the Services dialog
box. Restart the services by right-clicking on the service and selecting Restart.
For Linux: Log into a Linux account with administrative privileges and ensure that Ans.Rsm.* processes
are not running. Open a terminal window in the [RSMInstall]/Config/tools/linux directory
and run the following commands:
./rsmserver restart
18
Setting Up RSM File Transfers
2.3.5. Configuring a Network Installation

If you have a network installation of the same RSM package that may be shared by multiple machines,
and want each machine to have a different RSM configuration, you will need to point each machine to
local RSM configuration directories.
Perform the following steps on each machine where the same RSM package is used:
1. Set the system environment variable ANSYS_RSM_DATABASE_DIR to point to the new RSM database
configuration directory. This should be a local path on the machine. For more information about the RSM
database configuration file, see Accessing the RSM Database Configuration File (p. 27).
2. Set the system environment variable ANSYS_RSM_APPSETTINGS_DIR to point to the new RSM application settings configuration directory. Create the directory if it does not exist. Then, copy the
Ans.Rsm.AppSettings.config file into this folder. This file is located in the RSM\Config folder
where ANSYS products are installed on a network drive.
3. Restart the ANSYS JobManager Service V16.0 and/or ANSYS ScriptHost Service V16.0 service on the
current machine:
For Windows: On your Administrative Tools or Administrative Services page, open the Services dialog
box. Right-click on the desired service and select Restart.
For Linux: Log into a Linux account with administrative privileges and ensure that Ans.Rsm.* processes
are not running. Open a terminal window in the [RSMInstall]/Config/tools/linux directory
and run the following commands:
./rsmserver restart
2.4. Setting Up RSM File Transfers

ANSYS Remote Solve Manager offers different methods of transferring files. The preferred method is
OS File Transfer and involves using existing network shares to copy the files using the built-in operating
system copy commands. Other methods include native RSM file transfer, SSH file transfer, and complete
custom integration. You can also reduce or eliminate file transfers by sharing a network save/storage
location.
One of these methods will be used when you are submitting a job to a remote machine. For details on
each method or how to eliminate file transfers, see:
2.4.1. Operating System File Transfer Utilizing Network Shares
2.4.2. Eliminating File Transfers by Utilizing a Common Network Share
2.4.3. Native RSM File Transfer
2.4.4. SSH File Transfer
2.4.5. Custom Client Integration
2.4.1. Operating System File Transfer Utilizing Network Shares

RSM file transfer provides the ability to use the Operating System (OS) Copy operation. The OS Copy
operation can be significantly (up to 5 times) faster than the native file transfer used in the RSM code
(as described in Native RSM File Transfer (p. 27)). OS Copy is a faster and more efficient method of file
transfer because it uses standard OS commands and NFS shares. Typically, the client files are local to
19

the Client machine and are only transferred to the remote machines to solve because of storage speed,
capacity, and network congestion concerns.
No specific configuration is necessary within RSM itself. To enable the OS Copy operation, you must
configure the directories that will be involved in the file transfer so that the target directory is both
visible to and writable by the source machine. Generally, the target directories involved are:
The Project Directory on the RSM Manager machine (as specified in the Solve Manager Properties
dialog box)
The Working Directory on the Compute Server machine (as specified in the Compute Server Properties
dialog box)
Once the configuration is complete, the RSM Client machine should be able to access the Project Directory on the RSM Manager machine and the RSM Manager machine should be able to access the
Working Directory on the remote Compute Server machine. The OS Copy operation will be used
automatically for file transfers.
If two RSM services are on the same machine, no configuration is necessary for OS Copy to function
between those two services. For example, in an RSM layout where the RSM Manager and Compute
Server are on the same machine, the Client is running on a separate machine, the RSM Manager can
access the Working Directory, as long as the permissions are set to allow it. In this case, the only other
20

configuration necessary is to ensure that the RSM Client can access the RSM Managers network shared
Project Directory on the remote machine.
The steps for configuring directories for the OS Copy operation, discussed in the following sections, are
different between Linux and Windows.
Note
For the sake of general applicability, the configuration instructions in the following sections
assume an RSM layout in which each service runs on a separate machine. In a typical environment, however, ANSYS suggests that the RSM Manager and Compute Server be on the
same machine.
Related Topics:
2.4.1.1. Windows-to-Windows File Transfer
2.4.1.2. Linux-to-Linux File Transfer
2.4.1.3. Windows-to-Linux File Transfer
2.4.1.4. Verifying OS Copy File Transfers
2.4.1.1. Windows-to-Windows File Transfer

System Administrator permissions are required to configure directories for Windows-to-Windows OS
Copy file transfers.
For Windows-to-Windows file transfers, RSM uses predefined share names to locate and identify the
target directories. You must perform the following setup tasks for each of the target directories:
Share the target directory out to the remote machine.
Provide full read-write permissions for the shared directory.
Perform these steps for each of the target directories:
1. In Windows Explorer, right-click the target directory.
This is the directory you want to make visible for the OS Copy operations: either the RSM
Manager Project Directory or the Compute Server Working Directory.
2. Select the Sharing tab and click Share.
3. Click the Advanced Sharing button.
4. In the Advanced Settings dialog box, click Share this Folder and enter the correct name for the
share, as shown below.
For the Project Directory on the RSM Manager machine, enter RSM_Mgr.
For example, the directory C:\Projects\ProjectFiles may have a share named
\\winmachine06\RSM_Mgr.
For the Working Directory on the Compute Server machine, enter RSM_CS.
For example, the directory D:\RSMWorkDir may have a share named \\winmachine2\RSM_CS.
21

5. Ensure that full read-write permissions are defined for the target directory.
6. This naming requirement applies only to the network share for the target directory; the directory itself
can have a different name.
Note
Once target directory is shared, you can access it by typing the share path into
Windows Explorer.
7. Perform these steps for the other target directory.
2.4.1.2. Linux-to-Linux File Transfer

Root permissions are required to configure directories for Linux-to-Linux OS Copy file transfers.
For Linux-to-Linux file transfers, RSM uses mount points to locate and identify the target directories.
You must configure each of the target directories by performing the following setup tasks:
1. Ensure that the target directory belongs to a file system that is mounted, so that the target directory
is visible to the machine on which the source directory is located. Use the full path for the target directory.
2. Provide full read-write privileges for the target directory.
2.4.1.3. Windows-to-Linux File Transfer

Root permissions on the Linux machine are required to configure directories for Windows-to-Linux OS
Copy file transfers.
For Windows-to-Linux transfers (using Samba or a similar Linux utility), entries in the Samba configuration
file map the actual physical location of the Linux target directories to the predefined Windows share
names that RSM uses to locate and identify the target directories. The following example shows how
to configure a Samba share on Linux for the target directories RSM requires for the OS Copy operation.
If you are unable to create the share, contact your IT System Administrator for assistance with this step.
Edit the smb.conf Samba configuration file to include definitions for each of the Linux target directories. The example below shows Sambas default values for the Linux target directories.
[RSM_Mgr]
path = /home/staff/RSM/ProjectDirectory
browseable = yes
writable = yes
create mode = 0664
directory mode = 0775
guest ok = no
[RSM_CS]
path = /home/staff/RSM/WorkingDirectory
browseable = yes
writable = yes
create mode = 0664
guest ok = no
22

The path should point to the actual physical location of the existing target directories. The path for the
Project Directory should match the Project Directory path defined in the Solve Manager Properties
dialog box. The path for the Working Directory should match the Working Directory path defined in
the Compute Server Properties dialog box.
After making your changes to smb.conf, restart the Samba server by running the following command:
/etc/init.d/smb restart
Note
The locations of files and method of restarting the Samba service may vary for different Linux
versions.
Verify that the Samba shares are accessible by your Windows machine, indicating that they have been
properly set up. Check this by using Windows Explorer and navigating to the locations shown below
(using your specific machine name in place of linuxmachinename):
\\linuxmachinename\RSM_Mgr for the Project Directory on the RSM Manager machine
\\linuxmachinename\RSM_CS for the Working Directory on the Compute Server machine
2.4.1.3.1. Additional Windows-to-Linux Configuration When Using Alternate Accounts

This section contains additional tasks and information associated with configuring directories for Windows-to-Linux OS Copy file transfers.
Permission Issues
Permission issues can occur when an alternate account is used to run jobs on the Linux side. To resolve
such issues, make sure that Samba (or a similar Linux utility) is correctly configured.
The following code sample is from the Samba configuration file, smb.conf, showing a configuration
for file sharing between three accounts:
A Windows account mapped to a Linux account
An alternate account
An account that runs as the RSM service
[RSM_CS]
path = /lsf/wbtest
browseable = yes
writable = yes
create mode = 0666
guest ok = no
create mode:
The Samba default is 664, which corresponds to rw-rw-r--. If the alternate account is not in the same group
as the owner of the file, the job cannot write to the file and an error occurs for files that are both inputs
and outputs.
23

To provide full read-write access for all the accounts, set create mode to 666, as shown above in
the code sample. This sets the permissions for files that are copied from Windows to Linux to rwrw-rw, allowing all accounts to both read from and write to the file.
directory mode:
The Samba default is 775. If the copy from Windows to the Samba share results in the creation of directories,
a value of 775 prevents the job running under the alternate account from creating files in the newly copied
subdirectories.
To allow the job to create files in the new subdirectories, set directory mode to 777.
After making your changes to smb.conf, restart the Samba server as shown above.
Note
The locations of files and method of restarting the Samba service may vary for different Linux
versions.
User-specific Shares
Home Directory Shares
In order to use the home directory for each user as the share, a specific path variable (%H) must be used
for the shares. This is illustrated in the example below.
[RSM_CS]
path = %H/rsmtemp
browseable = yes
writable = yes
create mode = 0700
guest ok = no
The %H path variable represents the entire home directory path. For normal use, it is recommended
that users create a subdirectory in their home directory (for example, rsmtemp) to prevent the home
directory from becoming cluttered with ANSYS solve directories, and to facilitate the cleanup of cancelled
jobs or jobs that need to be kept for some time.
Generic User Directory Shares
If for some reason you do not want to use the home directory, you can create and use another directory
provided that there is a folder for each user in the directory. In this case, the path variable %u is used,
as shown in the example below.
[RSM_CS]
path = /ansysTemp/users/%u/rsmJobs
browseable = yes
writable = yes
create mode = 0700
guest ok = no
The $u path variable represents a users username. Therefore, the name of each folder in the chosen
directory must match the username exactly.
24
Resharing Network File System (NFS) Shares Through Samba

If sharing an NFS share, you may need to use an additional nolock keyword option to disable any file
locking that may occur when a Windows machine attempts to access an NFS share through a Samba
Share.
This is shown in the following excerpt from /etc/fstab:
hserver:/home on/nfs/hserver/homes type nfs (rw,soft,intr,nolock)
2.4.1.4. Verifying OS Copy File Transfers

After configuring a target directory for sharing, you can run a test server operation. Information about
the method used for file transfer is written to the job log in the RSM Job Log view and can be used to
verify whether RSM files are being transferred via the OS Copy operation:
In the job log, the messages Manager network share is available and Compute Server network share
is available indicate that all necessary directories are visible and OS Copy is being used.
2.4.2. Eliminating File Transfers by Utilizing a Common Network Share

Even though Workbench projects are typically run locally, small projects or larger models utilizing exceptional networks and file systems that exist today can allow Workbench projects to be saved and
opened from a network share. When using a shared Workbench storage location, this shared folder can
be used to minimize file transfers. In particular, this can be used to remove the necessity of transferring
files to and from the Client machine and the remote machine(s); ideally, this storage would be directly
attached to the Compute Server(s).
RSM places marker files in the RSM Client, RSM Manager, and Compute Server directories to uniquely
identify the job.
If the RSM Manager finds the RSM Clients marker in the project storage area (by recursively searching
subfolders), it will use that folder rather than copying the files to a separate folder.
Similarly, if the Compute Server finds the RSM Managers marker (by recursively searching subfolders),
it will also use that location rather than copying files unnecessarily.
Remember that while this leverages drivers at the operating system level which are optimized for network
file manipulation, files are still located on remote hard drives. As such, there will still be significant
network traffic, for example, when viewing results and opening and saving projects. Each customer will
have to determine the RSM configuration that best uses network resources.
The Client must be able access the Client Directory under the RSM Manager Project Directory. The
RSM Manager must have access to its sub-folders, including the RSM Client Directory and the shared
Compute Server Working Directory. One or both of these directories will be under the shared RSM
Manager Project Directory in this setup.
25
Example: You can set up RSM to use file shares in order to remove unnecessary file transfers. For example,
you might have a Linux share \usr\user_name\MyProjectFiles\, and have that same folder
shared via Samba or a similar method and mounted on the Windows Client machine as Z:\MyProjectFiles\. If you save your Workbench projects to this network location, you can set the RSM
Manager and Compute Server properties as follows in order to remove all file transfers and use the
network share directly as the working directory:
RSM Manager
For a Linux-based RSM Manager, set the Project Directory Location property to
\user\user_name\MyProjectFiles\.
For a Windows-based RSM Manager, set the Project Directory Location property to Z:\MyProjectFiles\.
Compute Server
For a Linux-based Compute Server, set the Working Directory Location property to
\user\user_name\MyProjectFiles\.
For a Windows-based Compute Server, set the Working Directory Location property to
Z:\MyProjectFiles\.
In some cases, you might still want a separate Working Directory and/or Project Directory and thus,
would not define the corresponding network file share(s) as described above. For example, if the jobs
26
Accessing the RSM Database Configuration File

to be submitted will make heavy use of scratch space (as some Mechanical jobs do), you might want
to retain a separate Working Directory which is on a separate physical disk and thus would not define
the two Working Directories to be in the same location.
2.4.3. Native RSM File Transfer

Native RSM file transfer occurs automatically if the preferred OS file copy or a Common Network Share
setup is not found. Native transfer requires no special setup or considerations, but is usually slower
than the preferred OS File copy setup. This method of file transfer uses the installed RSM services to
start a service to service file copy using the standard Microsoft .Net libraries. RSM has also included
some built-in compression features which can aid with copying over slow connections. For more information about these features see section Modifying RSM Manager Properties (p. 62).
2.4.4. SSH File Transfer

SSH file transfer can be defined to transfer files between a Windows proxy Compute Server to a Linux
machine, but is not supported in other configurations. SSH file transfer mode is actually just referencing
an external PuTTY implementation and is not natively included with RSM, but is included as an option
for customers who must use this protocol based on their specific IT security requirements. This method
is also usually slower than the preferred OS File Copy method, and thus is not recommended unless it
is required. For more information on setting up SSH, see Appendix B (p. 119).
2.4.5. Custom Client Integration

RSM also provides a method for completely customizing the file handling of RSM, using client-side integration to suit any specialized customer needs by using customer-written scripts. For more information
on custom integration techniques, see Customizing RSM (p. 75).
2.5. Accessing the RSM Database Configuration File

RSM database configurations are stored in a file named RSM.Config. This file contains the following:
RSM user account information
Compute server configuration
Queue configurations
It is not recommended that you edit this file, but you may want locate it in order to create a backup
copy of your RSM database configurations. You can also manually load RSM database configurations
to another machine by copying the RSM.Config file to the appropriate directory on that machine.
The location of the RSM.Config file depends on how the manager service has been installed.
To access the RSM.Config file:
If the RSM Manager service has been installed as a Windows service running as SYSTEM, the file is located
in %ALLUSERSPROFILE%\Ansys\v160\RSM\RSM.Config.
27

If the RSM Manager is run as a normal process on Windows, the file is located in %AppData%\Ansys\v160\RSM\RSM.Config.
Note
For a user who can log on from different machines, the system must already be configured
to use the Roaming profile.
On Linux, the file is located in ~/.ansys/v160/RSM/RSM.Config, where ~ is home directory of the

account under which the RSM Manager is being run.
2.6. Uninstalling RSM

Uninstall RSM with Workbench
For a machine on which RSM was installed along with ANSYS Workbench, RSM is removed when you
do a full uninstall of Workbench and ANSYS products. Run the ANSYS Product Uninstall wizard and
click the Select All button to remove all products.
Uninstall a Standalone RSM Package

To uninstall a standalone RSM package, run the ANSYS Product Uninstall wizard and select only the
ANSYS RSM check box.
2.6.1. Uninstall a Standalone RSM Package Manually

To uninstall a standalone RSM package manually, first uninstall all RSM services.
To uninstall RSM services for Windows, see Uninstalling RSM Services for Windows (p. 28).
To uninstall RSM services started manually for Linux, see Manually Uninstalling RSM Services for
Linux (p. 29).
To uninstall RSM daemon services for Linux, see Uninstalling RSM Automatic Startup (Daemon) Services
for Linux (p. 29).
After the services have been uninstalled, delete the RSM installation directory.
2.6.1.1. Uninstalling RSM Services for Windows

To unconfigure (remove) all RSM services, run the AnsUnconfigRSM.exe script.
1. Log into a Windows account with administrative privileges.
2. Ensure that Ans.Rsm.* processes are not running in the Windows Task Manager.
3. Open a command prompt in the [RSMInstall]\bin directory.
4. Enter the AnsUnconfigRSM.exe script into the command line.
28
Uninstalling RSM
5. Run the command.
Note
If you are using a Windows 7 operating system, you may need to select the Run as administrator option from the right-click context menu.
The uninstaller can only stop services which were started by and are owned by the user performing the uninstall.
6. After the services have been uninstalled, delete the RSM installation directory.
2.6.1.2. Manually Uninstalling RSM Services for Linux

1. Log into a Linux account with administrative privileges.
2. Ensure that Ans.Rsm.* processes are not running.
3. Open a terminal window in the RSM/Config/tools/linux directory.
4. Enter the rsmunconfig script into the command line, as shown below:
tools/linux#> ./rsmunconfig
5. Run the script.
Note
The uninstaller can only stop services which were started by and are owned by the user
performing the uninstall.
2.6.1.2.1. Uninstalling RSM Automatic Startup (Daemon) Services for Linux

As with RSM daemon service installation, only a system administrator can uninstall the RSM daemon
service. Also, the uninstaller can only stop services which were started by and are owned by the user
performing the uninstall.
Uninstalling All RSM Daemon Services

To uninstall all RSM daemon services, run the rsmunconfig script (without command line options).
The script is located in the WBInstallDir/RSM/Config/tools/linux directory.
The example below shows the command line used to uninstall all RSM service daemons.
tools/linux#> ./rsmunconfig
Uninstalling Individual RSM Daemon Services

To uninstall RSM daemon services individually, run the uninstall_daemon script. The script is located
in the WBInstallDir/RSM/Config/tools/linux directory. Specify the service by using command
line options, as shown below:
29

tools/linux# ./uninstall_daemon
Usage: ./uninstall_daemon [-mgr] [-svr] [-xmlrpc] [-rmadmin]
Options:
-mgr: Uninstall RSM Job Manager service.
-svr: Uninstall RSM Compute Server service.
-xmlrpc: Uninstall RSM XML-RPC Server.
-rmadmin : Remove 'rsmadmin' user and 'rsmadmins' group service account.
The example below shows the command line used to uninstall RSM Manager and Compute Server service
daemons via the uninstall_daemon script.
tools/linux#> ./uninstall_daemon -mgr -svr
Removing the Administrative User Account and Service Group Manually

By default, the rsmunconfig script does not remove the rsmadmin user account and rsmadmins
user group that were created earlier when service was configured. This allows the same account and
user group to be reused for the next service installation and configuration, and also prevents the accidental deletion of important files from the rsmadmin home directory (/home/rsmadmin).
However, if you decide that you do not want to keep the user account and user group, you can remove
them manually by adding the -rmadmin command line option to the uninstall_daemon script.
tools/linux#> ./uninstall_daemon -rmadmin
Important
The service account and group cannot be deleted if one or more RSM services are still being
run by that user account and service group name. You will be prompted to answer Yes or
No from the above command when there is no service is being run by these accounts and
RSM is trying to delete them.
30
Chapter 3: RSM User Interface

To launch RSM:
If you are using a Windows system, select Start > All Programs > ANSYS 16.0 > Remote Solve Manager
> RSM 16.0.
If you are using a Linux system, run the <RSMInstall>\Config\tools\linux\rsmadmin script.
Note
On Linux platforms, if you are re-launching a running RSM window after it has been closed
or minimized, the default Linux window management behavior applies. The RSM window
will open behind an active application rather than stealing focus.
You can change this behavior in either of the following ways:
In RSM, select View > Always On Top. When maximized, the RSM window will remain on top
of all other application windows.
If you are using KDE, access your Window Behavior settings and set the Focus stealing prevention level to None.
This chapter describes the following features of the RSM user interface:
3.1. RSM Main Window
3.2. Menu Bar
3.3.Toolbar
3.4.Tree View
3.5. List View
3.6. Status Bar
3.7. Job Log View
3.8. Options Dialog Box
3.9. Desktop Alert
3.10. Accounts Dialog
3.11.Test [computeserver] Dialog
3.12. RSM Notification Icon and Context Menu
31
RSM User Interface
3.1. RSM Main Window

Figure 3.1: RSM Main Window
Interface
Element
Description
Menu Bar
Provides access to the following menus: File, View, Tools, and Help.
Toolbar
Contains the following tools, from left to right: the Show drop-down and
three icons: Remove, All Owner Jobs, and Job Log.
Tree View
Displays defined RSM Managers, along with the Queues and Compute
Servers configured for each.
List View
Displays a listing of current jobs. You can delete jobs from this area
by selecting one or more jobs from the list and selecting Remove
from the context menu.
Job Log
View
Displays the progress and log messages for the job selected in the
List view.
Status Bar
Displays an icon indicating the status of the active operation.
3.2. Menu Bar

The menu bar provides the following functions:
Menu
Selections
Function
File
Minimize
to System
Tray
Hides the RSM main window. RSM continues to run and is
Exit
Exits the RSM application.
32
available from the system tray:
Menu Bar
Alternatively, you can right-click the RSM icon in the
notification area (or system tray
from in the context menu.
View
All Owner
Jobs
) and select Exit
Controls the display of jobs in the List view, allowing

you to display or hide jobs according to ownership.
Deselect to display only your own jobs.
Select to display the jobs of all owners.
Job Log
Displays or hides the Job Log view.
Refresh
Now
Forces the List view to update immediately, regardless

of the update speed setting.
Update
Speed
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.
Tools
Help
Always On
Top
When selected, the main RSM window remains in front

of all other windows unless minimized.
Hide When
Minimized
When selected, RSM will not appear on the taskbar
Desktop
Alert
Enables/disables the desktop alert window.
Remove
Deletes the job or jobs selected in the List view.
Submit a
Job
Displays the Submit Job dialog box, which allows you

to submit jobs manually.
Options
Displays the RSM Manager Options dialog box, which

allows you to define RSM Managers and specify
desktop alert settings.
ANSYS
Remote
Solve
Manager
Help
Displays the Help system in the ANSYS Help Viewer.
About
ANSYS
Remote
Solve
Manager
Provides information about the program.
when minimized. The RSM icon

will display in the
notification area (or system tray).
33
RSM User Interface
3.3. Toolbar
The toolbar provides the following functions:
Tool
Selections
Function
Show
All
Jobs
When this menu item is selected from the drop-down, all

jobs display in the List view.
Completed
When this menu item is selected from the drop-down,

only completed jobs display in the List view.
These jobs display with a Status of Finished.
Running

only running jobs display in the List view.
These jobs display with a Status of Running.
Queued

only queued jobs display in the List view.
These jobs display with a Status of Queued.
Failed

only failed jobs display in the List view.
These jobs display with a Status of Failed.
Cancelled

only cancelled jobs display in the List view.
These jobs display with a Status of Cancelled.
Remove
Not
applicable.
This icon allows you to delete the currently selected job or

jobs. It functions in the same way as the Remove option
of the right-click context menu, the Tools > Remove option
in the menu bar, or the Delete key.
All Owner
Jobs
Selected or
deselected.
This icon allows you to display or hide jobs that belong to

owners other than yourself. The function is the same as
using the View > All Owner Jobs option in the menu bar.
Job Log
Selected or
deselected.
This icon allows you to display or hide the Job Log view.
The function is the same as using the View > Job Log
option in the menu bar.
3.4. Tree View

The Tree view contains a list of Compute Servers, Queues, and RSM Managers. Compute Servers and
queues that appear may be set up on either your local machine (shown as My Computer) or remotely
on an RSM Manager.
The components in the list are summarized below:
Each RSM Manager node is a separate configuration, defined by the machine designated as the RSM Manager.
New RSM Managers are added via the Options dialog box, accessed by Tools > Options on the menu bar.
34
Tree View
The Queues node for an RSM Manager contains all of the queues that have been defined for that RSM
Manager. You can expand a Queue to view the Queue Compute Servers associated with it; these are the
Compute Servers that have been assigned to the Queue (that is, the machines to which the RSM Manager
will send queued jobs for processing).
The Compute Servers node contains all of the Compute Servers associated with the RSM Manager; these
are the machines that are available to be assigned to a Queue and to which jobs can be sent for processing.
Note
If you disable an RSM Manager, Queue, or Compute Server, it will be grayed out on the Tree view.
For information on disabling RSM Managers, see Options Dialog Box (p. 40).
For information on disabling Queues, see Creating a Queue (p. 61).
For information on disabling Compute Servers, see Adding a Compute Server (p. 64).
If a connection cannot be made with an RSM Manager, the RSM Manager will be preceded by a
red X icon.
For information on testing RSM Managers, see Testing a Compute Server (p. 73).
Tree View Context Menus

When an RSM Manager node is selected, Properties and Accounts options are available in the context
menu. If you havent yet cached your password with RSM, the Set Password option is also available.
35
RSM User Interface

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.
When a Compute Server is selected under a Queues node or under a Compute Servers node, the
Properties, Test, and Advanced Test options are available. The Delete option becomes available if a
Compute Server that is not assigned to any queue is selected under a Compute Servers node, as shown
in the image on the right below.
When a Compute Servers node is selected, only the Add option is available.
36
List View
For more information on using the Tree view context menu options, see RSM Administration (p. 59).
3.5. List View

You can sort the displayed fields by clicking on the column by which you want to sort. You can delete
one or more jobs that belong to you by selecting the jobs and clicking the Remove button in the
toolbar. Alternatively, you can also select Remove from the context menu, select Remove from the
Tools menu, or press the Delete key. When you delete a job, the job may not be removed from the
List view immediately; it will be removed the next time that the List view is refreshed.
Note
If a job is still running, you cannot remove it. Use either the Abort or the Interrupt option
in the List view context menu. Once the job Status changes to either Finished or Canceled,
you can click the Remove button to delete the job. The Interrupt command allows a job to
clean up the processes it has spawned before termination; the Abort command terminates
the job immediately. There may also be a job stopping option in the client application that
submitted the job (for example, ANSYS Workbench Mechanical Stop Solution command).
There may also be a disconnect option in the client application that submitted the job (for
example, the ANSYS Workbench Mechanical Disconnect Job from RSM command).
The List view context menu provides the following options:

Option
Function
Inquire
Inquire about a running job. This action depends on the type of job
being run.
37
RSM User Interface

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.
Abort
Immediately terminates a running job. Enabled only if a running job

is selected.
Jobs terminated via this option will have a Status of Canceled in the
List view.
Interrupt
Terminates a running job. Enabled only if a running job is selected.

Jobs terminated via this option will have a Status of Finished in the
List view.
Remove
Deletes the selected job or jobs from the List view. Enabled only if a
completed job is selected.
Cannot be used on a running job. It functions in the same way as the
Tools > Remove option in the menu bar.
Set Priority
Allows you to set the submission priority for the selected job or jobs.
When jobs are submitted they have a default priority of Normal.
Enabled only for jobs with a Status of Queued.
The higher priority jobs in a queue run first. To change the priority of
a Queued job, right-click the job name, select Set Priority and change
the priority. Only RSM administrators can change a job priority to the
highest level.
The status of each job displayed in the List view is indicated by the Status column and an icon. For
jobs that have completed, the Status column and an icon indicate the final status of the job; the addition
of an asterisk (*) to the final status icon indicates that the job has been released.
Status
Description
Input
Pending
Job is being uploaded to RSM.
Queued
Job has been placed in the RSM Manager queue

and is waiting to be run.
Running
Job is running.
Cancelled
Job has been terminated via the Abort option.
Icon
Also applies to jobs that have been aborted

because you exited a project without first
performing one of the following actions:
Saving the project since the update was initiated
Saving results retrieved since your last save
38
Released Icon
Job Log View

Finished
Job has completed successfully.

Also applies to jobs that have been terminated
via the Interrupt option or for which you have
saved results prior to exiting the project.
Failed
Job has failed.

Also may be applied to jobs that cannot be
cancelled due to fatal errors.
3.6. Status Bar

The Status bar indicates the status of the currently running operation by displaying either a Ready
icon or a Busy icon in its bottom left corner.
3.7. Job Log View

The Job Log view provides log messages about the job. The log automatically scrolls to the bottom to
keep the most recent messages in view. To stop automatic scrolling, move the vertical slider from its
default bottom position to any other location. To resume automatic scrolling, either move vertical slider
back to the bottom or select End from the Job Log view context menu.
The right-click context menu provides the following options:
Status
Description
Copy
Copy selected text in the Job Log view.

Alternatively, you can use the Ctrl+C key combination.
Select All
Select all of the text in the Job Log view.

Alternatively, you can use the Ctrl+A key combination.
Home
Go to the top of the Job Log view.
End
Go to the bottom of the Job Log view.
39
RSM User Interface

Save Job Report...
This option allows you to generate a Job Report for the job item selected
from the RSM List view. Enabled when the job has completed (that is, has a
final Status of Finished, Failed, or Cancelled).
The Job Report will include job details and the contents of the job log shown
in Job Log view. When generating the report, you can specify the following
report preferences:
Include Debug Messages: whether debugging messages are included in the
Job Report
Include Log Time Stamp: whether a log time stamp is included in the Job Report
Include Line Numbering: whether line numbering will be displayed on the Job
Report
Click the Browse button to select the directory to which the report will be
saved, type in report filename (RSMJob.html by default), select the report
format (HTML or text format), and click Save.
Line Numbering
Enable or disable the display of line numbers in the Job Log view. Right-click
inside the inside the Job Log view and select or deselect Line Numbering
Time Stamp
Enable or disable the display of the time stamp for each line in the Job Log
view. Right-click inside the Job Log view and select or deselect Time Stamp
Debug Messages
Enable or disable the display of debugging information. Right-click inside

the Job Log view and select or deselect Debug Messages from the context
menu to toggle between standard job log messages and debugging
messages.
Note
When making a support call concerning RSM functionality, send the RSM job report. Note
the HTML-format job report uses color highlighting by row to distinguish the Job Log view
contents from other information, which can be helpful for troubleshooting.
3.8. Options Dialog Box

From the menu bar, select Tools > Options to open Options dialog box. Use the Options dialog box
to configure RSM Managers or set up desktop alert settings.
40
Desktop Alert
The Options dialog box contains the following functions:

The Solve Managers pane lists available RSM Manager machines.
To enable or disable an RSM Manager, select or deselect the preceding check box. Disabled RSM Managers
will display as grayed out in the Tree view.
To add a new RSM Manager, type its name into the Name field and click the Add button.
To remove an RSM Manager, highlight it in the list and click the Delete button.
To change the name of an RSM Manager, highlight it in the list, edit the name in the Name field, and click
the Change button.
The Desktop Alert Settings pane contains check boxes to configure the following desktop alerts:
Show Running Jobs
Show Pending Jobs
Show Completed Jobs
3.9. 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. If all jobs are finished, the desktop alert disappears automatically.
If you want to hide the desktop alert window, use the menu options or tray context menu (right-click
the RSM icon in the notification area or system tray) to turn it off. If you close the desktop alert, it will
not remain hidden permanently. It will display again as long as jobs are active unless the alert is turned
off.
You can specify what jobs display on the desktop alert via the Options dialog box. To access the Options
dialog box, select Options from the RSM icon context menu or select Tools > Options from the menu
bar.
41
RSM User Interface
3.10. Accounts Dialog

To access the Accounts dialog box in Remote Solve Manager, right-click the RSM Manager node in the
RSM tree view and select Accounts.
The Accounts dialog allows you to define the accounts you will use with RSM. Given adequate privileges,
you can add, edit, and delete both primary and alternate accounts. For alternate accounts, you can also
select the Compute Servers that the alternate accounts will be used to access.
The Add Primary Account button allows you to define primary accounts for RSM.
When you right-click an existing account, the following context menu options are available:
Option
42
Function
RSM Notification Icon and Context Menu

Add Alternate Account
Available only when a primary account is selected.

Create an alternate account for the selected primary account.
Change Password
Change the password for the selected account.
Remove
Deletes the selected account.

When a primary account is removed, any associated alternate
accounts are also removed.
For more detailed information on working with accounts in RSM, see RSM User Accounts and Passwords (p. 47).
3.11. Test [computeserver] Dialog

To access the Test [computeserver] dialog in Remote Solve Manager, right-click a Compute Server
node in the Remote Solve Manager tree view and select Advanced Test.
The Test [computeserver] dialog box allows you to determine the type of test that will be performed
(either a basic configuration test or a file transfer check) and specify the directory in which the test job
will be run.
For more detailed information, see Testing a Compute Server (p. 73).
3.12. RSM Notification Icon and Context Menu

By default, RSM does not appear on the taskbar when it is minimized. To change this behavior, select
View > Hide When Minimized (to deselect this option). Otherwise you can use the RSM icon in the
notification area (also called the system tray for Linux GNOME) to interact with RSM when it is minimized.
On a Windows system, the notification area or system tray is accessible from the desktop and the RSM
icon is loaded to the notification area by default. On a Linux system, you may need to enable the notification area or system tray for the desktop.
To open the RSM interface, double-click the notification icon
By default, the RSM icon and its tooltip are static. You can, however, configure the icon and tooltip to
provide feedback on the current status of jobs. You can configure this behavior in the
Ans.Rsm.AppSettings.config file.
If you configure the icon to provide feedback, its appearance will vary according to the current status
of jobs:
Notification
Icon
Job Status
No jobs are running.
At least one job is running.
At least one job has failed.
All jobs have completed.
43
RSM User Interface

If you configure the tooltip to provide feedback, it will display the current status of jobs (the number
of jobs that are running, queued, failed, and so on).
Note
In Windows, the tooltip window has a 63-character limit. If this limit is exceeded, the current
status of jobs will not be displayed.
Configuring the RSM Icon and Tooltip Behavior

Follow the steps below to specify whether or not you want the RSM icon and optionally its tooltip to
provide feedback on the current status of jobs.
1.
Go to the [ANSYS 16.0 Install]/RSM/Config folder and open the Ans.Rsm.AppSettings.config file in a text editor.
2.
Locate the following setting:

<add key="TrayIcon.IndicateJobsStatus" value="None"/>
3.
Set the value to one of the following to indicate the desired behavior:
None. (default) The icon and tooltip do not change or provide feedback on the current status of jobs.
Icon. Only the icon changes based on the status of jobs.
IconAndToolTip. Both the icon and tooltip change based on the status of jobs.
Accessing Menu Options from the RSM Icon

Right-click the RSM icon to access its context menu. The context menu contains most of options that
are available on the RSM menu bar, as shown below:
Menu
Option
Description
Options
Displays the Options dialog box.
44
RSM Notification Icon and Context Menu

Menu
Option
Description
Functions in the same way as Tools > Options on the menu bar.
Help
Displays the Help system.
About
Provides information about the program.
All Owner
Jobs
Displays or hides jobs that belong to other owners.

Works in conjunction with the View > All Owner Jobs option in the
menu bar and the All Owner Jobs icon in the toolbar.
Desktop
Alert
Enables/disables the desktop alert window (see Desktop Alert (p. 41)).
Works in conjunction with the Tools > Desktop Alert option in the
menu bar.
Open Job
Status
Displays the RSM main window.
Exit
Exits the RSM application.

Functions in the same way as File > Exit on the menu bar.
45
46
Chapter 4: RSM User Accounts and Passwords

As part of setting up Remote Solve Manager, you must create user accounts for all users who will be
working with RSM.
The following topics are discussed in this section:
4.1.Types of RSM User Accounts
4.2. Required Permissions for Creating and Modifying User Accounts
4.3. Adding a Primary Account
4.4. Adding Alternate Accounts
4.5. Working with Account Passwords
4.6. Configuring Linux Accounts When Using SSH
RSM Administrative Privileges If you are a member of the RSM Admins user group, you have administrative privileges for RSM. You can use the Accounts dialog box to perform the following tasks:
Create accounts
Modify any account
Change the password for any account
Change the assignment of Compute Servers to any alternate account
47
RSM User Accounts and Passwords
Note
To create the RSM Admins user group and add users:
1. Right-click Computer and select Manage.
2. On the Computer Management dialog box, expand Local Users and Groups.
3. Right-click the Groups folder and select New Group.
4. On the New Group dialog box, enter RSM Admins as the Group Name and add members
by clicking the Add button.
5. On the Select Users, Computers, Service Accounts, or Groups dialog box:
Type in user names.
Click the Check Names button to check and select each name.
6. Click the Create button to create the new group.
RSM Non-Administrative Privileges If you are not a member of the RSM Admins user group, you
do not have administrative privileges for RSM. You can use the Accounts dialog box to perform the
following tasks:
Add or remove your own primary and alternate accounts
Change the passwords for your own accounts
Change the assignment of Compute Servers to your own alternate account
48
Required Permissions for Creating and Modifying User Accounts

RSM configuration data, including user account and password information, is stored in the RSM.Config
file. For details, see Accessing the RSM Database Configuration File (p. 27).
4.1. Types of RSM User Accounts

There are two types of RSM user accounts: primary accounts and alternate accounts.
Primary Account:
This is the main account used to communicate with RSMtypically, the account used with the client
application (ANSYS Workbench) on the RSM Client machine. By default, a primary account allows the
user to send jobs via RSM to all of the Compute Servers.
Your RSM privileges determine whether you can create and edit accounts for other users, or only for
yourself. For details, see Required Permissions for Creating and Modifying User Accounts (p. 49).
Alternate Account:
An alternate account is necessary when a remote Compute Server machine does not recognize the
primary account you are using on the Client machine. By defining an alternate account that is associated
with your primary account, you can send jobs from your primary account (on the Client) to be run under
your alternate account (on the remote Compute Server).
Example: You are using your primary account to submit jobs from a Windows Client to a remote Linux
Compute Server, but the Compute Server does not recognize your Windows-based primary account.
To send jobs to that Compute Server, you need to create an alternate account that will be recognized
and then submit your jobs under that account.
Multiple alternate accounts can be created for each primary account; a primary account with one or
more alternate accounts is called an owner account.
Note that manager (localhost) must also be assigned to an alternate account if the primary account
cannot access the manager machine.
4.2. Required Permissions for Creating and Modifying User Accounts

Whether you can create and modify accounts for other users or only for yourself is determined by
whether you have RSM administrative privileges or non-administrative privileges. (Note that having
RSM administrative privileges is not the same as having administrative privileges on your machine.)
RSM Non-Administrative Privileges

You are not a member of the RSM Admins user group. With RSM non-administrative privileges, you
can create and modify accounts for only for yourself. Specifically, you can:
Create and remove your own primary and alternate accounts
Create and remove your own alternate accounts
Change the passwords for your own accounts
Change the assignment of Compute Servers to your own alternate accounts
49
RSM Administrative Privileges

You are a member of the RSM Admins user group. With RSM administrative privileges, you can create
and modify accounts for users other than yourself. Specifically, you can:
Create and remove primary and alternate accounts
Modify any account
Change the password for any account
Change the assignment of Compute Servers to any alternate account
For more information, see Granting Administrative Privileges for RSM (p. 50).
Granting Administrative Privileges for RSM

To provide a user with administrative privileges for RSM, you must add the user to the RSM Admins
user group. If the group does not already exist, you must create it manually.
To create and add users the RSM Admins user group:
1. In the Windows Start menu or Windows Explorer, right-click Computer and select Manage.
2. On the Computer Management dialog box, expand Local Users and Groups.
3. Right-click the Groups folder and select New Group.
4. On the New Group dialog box, enter RSM Admins as the Group Name and add members by clicking the
Add button.
5. On the Select Users, Computers, Service Accounts, or Groups dialog box:
Type in user names.
Click the Check Names button to check and select each name.
6. Click the Create button to create the new group.
You can view RSM user account and password information in the RSM.Config file. For more information,
see Accessing the RSM Database Configuration File (p. 27).
4.3. Adding a Primary Account

A primary account enables a user to send jobs via RSM to all of the Compute Servers.
To add a primary account:
1. In the RSM tree view, right-click the Manager node (in our example, this is My Computer) and select Accounts from the context menu.
2. In the Accounts dialog box, click Add Primary Account.
50
Adding a Primary Account
3. In the Adding Primary Account dialog box, specify account user name and password.
Enter a user name for the account (in our example, username_02).
If a primary account has not been defined for the user name youve used to log into your machine,
the User Name field will be populated with your current user name and will be read-only.
Enter and verify the password for the account. See Working with Account Passwords (p. 54) for details.
Click OK.
4. Back in the Accounts dialog box, the new primary account has been added to the Accounts list.
51
Note
You can create primary accounts for other users only via the Accounts dialog box, as described
above. You can create primary accounts for yourself via the Accounts dialog box or either of the
following methods:
Run the RSM password application manually. For details, see Manually Running the Password
Application (p. 57).
In Workbench, select Tools > Enter Credentials for Remote Solve Manager. For details, see
Entering Credentials for Your RSM Alternate Accounts in the Workbench User's Guide.
If the primary account cannot access a Compute Server or the manager machine, you must assign
it to an alternate account. See Adding Alternate Accounts (p. 52).
4.4. Adding Alternate Accounts

An alternate account is necessary when a remote Compute Server machine does not recognize the
primary account you are using on the Client machine.
Important
You will need to create an alternate account on a Windows RSM Manager when integrating
it with a Linux Compute Server, so that the Windows Manager can run the job on the Linux
Compute Server using the correct Linux credentials.
To add an alternate account to a primary account:
1. In the Accounts dialog box, right-click the primary account and select Add Alternate Account.
52
Adding Alternate Accounts
2. In the Adding Alternate Account dialog box, specify account details.

Enter a user name for the account (in our example, un02_alltest).
Enter and verify the password for the account. See Working with Account Passwords (p. 54) for details.
Click OK.
3. Back in the Accounts dialog box, specify the Compute Servers to which the new alternate account will
have access.
In the Alternates list, select the newly created alternate account.
In the Compute Servers list, select the check box for each Compute Server to which the account will
send jobs. (In our example, weve selected three test servers for alternate account un02_alltest).
53
Note
Each alternate account can have access to a different combination of Compute Servers,
but each Compute Server can only be associated with one alternate account at a time.
Click Done.
In the RSM Accounts dialog box, select a primary account to view its alternate accounts. Select an alternate account to view the Compute Servers to which it can send jobs.
Note
It is also possible to add alternate accounts via either of the following methods:
In Workbench, select Tools > Enter Credentials for Remote Solve Manager. For details,
see Entering Credentials for Your RSM Alternate Accounts in the Workbench User's Guide.
4.5. Working with Account Passwords

This section addresses the following password-related topics:
4.5.1. Setting an Account Password
4.5.2. Changing an Account Password
4.5.3. Manually Running the Password Application
4.5.1. Setting an Account Password

If you will be sending jobs from an account on RSM Client machine to a remote RSM Manager machine,
you must set the account password in RSM. When you set the password, it is cached with the remote
54
Working with Account Passwords

RSM Manager machine. The RSM Manager can then run jobs on a Compute Server on behalf of that
account.
When you need to set your password, a Set Password reminder is displayed on the RSM Manager node
(in the example below, My Computer) in the RSM tree view. This reminder is shown when:
You need to set the account password when you first configure RSM, and the Client and RSM Manager are
on different machines.
You need to reset the password for the primary account of the currently logged-in user because the primary
account has been removed.
To set an account password:

1. In the RSM tree view, right-click My Computer [Set Password] and select Set Password.
2. On the Set Password dialog box, the User Name will be auto-populated with the DOMAIN\username of
the account under which youre currently logged in. Enter and verify the account password.
3. Click OK.
4. If the [Set Password] reminder is still displayed in the tree view, exit the RSM main window and relaunch
it to refresh the indicator to the correct state.
Note
It is not necessary to cache your password with the RSM Manager in the following situations:
The Client and RSM Manager are the same machine.
You are using RSM only for local background jobs.
Youve created a new account via the Accounts dialog box. When you set the password
during the creation of the account, it is automatically cached with RSM. The RSM Manager
encrypts and stores the password in a list of registered accounts.
55

The account is the root user account on Linux. For security reasons, RSM will not allow any
job to be run by a Linux root user account, so you should not need to cache the root account
password with the RSM Manager.
Note
It is also possible to set a password via either of the following methods:
4.5.2. Changing an Account Password

Given adequate privileges, you can change an account password at any time. Note that whenever a
password is changed outside of RSM, you must also change the password inside RSM (that is, to cache
the new password with RSM as described in Setting an Account Password (p. 54).
To change an account password:
1. In the RSM tree view, right-click the RSM Manager node and select Accounts.
2. In the Accounts dialog box, right-click the account in either the Accounts or Alternates list and select
Change Password.
3. Depending on the type of account youve selected, either the Changing Account Password or the
Changing Alternate Account Password dialog box will be displayed. The User Name field will be autopopulated with the DOMAIN\username of the selected account. Enter and verify the password.
4. Click OK.
5. If the [Set Password] reminder is still displayed in the tree view, exit the RSM main window and relaunch
it to refresh the indicator to the correct state.
Note
It is also possible to change a password via either of the following methods:
In RSM, use the right-click menu to open the Set Password dialog box. If the password is
already set, entering a password into this dialog box changes the password.
56
Configuring Linux Accounts When Using SSH
4.5.3. Manually Running the Password Application

It is usually unnecessary to manually run the password caching 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.
It is possible to stop and restart the RSM interface via the Ans.RSM.Password.exe password application, located in the [RSMInstall]\bin directory. The instructions provided in this section are included in the event that a general solution is desired.
Windows
You can run the password application directly by locating Ans.Rsm.Password.exe in the [RSMInstall]\bin directory and double-clicking it.
Linux
You can open the password application by running the rsmpassword shell script, located in the
[RSMInstall]\Config\tools\linux directory.
If you run the script with no command options, it displays available options as below:
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.
Note
The rsmpassword shell script depends on its relative location in the Workbench installation; it should not be moved.
Alternate accounts are typically added to the owner account via the Accounts dialog box, but can also
be manually added and edited by running the password application. In the example below, DOMAIN\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 (DOMAIN\johnd):johndoe
Enter password for DOMAIN\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 DOMAIN\johnd.
4.6. Configuring Linux Accounts When Using SSH

If the Windows and Linux account names are the same (for example, DOMAIN\johnd on Windows and
johnd on Linux) then no additional configuration is required. If the account name is different, specify
the account in the Linux Account property on the SSH tab of the Compute Server Properties dialog
box.
57

Client applications may also have a mechanism to specify an alternate account name. For example, you
can specify a Linux account in the ANSYS Workbench Solve Process Settings Advanced dialog box.
Remember that SSH must be configured for password-less access (see Appendix B (p. 119)). RSM does
not store Linux passwords for use with SSH.
58
Chapter 5: RSM 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 the jobs of any user.
RSM administrators must fulfill one of the following requirements:
Windows:
The RSM administrator is a Windows administrator on the RSM Manager machine (that is, they are in
the local or domain administrators group).
The RSM administrator has been added as a member of the RSM Admins group on the RSM Manager
machine.
Linux:
The RSM administrator is a root user.
The RSM administrator has been added as a member of the rsmadmins group on the RSM Manager
machine.
Note
In both of the above cases, the RSM services ANSYS JobManager Service V16.0 and
ANSYS ScriptHost Service V16.0 may need to be restarted in order for administrator
privileges to take effect.
RSM configuration data, including the configurations for the RSM Manager, Compute Servers, and
queues, is stored in the RSM.Config file. For details, see Accessing the RSM Database Configuration
File (p. 27).
The following RSM administration tasks are discussed in this section:
5.1. Automating Administrative Tasks with the RSM Setup Wizard
5.2. Working with RSM Administration Scripts
5.3. Creating a Queue
5.4. Modifying RSM Manager Properties
5.5. Adding a Compute Server
5.6.Testing a Compute Server
5.1. Automating Administrative Tasks with the RSM Setup Wizard

The ANSYS Remote Solve Manager Setup Wizard is a utility designed to guide you through the process
of setting up and configuring Remote Solve Manager. The setup tasks addressed by the wizard include
adding and managing RSM Managers, Compute Servers, queues, and accounts. It also allows you to
test the final configuration.
59
RSM Administration
For information on using the wizard, see Using the RSM Setup Wizard (p. 8).
5.2. Working with RSM Administration Scripts

Sometimes it is more convenient to work with RSM manually, rather than via the user interface. In addition to allowing you to manually run the password application, RSM provides you with a way to
manually open the main RSM window and start the RSM Utility application.
Opening the Main RSM Window Manually
For Windows, you can open the main RSM administration window directly by locating Ans.Rsm.Admin.exe in the [RSMInstall]\bin directory and double-clicking it.
For Linux, you can open the main RSM administration window by running the rsmadmin shell
script, located in the [RSMInstall]\Config\tools\linux directory.
Starting the RSM Utility Application Manually
For Windows, you can start the RSM Utilities application by opening a command prompt in the [RSMInstall]\bin directory and running rsm.exe. The example below shows available command line options.
The -s configFile command option can be used to create a backup file containing configuration
information for each of the queues and Compute Servers you have defined. For example, in the
event that you would need to rebuild a machine, you can run this script beforehand. The backup
file, configFile, is created in the [RSMInstall]\bin directory and can be saved as a .txt
file. Once the machine is rebuilt, you can then use the saved configuration file to reload all the
previously defined queues and Compute Servers, rather than having to recreate them.
The -migrate vVer command option enables you to migrate the existing RSM database into
the newer release without having to set up your RSM queues and Compute Servers again.
Note
In order to use the -migrate vVer command, you must first start the RSM Manager
service or process.
The migration can also be achieved by running the RSM Setup wizard to set up RSM
as a SYSTEM user and then running the rsm.exe migrate vVer command via
the command prompt.
C:\Program Files\ANSYS Inc\v160\RSM\bin>rsm.exe
Usage: rsm.exe [-m manager|machine][-clr]
[-c configFile|-s configFile|-migrate vVer]
[-stop mgr|svr|xmlrpc|all [-cancel]][-status mgr|svr]
-m manager:
RSM Manager machine (default = localhost).
-c configFile:
File containing Queues and Servers.
-s configFile:
File to save Queues and Servers.
-clr:
Clear Queues and Servers.
If used with -c, clears before configure.
-stop mgr|svr|xmlrpc|all: Stop RSM services, where:
mgr = Manager, svr = ScriptHost,
xmlrpc = XmlRpc Server, all = All three.
-cancel
Cancel all active Jobs. For use with -stop.
-status mgr|svr:
Query Manager and ScriptHost on localhost or use -m option.
-migrate vVer:
Migrate database from previous version (ex. v145).
Can be used with -clr.
60
Creating a Queue
For Linux, you can open the main RSM window by running the rsmutils shell script, located in
the [RSMInstall]\Config\tools\linux directory. The rsmutils shell script has the same
command options noted above for Windows.
Note
The Linux shell scripts are dependent on their relative location in the ANSYS Workbench installation, so cannot be moved.
5.3. 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 the Queues node for a desired RSM Manager.
2. Select Add. The Queue Properties dialog box displays:
3. Configure the Queue Properties described below, then select OK.

The table below lists the fields on the Queue Properties dialog box:
Property
Description
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 (for example, "Night Time Only").
61
RSM Administration
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
Possible values are 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
Select the check box for each Compute Server to be 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.4. Modifying RSM Manager Properties

To modify RSM Manager properties:
1. In the tree view, right-click a Manager node.
2. Select Properties. The Solve Manager Properties dialog box appears:
3. Modify RSM Manager properties described below, and then click OK.
The table below lists the editable fields on the Solve Manager Properties dialog box:
Property
62
Description
Modifying RSM Manager Properties

Job
Cleanup
Period
The length of time (in D.H:MM:SS format) that a job remains in the list
view based on its status. You can set a different time period for
finished, failed, and cancelled jobs. For example, you may want to set
a longer time period for jobs that have failed so that you have ample
time to troubleshoot them, and a shorter time period for jobs that
have finished successfully to prevent an excessive number of jobs
from accumulating in the list view.
Clearing out jobs in a timely manner improves the performance of
the RSM Manager and optimizes memory usage.
Default values are as follows:
Finished jobs: 02:00:00 (2 hours)
Failed jobs: 1.00:00:00 (1 day)
Cancelled jobs: 00:10:00 (10 minutes)
When specifying a time period, the following values are acceptable:
D (days) = integer indicating the number of days
H (hours) = 023
MM (minutes) = 059
SS (seconds) = 059
You can enter only the number of days (without the zeros), only the
hours/minutes/seconds, or both.
Examples:
1.00:00:00 or 1 = one day.
1.12:00:00 = 1.5 days
02:30:00 = 2.5 hours
00.15.00 = 15 minutes
Project
Directory
The base location where the RSM Manager stores input and output
files for a job. As jobs are created, a unique subdirectory for each job
is created in the Project Directory.
When defining the location of your Project Directory, you can enter
either a path or an environment variable in the format %VAR%. If you
enter a path to a base location that does not exist on the RSM Manager
machine, RSM will automatically create the path on the machine. This
location can be either on the local disk of the RSM Manager machine
or on a network share.
Example of local absolute path: E:\Users\username\work\cfdproj
63
RSM Administration
Example of network share path: \\fileserver\RSMProjects
Example of environment variable: %HOME%\Projects
When a job is stopped abruptly rather than released (for instance, via
the Abort option in the right-click context menu of the List view) or
is not released immediately, you may need to take additional steps
to ensure that its files are deleted from the Project Directory on the
RSM Manager. You can ensure that job-specific files are deleted by
one of the following two methods:
Remove the job from the List view. You can do this by right-clicking
the job and selecting Remove from the context menu. Alternatively,
you can highlight the job and either select the Tools > Remove
option or press the Delete key.
Configure the system to remove the files automatically by setting
the Job Cleanup Property in the Solve Manager Properties dialog
box.
Compression The threshold at which files are compressed prior to transfer.
Threshold
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.
Example: If you set this value to 50, files greater than 50 MB will be
compressed before being sent over the network.
5.5. Adding a Compute Server

A Compute Server is the machine on which the RSM Compute Server process runs. It executes the jobs
that are submitted by the RSM Client and distributed by the RSM Manager. You can add and configure
a new Compute Server via the Compute Server Properties dialog box. Once a Compute Server has
been added, you can also use this dialog box to edit its properties.
To add a new Compute Server:
1.
In the RSM Manager tree view, right-click the Compute Servers node under the machine you are designating as the RSM Manager.
2.
Select Add from the context menu. The Compute Server Properties dialog box displays.
The dialog box includes the following tabs:

The General tab contains properties that are used for all RSM configurations. See Properties on the General
Tab (p. 65).
The Remote tab contains properties that are used only when your Compute Server and RSM Manager are
on different machines and you are not using a cluster. See Properties on the Remote Tab (p. 70).
The Cluster tab contains properties that are used only if you are using a cluster. See Properties on the Cluster
Tab (p. 71).
64
Adding a Compute Server

The File Management tab contains information that is used whenever there will be file transfers between
different machines in the RSM configuration. See Properties on the File Management Tab (p. 72).
With the exception of the General tab, the tabs are displayed conditionallythey are dependent on
your property selections on the General tab, so that only the tabs relevant to your specific configuration
are shown.
On a given tab, some properties are also displayed conditionally, according to your selections for other
properties. For details on specific properties, see Compute Server dialog box Properties (p. 65).
To configure the new Compute Server, go to each tab and enter or select property values according to
your intended configuration.
Note
If you do not have permissions to a Compute Server machine (that is, you have not set your
account password in RSM for the Manager node), you cannot add the machine as a Compute
Server or edit its properties. For instructions on setting your password, see Working with
Account Passwords (p. 54).
5.5.1. Compute Server dialog box Properties

This section is a reference guide for the properties that may be displayed on the following Compute
Server Properties dialog box tabs:
5.5.1.1. Properties on the General Tab
5.5.1.2. Properties on the Remote Tab
5.5.1.3. Properties on the Cluster Tab
5.5.1.4. Properties on the File Management Tab
5.5.1.1. Properties on the General Tab

The General tab contains properties that are relevant to all types of RSM configurations. Conditional
properties are marked by an asterisk (*).
Display Name
Required. Enter a descriptive name or the Compute Server machine. It is an easy-to-remember alternative
to the Machine Name, and is the name that is displayed in the RSM Manager tree view.
The Display Name defaults to first to New Server and thereafter to New Server n to guarantee
its uniqueness. Examples of default display names include New Server, New Server 1, and
New Server 2.
Examples of display names you might select are Bobs Computer and My Computer to
Linux.
Machine Name
Required. Enter the name (the hostname or IP address) of the Compute Server machine. Both RSM and the
application being used (for example, ANSYS Mechanical or Fluent) must be installed on this machine. This
is a required field.
If the Compute Server is the same physical machine as the RSM Manager, enter localhost or the
machine name of the RSM Manager. If it is a different machine, enter the remote machine name.
65
RSM Administration
Examples of machine names for remote machines are comp1, comp1.win.domain.com, and
100.10.87.465.
This Compute Server is integrating with an HPC cluster
Specify whether the Compute Server being defined will be integrated with a cluster.
What is the role of [machinename]?*
Displays only when the Compute Server is not being integrated with a cluster.
Specify the role of the Compute Server being configured. Available options are:
Performs Computational Work: RSM jobs are actually executed on the Compute Server.
Communicates with remote computer which performs the work (e.g. SSH): The Compute
Server does not actually execute the jobs, but communicates with the machine that does via SSH
or another external (non-RSM) method.
How does [machinename] communicate with the cluster?*
Displays only when the Compute Server is being integrated with a cluster.
Specify the method of communication to be used between the Compute Server and the cluster.
Available options are:
Able to directly submit and monitor cluster jobs: The Compute Server can submit and monitor
cluster jobs directly, so files are transferred via network share or reuse of the Client or RSM Manager
directory that is shared to the cluster.
Uses non-RSM communication to a remote cluster node (e.g. SSH): The Compute Server requires
SSH to communicate with the node in the cluster. Files can be transferred by network share, reusing
the Client or RSM Manager shared directory, or an external mechanism (SSH).
Working Directory Location*
The Working Directory houses temporary job directories that are created by the Compute Server when
jobs are run. These job directories contain job scripts and solution files. This property specifies how the
location of the Working Directory is determined. This property may or may not be automatically determined
depending on how cluster and file management settings have been defined.
Possible options are:
66
User Specified
Enables you to explicitly specify the path to a Compute Server directory

to be used as a container for job sub-directories.
Shared Cluster
Directory
Signifies that the Compute Server working directory is the same as the
Shared Cluster Directory specified on the File Management tab.
Cluster Network
Share
Signifies that the Compute Server working directory is the same as what
is specified in the Cluster Network Share field under the Existing
Network Share option on the File Management tab. This is used in a
clustered setup when Uses non-RSM communication to remote cluster
node (e.g. SSH) is selected.
Network Share
Signifies that the Compute Server working directory is the same as what
is specified in the Network Share field under the Existing Network
Share option on the File Management tab. This is used in a
non-clustered setup when Communicates with a remote computer
which performs the work (e.g. SSH) is selected.

Reuse Manager
Storage
Specifies that you want to reuse the RSM Manager's project storage
directory as the working directory.
The choice between User Specified and Reuse Manager Storage exists only when the Compute
Server is the same as the RSM Manager machine, and either:
The role of the Compute Server is set to Performs Computational Work, which means that jobs will
run on the same machine as the RSM Manager.
or
The role of the Compute Server is set to Communicates with a remote computer which performs the
work (e.g. SSH), and the file transfer method on the File Management tab is not set to Existing Network
Share (Samba, CIFS, NSF).
If the Compute Server is not the same as the RSM Manager machine, but either of the above conditions is true, then only the User Specified option is available.
Otherwise, this property is automatically preset to either Shared Cluster Directory, Cluster Network
Share or Network Share according to the file transfer method and settings specified on the File
Management tab, and whether or not the Compute Server is used to run cluster jobs.
Working Directory Path*
This is the actual path to the Working Directory whose general location is determined by the Working
Directory Location property.
If the Working Directory Location property is set to User Defined, enter a path for the Working
Directory on the Compute Server machine. You can enter either an absolute local path (for example,
C:\RSMTemp) or an environment variable in the format %VAR% (for example, %TMP%).
If you will be using a native cluster configuration (that is, will not be using SSH), essentially you are
indicating that the Working Directory and the Shared Cluster Directory are the same location. As
such, the Working Directory Path property is populated with the path entered for the Shared
Cluster Directory property.
When the Compute Server and RSM Manager are two different machines, for each job that runs, a
temporary subdirectory is created in the Compute Server Working Directory. This subdirectory is
where job-specific scripts, input files, and output files are stored. When the job completes, output
files are then immediately transferred back into the Project Directory on the RSM Manager machine.
Requirements:
The Working Directory must be located on the Compute Server machine (the machine specified in the
Machine Name field).
All RSM users must have write access and full permissions to this directory.
If you will be using a cluster configuration, the directory must be shared and writable to all of the nodes
in the cluster.
67
RSM Administration
Note that in some cluster configurations, the Working Directory may also need to exist on each cluster
node and/or may share the same physical space as the Shared Cluster Directory. Examples of Working
Directory paths are D:\RSMTemp and C:\RSMWorkDir.
Note
In a configuration where the Compute Server and RSM Manager are the same machine (that
is, the job is queued from and executed on the same machine), and the Reuse Manager
Storage option has been selected for the Working Directory Location property, the job
execution files are stored directly in the Project Directory on the RSM Manager, rather than
in the Working Directory on the Compute Server. This conserves disk space on the Compute
Server.
In a native cluster configuration (that is, you are not using SSH), when you specify that you
want to use the Shared Cluster Directory to store temporary solver files, essentially you are
indicating that the Working Directory and the Shared Cluster Directory are the same location;
as such, the Working Directory property is populated with the path entered for the Shared
Cluster Directory property in the Cluster tab. See the descriptions of the Shared Cluster
Directory and File Management properties.
Server Can Accept Jobs
Specify whether the Compute Server can accept jobs. Selected by default.
Leave selected to indicate that the Compute Server can accept jobs.
Deselect to prevent jobs from being run on this Compute Server. Primarily used when the server is offline
for maintenance.
The Server Can Accept Jobs property can also be set on the client side (that is, on the RSM Client
machine via the Workbench Update Design Point Process properties). This can be done both in
scenarios where the RSM Manager runs locally on the same machine as the RSM Client, and in
scenarios where the RSM Manager is run remotely on a different machine. In either case, the Server
Can Accept Jobs value set on the server side (that is, on the remote Compute Server machine)
takes precedence.
Maximum Number of Jobs
Specify the maximum number of jobs that can be run on the Compute Server at the same time. When this
number is reached, the server is marked as Busy.
The purpose of the Maximum Number of Jobs property is to prevent job collisions, which can
occur because RSM cannot detect the number of cores on a machine. The ability to determine a
maximum number of jobs is particularly useful when the job is simply forwarding the work to a
third-party job scheduler (for example, to an LSF or PBS Pro cluster). Default value is 1.
In a cluster configuration, this property refers to the maximum number of jobs at the server level,
not at the node/CPU level.
The Maximum Number of Jobs property can also be set on the client side (that is, on the RSM
Client machine via the Workbench Update Design Point Process properties). This can be done
both in scenarios where the RSM Manager runs locally on the same machine as the RSM Client, and
in scenarios where the RSM Manager is run remotely on a different machine. In either case, the
Maximum Number of Jobs value set on the server side (that is, on the remote Compute Server
machine) takes precedence.
68

When multiple versions of RSM are being run at the same time (for example, 13.0 and 14.0), this
property applies only to the current instance of RSM. One version of RSM cannot detect the jobs
being assigned to a Compute Server by other versions.
Limit Job Times for Submission
Specify whether there will be limitations on the times when jobs can be submitted to the Compute Server.
Deselected by default.
Leave the check box deselected for 24-hour availability of the Compute Server.
Select the check box to specify submission time limitations in the Start Time and End Time fields. This
option is primarily used to limit jobs to low-load times or according to business workflow.
Start Time / End Time
Enabled when the Limit Times for Job Submissions check box is selected. These properties allow you to
specify a time range during which the Compute Server is available to accept submitted jobs. The Start
Time property determines when the Compute Server becomes available and the End Time property determines when it becomes unavailable to accept job submissions.
A job cannot be run on a Compute Server if it is submitted outside of the Compute Servers range
of availability. The job may still be queued to that Compute Server later, however, when the Compute
Server again becomes available to accept it. Also, if there are multiple Compute Servers assigned
to a queue, a queued job may still be submitted to another Compute Server that is available to
accept submissions.
It can be useful to define an availability range when Compute Servers or application licenses are
only available at certain times of the day.
You can either enter the time (in 24-hour HH:MM:SS format) or select a previously entered time from
the drop-down list.
Do not indicate 24-hour availability by entering identical values in the Start Time and End Time
fields; doing so will cause an error. Instead, indicate unlimited availability by deselecting the Limit
Times for Job Submissions check box.
Save Job Logs to File
Specify if job logs should be saved as files. Deselected by default.
Leave the check box deselected to specify that no job log files will be saved.
Select the check box to save job log files.
When a job runs, a log file named RSM_<ServerDisplayName>.log is saved to the TEMP directory on the RSM Manager machine unless the TMP environment variable has been defined; in
this case, job log files are saved to the location defined in the TMP environment variable.
Note
To access the default TMP directory for Windows, go to %TMP% in Windows Explorer
or to /tmp in Linux.
Selecting this option could potentially increase disk usage on the RSM Manager.
69
RSM Administration
Job log files are primarily used for troubleshooting. The log file for a job contains the same information displayed on the Job Log view when the job is selected in the List view of the main RSM application window.
When this option is enabled, the log file on disk is updated/saved only when a job finishes running.
The user can always see the same live log from the RSM user interface when the job is running.
Delete Job Files in Working Directory
Specify whether the temporary job subdirectories created in the Compute Server Working Directory are
deleted upon completion of the associated job. Selected by default.
Leave the check box selected to delete temporary job subdirectories and their contents upon completion
of the associated job.
Deselect the check box to save temporary job subdirectories and their contents after the completion of
the associated job.
The job files in the Working Directory are primarily used for troubleshooting. When a submitted job
fails, saved job-specific scripts and files can be helpful for testing and debugging. You can find these
files by looking at the RSM log (either in the Job Log view of the main application window or in
the job log file saved to the Working Directory on the RSM Manager machine) and finding the line
that specifies the Compute Server Working Directory.
If the Compute Server Working Directory shares (or reuses) the RSM Manager Project Directory, the
Compute Server Working Directory will not be deleted until the RSM Manager Project Directory is
deleted. This does not occur until a job is released by the client and its cleanup period expires. The
Job Cleanup Period is specified in the Solve Manager Properties (see Modifying RSM Manager
Properties (p. 62)).
Note that if the RSM Manager Project Directory shares the client working directory, then the RSM
Manager Project Directory will not be deleted until the client working directory is deleted by RSM
clients such as Workbench or EKM.
Use SSH protocol for inter- and intra-node communication (Linux only)
Specify whether RSM and solvers use RSH or SSH for inter-node and intra-node communications on Linux
machines. Deselected by default.
Leave the check box deselected to use RSH.
Select the check box to use SSH.
This setting will be applied to all Linux Compute Servers, not only those in clusters, allowing for
solvers to run in distributed parallel mode on a single machine.
When ANSYS Fluent, ANSYS CFX, ANSYS Mechanical, and ANSYS Mechanical APDL are configured
to send solves to RSM, their solvers will use the same RSH/SSH settings as RSM.
5.5.1.2. Properties on the Remote Tab

The Remote tab contains properties that are relevant only when your Compute Server is a remote
machine on a different platform than the RSM Manager and will not be communicating with a cluster.
Remote Computer
Enter the name of the remote machine on which jobs will be executed. Also select the platform.
70

Account Name
Enter the name of the user account that will be used to access the remote machine. For more information,
see RSM User Accounts and Passwords (p. 47).
5.5.1.3. Properties on the Cluster Tab

The Cluster tab contains properties that are relevant only when the Compute Server will be integrated
with a cluster. Conditional properties are marked by an asterisk (*).
Cluster Node*
Displayed only when a non-RSM mode of communication (such as SSH) is being used for the cluster.
Enter the machine name of the cluster node (that is, the machine with which the Compute Server
will communicate). Also allows you to specify the platform of the cluster node, when it is different
than that of the Compute Server.
Account Name*
Displayed only when a non-RSM mode of communication (such as SSH) is being used for the cluster.
Enter the user account that will be used to access the cluster node.
Cluster Type
Select the type of job scheduling system that will be used to manage the cluster.
The following options are available:
None: Selected by default. Leave selected if you wont be using a job scheduler for cluster management.
When this option is selected, the rest of the properties on the tab are disabled.
Windows HPC: Select to use MS HPC. When this option is selected, the SSH tab is disabled because SSH
is applicable only to Linux cluster configurations.
LSF: Select to use LSF.
PBS Pro: Select to use PBS Professional.
TORQUE with Moab: Select to use TORQUE Resource Manager when integrated with Moab Workload
Manager. Note that integration of TORQUE with other workload managers is not supported by RSM.
UGE (SGE): Select to use UGE or SGE.
Custom: Select to customize RSM integration. See Customizing RSM (p. 75).
Parallel Environment (PE) Names*
Displayed only when UGE (SGE) is selected for Cluster Type. Required when enabled.
Enter the names of the Shared Memory Parallel and Distributed Parallel environments. These
environments must have already been created by your cluster administrator.
Defaults are set as pe_smp and pe_mpi. To use one of the default names, your cluster administrator
must create parallel environments with these names.
Please consult your cluster system administrator to ensure that parallel environments have been
set up properly before running jobs. Otherwise, jobs may fail.
71
RSM Administration
Custom Cluster Type*
Displayed only when Custom is selected for Cluster Type.
Enter the type of custom cluster being used.
[scheduler] Job Submission Arguments
Optional.
Enter scheduler-specific arguments that will be added to the job submission command line of your
third-party job scheduler. For example, you can enter job submission arguments to specify the
queue (LSF, PBS, SGE) or the nodegroup (MS HPC) name. For valid entries, see the documentation
for your job scheduler.
5.5.1.4. Properties on the File Management Tab

The File Management tab contains properties that are used whenever there will be file transfers
between different machines in the RSM configuration. Conditional properties are marked by an asterisk
(*).
How do files get to/from Remote Computer?*
Displayed only when the Compute Server communicates with a remote machine that will execute the jobs.
Specify the file transfer method to be used between the Compute Server and the remote machine.
Network Share*
Displayed when files are transferred via network share between the Compute Server and the remote machine.
Enter the name of the network share to be used.
Remote Directory*
Displayed when files are transferred either via a network share or an external mechanism (such as SSH)
between the Compute Server and the remote machine.
Enter the path of the remote directory on remote machine used to run jobs.
How do files get to the cluster shared directory?*
Displayed only when the Compute Server will be integrated with a cluster.
Specify the file transfer method to be used to communicate with the cluster head node.
Cluster Network Share*
Displayed only when files are transferred via network share between the Compute Server and the cluster
node.
Enter the path to the network share used to transfer files between the Compute Server and the
cluster node. You can enter the path of the network share manually, or can enter an environment
variable in the format %VAR%.
Shared Cluster Directory*
Displayed only when files are transferred via network share between the Compute Server and the cluster
node.
72
Testing a Compute Server

Enter the path to the shared cluster directory used to share files within the cluster. You can enter
the path of the shared cluster directory manually, or can enter an environment variable in the format
%VAR%.
Note
For Linux, spaces in the Shared Cluster Directory path are not supported because Linux
does not provide full support for spaces in shared NFS directories.
Remote Shared Cluster Directory*
Displayed only when files are transferred via an external mechanism (such as SSH) between the Compute
Server and the cluster.
Enter the path to the remote shared cluster directory used to transfer files between the Compute
Server and the cluster. You can enter the path of the remote shared cluster directory manually, or
can enter an environment variable in the format %VAR%.
In which directory does the cluster job run?
Select one of the following options to indicate the directory in which the cluster job will run.
In the shared cluster directory
This option is recommended when one or more of the following is true:
You are using a native cluster setup (that is, you are not using SSH).
You have a fast network connection between the execution nodes and the Shared Cluster Directory.
You are using a solver that produces fewer, relatively small files as part of the solution and does not
make heavy use of local scratch space (for example, the CFX or the Fluent solver).
In a scratch directory local to the execution node
This option is recommended to optimize performance when one or both of the following is true:
You have a slower network connection between the execution nodes and the Shared Cluster
Directory.
You are using a solver that produces numerous, relatively large files as part of the solution and
makes heavy use of local scratch space (for example, Mechanical solvers).
Cluster Scratch Directory*
Displayed only when youve specified that cluster jobs will run in a scratch directory local to the execution
node.
Enter the path for a scratch directory on the execution node. You can enter the path of the scratch
directory manually, or can enter an environment variable in the format %VAR%.
5.6. Testing a Compute Server

To test a Compute Server configuration, right-click the Compute Servers node in the tree view and
select either Test or Advanced Test.
73
RSM Administration
If you select Test Server, this runs a test job on the Compute Server configuration, using the settings
provided.
If you select Advanced Test, a Test [computeservername] dialog box displays, allowing you to specify test
details in the following fields:
Client Directory for Test: Specify the directory in which the test job will be run. You can leave set to the
default (the %TEMP% environment variable) or enter a path or environment variable manually. Manually
entered items will be added as drop-down options.
Test Type: Specify the kind of Compute Server test that will be run. If you leave this field set to Basic (the
default), a standard test of the Compute Server configuration is performed. If you select File Transfer
Check, the test will verify that your files are being transferred successfully.
The List view indicates whether the test job is running, has finished, or has failed. Select the job in the
List view to view details in the Job Log below. A log message will indicate whether the test finished or
failed. If the test finishes, you can successfully run jobs on the Compute Server.
If you do not have full permissions to the Compute Server working directory, Compute Server tests will
fail. If tests fail, try deselecting the Delete Job Files in Working Directory check box on the General
tab of the Compute Server Properties dialog box. You can then examine the contents of the temporary
job directories for additional debugging information. When this option is deselected, RSM will keep the
temporary directories on the server after the job is completed. You can find the location of these temporary directories by looking for the line that specifies the "Compute Server Working Directory" in the
RSM log.
The test server job will always keep the temporary client working directory created by RSM on the client
machine, regardless of the Delete Files in Working Directory setting. You can find the location of the
temporary client working directory by looking for the line that specifies the "Client Directory" in the
RSM log.
74
Chapter 6: Customizing RSM

This section discusses various methods of customizing ANSYS Remote Solve Manager.
The following topics are addressed:
6.1. Understanding RSM Custom Architecture
6.2. Custom Cluster Integration Setup
6.3. Writing Custom Code for RSM Integration
6.1. Understanding RSM Custom Architecture

The [RSMInstall]\Config directory contains job templates, code templates, job scripts, and other
files that are used to define and control RSM jobs. The RSM architecture allows the user to customize
how jobs are executed on a cluster or Compute Server by providing a custom version of some of the
files. This section briefly describes the types of files used in the customization.
This section addresses each file type in the RSM customization architecture:
6.1.1. Job Templates
6.1.2. Code Templates
6.1.3. Job Scripts
6.1.4. HPC Commands File
6.1.5. Job Configuration File
6.1.1. Job Templates

Job Templates define the code template, inputs, and outputs of a job.
RSM job templates are located in the [RSMInstall]\Config\xml directory. Examples of job templates in this directory are GenericJob.xml, Workbench_ANSYSJob.xml, and Workbench_CFXJob.xml.
An example job template for a server test job is shown below:
<?xml version="1.0" ?>
<JobTemplate>
<script>ServerTestCode.xml</script>
<debug>TRUE</debug>
<cleanup>TRUE</cleanup>
<inputs>
<file type="ascii">*.in</file>
</inputs>
<outputs>
<file type="ascii">*.out</file>
</outputs>
</JobTemplate>
6.1.2. Code Templates

Code templates are used by the corresponding job template and determine which scripts will be used
to run a specific job. Code templates contain sections for the actual code files (job scripts), referenced
75
Customizing RSM
assemblies (.dlls), and support files. These code templates are chosen at runtime based upon the
job template and cluster type selected to run the job.
RSM code templates are located in the [RSMInstall]\Config\xml directory.
An example code template for a server test job is shown below:
<?xml version="1.0" ?>
<codeDefinition transfer="true" prebuilt="false" assemblyName="Ans.Rsm.Test.dll">
<codeFiles>
<codeFile>Test.cs</codeFile>
</codeFiles>
<references>
<reference>Ans.TestDlls.dll</reference>
<references/>
<supportFiles>
<supportFile transfer="true" type="ascii">TestingScript.py</supportFile>
<supportFiles/>
</codeDefinition>
6.1.3. Job Scripts

The job scripts for a particular type of job are defined in the <codeFiles> section from code template.
The term script refers generically to the code used for running the different types of RSM jobs, such as
native jobs, SSH jobs, cluster jobs, and so on. Depending on the Compute Server configuration, different
sets of scripts may also be compiled dynamically during the run time of the job. Job scripts also include
actual command scripts that you may provide to customize the cluster job behavior. These scripts are
included in the <supportFiles> section.
RSM job script files are located in the [RSMInstall]\Config\scripts directory.
Specialized job scripts for integrating RSM with third-party job schedulers are invoked based upon the
Cluster Type property on the Cluster tab of the Compute Server Properties dialog box. Your selection
from the Cluster Type drop-down is appended to the name of the base code template. These files are
generically in the format of GenericJobCode_<Keyword>.xml, but the exact format for every
cluster type keyword is defined in the jobConfiguration.xml file.
For example, if you set Cluster Type to LSF, then LSF will be your keyword, and RSM will look in the
jobConfiguration.xml file for the corresponding code template. It will find GenericJobCode_LSF.xml, which invokes the scripts necessary to run a test job on an LSF cluster.
If you chose a Cluster Type of Custom, then Custom is not used as the keyword. Rather, you are required
to provide a name for your Custom Cluster Type. This name will become your keyword, and you can
customize the cluster by adding a section for your new keyword in the jobConfiguration.xml file
which lists the files that you wish to apply to this custom type.
6.1.4. HPC Commands File

The cluster-specific HPC commands file is the configuration file used to specify the commands or
queries that will be used in the cluster integration. The file is in xml format and is located in
the [RSMInstall]\Config\xml directory. The default naming scheme is hpc_commands_<clustertype>.xml. When using a custom cluster type, you will need to provide a name for the HPC Commands
file that contains your changes in the jobConfiguration.xml file. It is not required to follow any naming
convention, but it is suggested that the file that matches your custom cluster type name in the format
hpc_commands_<keyword>.xml. This is also discussed in the setup sections of Custom Cluster Integration Setup (p. 78).
76
Understanding RSM Custom Architecture

The commands inside the HPC command file can point directly to cluster software specific commands
(like bsub or qstat). When the operations are more complex, the commands can reference scripts or
executables that call the cluster software functions internally. These scripts can be in any language that
can be run by the Compute Server. The HPC command file is described in greater detail in Custom
Cluster Integration Setup (p. 78).
6.1.5. Job Configuration File

The jobConfiguration.xml file, located in the [RSMInstall]\Config\xml directory, contains
the files that will be used for each job type. For every cluster job that is run, a <keyword> is used to
describe the job type. For example, LSF is used for a job running on an LSF cluster, and LSFSSH is
used for a job running on an LSF cluster that uses SSH. Each job type uses slightly different files to run
the job.
The jobConfiguration.xml file contains keyword entries for the following job types:
LSF, LSFSSH, LSFSMB
PBS, PBSSSH, PBSSMB
SGE, SGESSH, SGESMB
TORQUE, TORQUESSH, TORQUESMB
MSCC
RSM, RSMSSH, RSMSMB
YAC, YACSSH, YACSMB
CIS
Note
The RSM keyword entry is not yet valid for hpcCommands. It is available here so that you
can set the default jobCode for non-cluster jobs.
How Keyword Entries Work

Each keyword entry in the jobConfiguration.xml file includes a reference to the HPC commands
file (and/or Protocol) that is to be used for that job type. The <include> option is used to add more
HPC command files to the list, which enables you to reuse commands that are common to multiple job
types.
Below is the standard keyword entry for jobs running on an LSF cluster using SSH. The keyword for this
job type is LSFSSH. Commands from the uppermost file in the list, hpc_commands_LSF.xml, will
be used first. Subsequently, commands from the included hpc_commands_extensions_SSH.xml
file will be used. Duplicate commands in included file will be ignored (because it is not first in the list),
and commands that are not duplicates will be combined with those in the first file to form the complete
HPC commands file.
<keyword name="LSFSSH">
<jobCode name="GenericJobCode_base.xml">
</jobCode>
<hpcCommands name="hpc_commands_LSF.xml">
77
Customizing RSM
<include name="hpc_commands_extensions_SSH.xml"/>
</hpcCommands>
<protocol name="protocol_definition_SSH.xml"/>
</keyword>
If you want to customize the way jobs are run on a cluster, you will need to modify the jobConfiguration.xml file, either by editing existing keyword entries or adding new ones for each custom
cluster job type.
Customizing Cluster Job Type Entries

If you only want to make small changes to a cluster, and those changes apply to all users, projects and
groups, then editing one of the standard keyword entries may be sufficient.
For example, assuming that your cluster is most like a standard LSF cluster that uses SSH, you could
modify the existing LSFSSH keyword entry in the jobConfiguration.xml file. The modified entry
below references a new hpc_commands file, MyCustomChanges.xml, that contains changes to only
one or a few commands. The <include> option is used to include the original hpc_commands_LSF.xml and hpc_commands_extensions_SSH.xml files to make use of any standard
commands that are not present in the custom file. Commands in the MyCustomChanges.xml file
will be used first because it is at the top of the list, and any non-duplicate commands in the two included
files will be merged with those in the custom file to form the complete HPC commands file.
<keyword name="LSFSSH">
<jobCode name="GenericJobCode_base.xml">
</jobCode>
<hpcCommands name="YourCustomChanges.xml"> 
<include name=hpc_commands_LSF.xml/>
<include name="hpc_commands_extensions_SSH.xml"/>
</hpcCommands>
<protocol name="protocol_definition_SSH.xml"/>
</keyword>
If significant changes are to be made to the cluster, or there are different customization requirements
for different projects, groups, and so on, then you will need to add a custom keyword entry to the
jobConfiguration.xml file.
In the example below, a new entry has been created for jobs running on a custom cluster that has been
assigned the keyword CUSTOM. It references a custom HPC commands file, hpc_commands_CUSTOM.xml, as well as the standard hpc_commands_PBS.xml file.
<keyword name="CUSTOM">
<jobCode name="GenericJobCode_base.xml"/>
<hpcCommands name="hpc_commands_CUSTOM.xml">
<include name="hpc_commands_PBS.xml"/>
</hpcCommands>
</keyword>
For more information see Modifying the Job Configuration File for a New Cluster Type (p. 83).
6.2. Custom Cluster Integration Setup

ANSYS Remote Solve Manager (RSM) provides built-in functionality that allows Workbench jobs to be
submitted to a commercial cluster. The built-in functionality includes the ability to transfer files automatically to/from the cluster from a remote client and the ability to submit, cancel, and monitor Workbench jobs. The current supported commercial clusters are Linux LSF, Linux PBS Pro, Linux TORQUE
with Moab, Linux UGE (SGE), and Microsoft HPC (MSCC).
78
Custom Cluster Integration Setup

RSM also provides a custom cluster integration mechanism that allows third parties to use custom
scripts to perform the tasks needed to integrate Workbench with the cluster. The custom integration
scenarios can be grouped into the following categories in order of complexity:
Commercial clusters (listed above) for which the customers need some additional operation to be performed
as part of the RSM job execution. This is a type of server-side integration.
Unsupported clusters, not included in the list above, that the customers want to use for executing a job
via RSM. This is also a type of server-side integration.
Customers with specialized requirements that need to fully replace RSM functionality with 3rd-party scripts
for handling all aspects of job submission including file transfer. This is called client-side integration.
The terms server-side and client-side integration refer to the location (in the RSM architecture) where
the custom script files are going to be located.
In the typical RSM configuration with a (supported or unsupported) cluster, a Submission Host of the
cluster is typically configured as RSM Manager and Compute Server. The cluster acts as a Compute
Server with respect to the RSM client from where the jobs are submitted; therefore the customization
of RSM files on the cluster is referred to as server-side integration. For server-side integration, you must
be able to set up the RSM services on the cluster head node and file transfers should be handled by
RSM, using either network file shares or native RSM transfers. The methods of file transfer discussed in
Setting Up RSM File Transfers (p. 19) are available, except for SSH File Transfer (p. 27) and Custom Client
Integration (p. 27).
The client-side integration refers to the case where the RSM functionality is completely replaced by the
3rd-party scripts. In this case, the RSM Manager and Compute Server are located on the Client machine.
However, only a thin layer of the RSM architecture is involved, in order to provide the APIs for execution
of the custom scripts, which are located on the Client machine. The RSM services are not installed on
the cluster machine.
Note that for supported clusters it is also possible to include additional job submission arguments to
the command executed by the cluster. The addition of custom submission arguments does not require
the creation of custom scripts. For more details, refer to Properties on the Cluster Tab (p. 71).
The following sections describe the general steps for customization with server-side and client-side integration. The detailed instructions for writing the custom code are similar for the two cases. They are
addressed in Writing Custom Code for RSM Integration (p. 95).
The following topics are addressed:
6.2.1. Customizing Server-Side Integration
6.2.2. Customizing Client-Side Integration
6.2.3. Configuring File Transfer by OS Type and Network Share Availability
6.2.1. Customizing Server-Side Integration

RSM allows you to customize your integration with supported cluster types (LSF, PBS Pro, TORQUE with
Moab, HPC, and SGE) by starting with examples of production code for one of the standard cluster
types and then changing command lines or adding custom code where necessary. If an unsupported
cluster is being used, the recommended procedure is still to start from the example files for one of the
supported clusters. This section will walk through the process of how to integrate such changes into
RSM.
79
Customizing RSM
On the server-side RSM installation, you will need to log into the remote cluster (RSM Manager) machine
to perform all the tasks (steps 1 through 4). To override or modify selective cluster commands, you
must:
1. Configure RSM to use a cluster-specific code template.
2. Create copies of existing code and rename files using your new Custom Cluster Type keyword.
3. Add an entry to the job configuration file that associates your Custom Cluster Type keyword with
the cluster-specific hpc_commands_<keyword> file.
4. Edit the cluster-specific hpc_commands_<keyword> file to reference the code you want to execute.
The following sections discuss the steps needed for customizing your integration cluster:
6.2.1.1. Configuring RSM to Use a Cluster-Specific Code Template
6.2.1.2. Creating Copies of Standard Cluster Code Using A Custom Cluster Keyword
6.2.1.3. Modifying the Job Configuration File for a New Cluster Type
6.2.1.4. Modifying the Cluster-Specific HPC Commands File
6.2.1.1. Configuring RSM to Use a Cluster-Specific Code Template

On the server-side RSM installation, you will need to log into the remote cluster (RSM Manager) machine
to perform all the tasks (steps 1 through 4) in Customizing Server-Side Integration (p. 79).
After creating a new Compute Server, set up the Compute Server Properties dialog box under the
Cluster tab. You must set Cluster Type to Custom and create a short phrase/word in the Custom
Cluster Type as the custom cluster name. The name is arbitrary, but you should make it simple enough
to append to file names. This name will be referred to as the keyword from now on.
For supported clusters, you can include the original cluster name in the new custom name, for clarity.
For example, if your cluster is actually an LSF or PBS Pro cluster but you need to customize the RSM
interaction with it, you might use the keyword CUS_LSF or CUS_PBS. If the underlying cluster is
not a supported platform, it could be called CUSTOM or any other arbitrary name. The names are in
capital letters for simplicity, but the only requirement is that the capitalization is the same in all places
where this keyword is referenced.
A custom server integration means that you are running in non-SSH mode or (RSM is able to communicate directly and submit jobs). Thus, on the General tab of the Compute Server Properties dialog
box, you need to select Able to directly submit and monitor cluster jobs.
For File Management tab, see Configuring File Transfer by OS Type and Network Share Availability (p. 91)
for details on the different file transfer scenarios.
A full example of a typical cluster setup using the remote RSM Manager and custom properties is shown
below.
80
81
Customizing RSM
Note
The Shared Cluster Directory you choose must be readable and writable by all users of RSM
and also by rsmadmin. The Shared Cluster Directory must be shared between all nodes of the
cluster and must be mounted using the same name (with the same parent directories).
The Local Scratch Directory you choose must be readable and writable by all users of RSM. The
scratch directory should not be shared between nodes, but it should have the same name (and
parent directories) on all nodes.
If you want to have a configuration with a shared scratch directory, specify where the job will
be run by selecting In the shared cluster directory.
Refer to Adding a Compute Server (p. 64) for information about the properties in the General and
Cluster tabs of the Compute Server Properties dialog box.
6.2.1.2. Creating Copies of Standard Cluster Code Using A Custom Cluster Keyword
As part of the setup, you must create a custom copy of the xml file that contains the definition of the
HPC commands to be used for the job execution. As a starting point, you can copy existing RSM files
as shown below:
Locate the directory [ANSYS 16.0 Install]/RSM/Config/xml. Note that all the actions listed below
should be performed on the cluster installation.
Locate the commands file that pertains to your cluster type (for instance, if you are using PBS Pro, the file
is hpc_commands_PBS.xml).
Copy the content of the hpc_commands_PBS.xml file into a new file hpc_commands_<YOURKEYWORD>.xml. If your keyword for the custom cluster was CUS_PBS like the example in Configuring
82

RSM to Use a Cluster-Specific Code Template (p. 80), the new file should be called hpc_commands_CUS_PBS.xml.
Note
In order to use the native RSM cluster functionality (that is, using a fully supported cluster
type in your setup, such as LSF, PBS Pro, and so on), you must not change the file names or
contents of the corresponding cluster-specific templates provided by RSM. This can cause
those standard cluster setups to fail and will make it harder to start over if you need to
change something later on. Here we have created a custom cluster type, but used copies of
a standard template to start from; this is the recommended method.
As part of the setup, you must add an entry for your custom cluster keyword in the jobConfiguration.xml file, and reference the files that are needed for that cluster job type.
should be performed on the cluster installation.
Open the jobConfiguration.xml file and add an entry that follows the pattern shown in the sample
code below. This code corresponds to the example in preceding sections which assumes your cluster is
most like a PBS cluster.
<keyword name="YOURKEYWORD">
<hpcCommands name="hpc_commands_YOURKEYWORD.xml">
<include name="hpc_commands_PBS.xml"/>
</hpcCommands>
</keyword>

The command file prior to the modification is pasted below. While a detailed description of the command
is beyond the scope this documentation, it can be noted that the command file provides the information
on how actions related to job execution (submit a job, cancel a job, getting the job status) are executed.
The file also refers to a number of environment variables.
<jobCommands version="3" name="Custom Cluster Commands">
<environment>
<env name="RSM_HPC_PARSE">PBS</env>
<env name="RSM_HPC_JOBNAME">RSM</env>
<env name="RSM_HPC_PARSE_MARKER">START</env>
</environment>
<submit>
<precommands>
<command name="memory">
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY%/pbsMemory.py</pythonapp>
</application>
<arguments>
<arg>%RSM_HPC_MEMORY%</arg>
<arg>%%RSM_HPC_CORES%</arg>
</arguments>
<outputs>
<variableName>RSM_PBS_MEMORY_AMOUNT</variableName>
</outputs>
<condition>
<env name=RSM_HPC_MEMORY">ANY_VALUE</env>
<env name=RSM_HPC_DISTRIBUTED">FALSE</env>
83
Customizing RSM
</condition>
</command>
</precommands>
<primaryCommand name="submit">
<application>
<app>qsub</app>
</application>
<arguments>
<arg>
<value>-q %RSM_HPC_QUEUE%</value>
<condition>
<env name="RSM_HPC_QUEUE">ANY_VALUE</env>
</condition>
</arg>
<arg>
<value>-l select=%RSM_HPC_CORES%:ncpus=1:mpiprocs=1</value>
<condition>
<env name="RSM_HPC_DISTRIBUTED">TRUE</env>
</condition>
</arg>
<arg>
<value>-l select=1:ncpus=%RSM_HPC_CORES%:mpiprocs=%RSM_HPC_CORES%</value>
<condition>
<env name="RSM_HPC_DISTRIBUTED">FALSE</env>
</condition>
</arg>
<arg noSpaceOnAppend="true">
<value>:mem=%RSM_HPC_MEMORY%mb</value>
<condition>
<env name="RSM_HPC_MEMORY">ANY_VALUE</env>
</condition>
</arg>
<arg noSpaceOnAppend="true">
<value>:mem=%RSM_PBS_MEMORY_AMOUNT%</value>
<condition>
<env name="RSM_PBS_MEMORY_AMOUNT">ANY_VALUE</env>
</condition>
</arg>
<arg>
<value>-l place=excl</value>
<condition>
<env name="RSM_HPC_NODE_EXCLUSIVE">TRUE</env>
</condition>
</arg>
<arg>-N "%RSM_HPC_JOBNAME%" %RSM_HPC_NATIVEOPTIONS% -V -o "%RSM_HPC_STAGING%/%RSM_HPC_STDOUTFILE%"
-e "%RSM_HPC_STAGING%/%RSM_HPC_STDERRFILE%" "%RSM_HPC_STAGING%/%RSM_HPC_COMMAND%"</arg>
</arguments>
</primaryCommand>
</submit>
<cancel>
<primaryCommand name="cancel'>
<application>
<app>qdel</app>
</application>
<arguments>
<arg>%RSM_HPC_JOBID%</arg>
</arguments>
</primaryCommand>
</cancel>
<queryStatus>
<primaryCommand name="queryStatus>
<application>
<app>qstat</app>
</application>
<arguments>
<arg>%RSM_HPC_JOBID%</arg>
</arguments>
</primaryCommand>
</queryStatus>
<queryQueues>
84

<primaryCommand name="queryQueues>
<application>
<app>qstat</app>
</application>
<arguments>
<arg>-Q</arg>
</arguments>
</primaryCommand>
</queryQueues>
</jobCommands>
The section in bold text is the section that provides the Submit action, which we want to customize in
this example. In the original version the Submit command invokes the cluster qsub with arguments
determined via environment variables. The actual executable that is submitted to the cluster is determined
by RSM during runtime and can be specified via an environment variable named RSM_HPC_COMMAND.
For details, see Submit Command (p. 96).
The example below shows the same section after it is customized to execute the Python file submit_PBS_EXAMPLE.py. In this example, we defined the type of application to execute (runpython,
accessed from the ANSYS installation) and the name of the Python file to be executed (submit_PBS_EXAMPLE.py).
<application>
<app>%AWP_ROOT160%/commonfiles/CPython/2_7_3/linx64/Release/python</app>
</application>
<arguments>
<arg>
<value>%RSM_HPC_SCRIPTS_DIRECTORY%/submit_PBS_EXAMPLE.py</value>
</arg>
</arguments>
</primaryCommand>
The custom Submit command appears much simpler than the original one. However, the details of the
submission are handled inside the Python file, which contains the same arguments used in the original
section. The Python file will also contain any custom code to be executed as part of the submission.
Note
The submit_PBS_EXAMPLE.py script is provided in the [RSMInstall]/RSM/Config/scripts/EXAMPLES directory. It can be used as a starting point for a customized
Submit command. The script should be copied into the [RSMInstall]/RSM/Config/scripts directory. Alternatively, a full path to the script must be provided along with
the name.
Other commands or queries can be overridden using the same procedure. You can find the command
name in the cluster-specific hpc_commands file and replace the application that needs to be executed
and the arguments needed by the application. Details on how to provide custom commands, as well
as the description of the environment variables, are provided in Writing Custom Code for RSM Integration (p. 95).
6.2.2. Customizing Client-Side Integration

The mechanism and operations for custom client-side integration are very similar to the ones for custom
server-side integration. However, the underlying architecture is different. In the server-side integration,
the customization affects the scripts used for RSM execution on the server/cluster side. In the clientside integration, only a thin layer of the RSM on the client side is involved. The layer provides the APIs
for the execution of the custom scripts, which are located on the Client machine. RSM is not installed
85
Customizing RSM
on the server/cluster. It is the responsibility of the custom scripts to handle all aspects of the job execution, including transfer of files to and from the server.
The RSM installation provides some prototype code for client integration that can be tailored and
modified to meet specific customization needs. As indicated above, the steps needed for client-side
integration are very similar to those for server-side integration. On the client-side RSM installation, you
will be using the local Client machine (and RSM Manager) to perform all the tasks (steps 1 through 4),
as follows:
1. Configure RSM to use cluster-specific code template.
2. Create copies of prototype code for the custom cluster type.
3. Add an entry to the job configuration file that associates your Custom Cluster Type keyword with
the cluster-specific hpc_commands_<keyword> file.
4. Edit the cluster-specific hpc commands_<keyword> file to reference the custom commands.
5. Provide cluster-specific script\code\commands that perform the custom actions and return the required RSM output.
The following sections discuss the steps to customize your integration:
6.2.2.1. Configuring RSM to Use a Cluster-Specific Code Template on the Client Machine
6.2.2.2. Creating Copies of Sample Code Using a Custom Client Keyword
6.2.2.1. Configuring RSM to Use a Cluster-Specific Code Template on the Client Machine
On the client-side RSM installation, you will be using the local Client machine (and RSM Manager) to
perform all the tasks (steps 1 through 4) in Customizing Client-Side Integration (p. 85).
After creating a new Compute Server, set up the Compute Server Properties dialog box under the
Cluster tab. You must select Cluster Type to Custom and then create a short phrase/word in the
Custom Cluster Type property as the custom cluster name. The name is arbitrary, but you should make
it simple enough to append to file names. This name will be referred to as the keyword from now on.
For supported clusters, you can include the original cluster name in the new custom name, for clarity.
For example, if your cluster is actually an LSF or PBS Pro cluster but you need to customize the RSM
interaction with it, you might use the keyword CUS_LSF or CUS_PBS. If the underlying cluster is
not a supported one, it could be called CUSTOM or any other arbitrary name. The names are in capital
letters for simplicity, but the only requirement is that the capitalization is the same in all places where
this keyword is referenced.
A custom client integration means that you are running in SSH mode or (non-RSM communication).
Thus, on the General tab of the Compute Server Properties dialog box, you need to select Uses nonRSM communication to a remote cluster node (e.g. SSH).
For the File Management tab, see Configuring File Transfer by OS Type and Network Share Availability (p. 91) for details on different file transfer scenarios.
A full example of a typical cluster setup using the local RSM Manager and custom client definition is
shown below.
86
87
Customizing RSM
Note
The Shared Cluster Directory you choose must be readable and writable by all users of RSM
and also by rsmadmin. The Shared Cluster Directory must be shared between all nodes of the
cluster and must be mounted using the same name (with the same parent directories).
The Local Scratch Directory you choose must be readable and writable by all users of RSM. The
scratch directory should not be shared between nodes, but it should have the same name (and
parent directories) on all nodes.
If you want to have a configuration with a shared scratch directory, specify where the job will
be run by selecting In the shared cluster directory.
Refer toAdding a Compute Server (p. 64) in the Remote Solve Manager User's Guide for information
about the properties in the General and Cluster tabs of the Compute Server Properties dialog box.
6.2.2.2. Creating Copies of Sample Code Using a Custom Client Keyword

As part of the setup, you must create a custom copy of the xml file that contains the definition of the
HPC commands to be used for the job execution. As a starting point you can create copies of existing
RSM files. The sample files are marked with the suffix CIS (Client Integration Sample) and provide an
example of LSF-based integration.
1. Using the RSM installation on your Client machine, locate the directory [RSMInstall]\Config\xml.
Note that all the actions listed below should be performed on the Client machine.
2. Locate the sample file for code template GenericJobCode_CIS.xml.
88

3. Copy the content of the GenericJobCode_CIS.xml code template into a new code template GenericJobCode_<YOURKEYWORD>.xml. If your keyword for the custom cluster was CUS_LSF like the
example in Configuring RSM to Use a Cluster-Specific Code Template on the Client Machine (p. 86), the
new file should be called GenericJobCode_CUS_LSF.xml.
4. Locate the sample file for command execution hpc_commands_CIS.xml.
5. Copy the content of the hpc_commands_CIS.xml command file into a new command file template
hpc_commands_<YOURKEYWORD>.xml. If your keyword for the custom cluster was CUS_LSF like
the example in Configuring RSM to Use a Cluster-Specific Code Template on the Client Machine (p. 86),
the new file should be called GenericJobCode_CUS_LSF.xml.
The client-side integration requires a custom implementation to be provided for all the commands to
be executed on the cluster. The standard RSM installation includes sample scripts for all these commands,
which should be used as a starting point for the customization. The sample scripts are named submitGeneric.py, cancelGeneric.py, statusGeneric.py, transferSSH.py, and cleanupSSH.py.
They are located in the [RSMInstall]\RSM\Config\scripts directory.
While it is not absolutely necessary to create a copy and rename the scripts, we have done so for consistency; in the rest of the example, it is assumed that they have been copied and renamed to add the
same keyword chosen for the custom cluster, for example (submit_CUS_LSF.py, cancel_CUS_LSF.py, status_CUS_LSF.py, transfer_CUS_LSF.py, and cleanup_CUS_LSF.py).
These scripts will have to be included in the custom job template, as shown in the following section,
Modifying the Job Configuration File for a New Cluster Type (p. 89).
These scripts are actually sample scripts that use a fully custom client integration on a standard LSF
cluster, for example only. Generally, custom client integrations do not use standard cluster types, and
thus there are no samples for custom client integrations on other cluster types.
Note
Any additional custom code that you want to provide as part of the customization should
also be located in the [RSMInstall]\RSM\Config\scripts directory corresponding
to your local (client) installation. Alternatively, a full path to the script must be provided
along with the name.
As part of the setup, you must add an entry for your custom cluster keyword in the jobConfiguration.xml file, and reference the files that are needed for that cluster job type.
should be performed on your client machine.
Open the jobConfiguration.xml file and add an entry that follows the pattern shown in the sample
code below. This code corresponds to the example in preceding sections which assumes your cluster is
most like an LSF cluster.
Note
In our example we have been using CUS_LSF as the keyword, but you still must replace
YOURKEYWORD with the actual custom cluster keyword you have defined.
89
Customizing RSM
<keyword name="YOURKEYWORD">
<hpcCommands name="hpc_commands_YOURKEYWORD.xml"/>
</keyword>

The cluster-specific HPC commands file is the configuration file used to specify the commands that will
be used in the cluster integration. The file is in xml format and is located in the [RSMInstall]\RSM\Config\xml directory.
This section provides an example of a modified file hpc_commands_CUS_LSF.xml. The cluster
commands are provided by the sample scripts to which the previous section refers. These scripts have
been copied from the samples provided in the RSM installation and renamed to match the keyword
chosen to the custom cluster.
The hpc_commands file provides the information on how commands or queries related to job execution
are executed. The file can also refer to a number of environment variables. Details on how to provide
custom commands, as well as the description of the environment variables, are provided in Writing
Custom Code for RSM Integration (p. 95).
<jobCommands version="3" name="Custom Cluster Commands">
<environment>
<env name="RSM_HPC_PARSE">LSF</env>
<env name="RSM_HPC_PARSE_MARKER">START</env> 
<env name="RSM_HPC_SSH_MODE">ON</env>
</environment>
<submit>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/submit_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
</submit>
<queryStatus>
<primaryCommand name="queryStatus">
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/status_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
</queryStatus>
<cancel>
<primaryCommand name="cancel">
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/cancel_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
</cancel>
<transfer>
<primaryCommand name="transfer">
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/transfer_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
<outputs>
<variableName>RSM_HPC_DIRECTORY_SHARED</variableName>
</outputs>
</primaryCommand>
</transfer>
<cleanup>
90

<primaryCommand name="cleanup">
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/cleanup_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
</cleanup>
</jobCommands>
Note
Any custom code that you want to provide as part of the customization should also be located
in the [RSMInstall]\RSM\Config\scripts directory corresponding to your local
(client) installation. Alternatively, a full path to the script must be provided along with the
name.
6.2.3. Configuring File Transfer by OS Type and Network Share Availability

A remote job execution on a cluster usually requires the transfer of files to and from a cluster directory.
This section goes over the different options that are available for server-side and client-side integration
in terms of how you can copy the files.
The Compute Server settings are used to specify information about the cluster staging area and local
scratch directory. The following sections contain example configuration settings for different scenarios:
6.2.3.1. Windows Client to Windows Cluster
6.2.3.2. Windows Client to Linux Cluster
6.2.3.3. Linux Client to Linux Cluster
For each scenario, the Shared Cluster Directory (that is, staging directory) can be:
Visible to the RSM Client machine via a network share, Samba share, or mapped drive. Using the naming
convention in Operating System File Transfer Utilizing Network Shares (p. 19). In these cases, RSM will
transfer the files to and from cluster staging area using an OS native copy command which is the fastest
method available.
Not visible to the RSM Client machine. In these cases, file management is handled in one of two ways:
For custom server integrations (that is, you have RSM services running on the Compute Server) transfers
can be handled internally by automatic native RSM file transfer system
or externally by HPC commands/scripts. RSM is not involved in the copying of files to/from the cluster.
Also, for each scenario, you can be using different types of communication:
Non-SSH (OS file transfer via network shares or RSM native transfer)
SSH (OS file transfer via network shares or custom script implementation)
6.2.3.1. Windows Client to Windows Cluster

In the following two scenarios, a Windows Client machine is integrated with a Windows cluster. Windows
to Windows SSH is not supported natively.
91
Customizing RSM
6.2.3.1.1. Windows-to-Windows, Staging Visible

In this scenario, the Windows Client can see the Windows cluster staging area via a network share or
mapped drive.
1. On the Compute Server Properties dialog box General tab, select This Compute Server is integrating
with an HPC Cluster.
2. On the Cluster tab, set the appropriate Custom Cluster Type as described in Customizing Server-Side Integration (p. 79) or Customizing Client-Side Integration (p. 85).
3. On the File Management tab:
Set Cluster Shared Directory to the UNC path of the actual shared directory on the cluster. It should
be in the form of \\Share_Host_Name\Share\Directory and all of the nodes and the Client
machine (the one submitting the job) should be able to access this share. RSM will (attempt to) copy
jobs to and from this location using the native Windows OS copy commands.
If using local scratch, set to the path of the desired local scratch space on the cluster. This local scratch
directory must be exactly the same location on all of the nodes, should not be shared, and should be in
the form of D:\storage\RsmTemp.
6.2.3.1.2. Windows-to-Windows, Staging Not Visible

In this scenario, the Windows Client cannot see the Windows cluster staging area; either there is a
firewall or this storage is otherwise not allowed to be directly accessed by the users.
2. On the Cluster tab, set the appropriate Custom Cluster Type as described in Customizing Server-Side Integration (p. 79) or Customizing Client-Side Integration (p. 85).
Set Cluster Shared Directory to the path of the actual shared directory on the cluster. It should be in
the form of Z:\storage\RsmTempShare and all of the compute nodes should be able to access this
share. RSM will copy jobs from the client to this location but it will use built in RSM file copy mechanism
that is slightly slower than the mechanism noted above in Windows-to-Windows, Staging Visible (p. 92).
If using local scratch, set to the path of the desired local scratch space on the cluster. This local scratch
directory must be exactly the same location on all of the nodes, should not be shared, and should be in
the form of D:\storage\RsmTemp.
6.2.3.2. Windows Client to Linux Cluster

In the following two scenarios, a Windows Client machine is integrated with a Linux cluster. Windows
to Linux SSH is supported, so additional commentary about SSH is included in these sections.
6.2.3.2.1. Windows-to-Linux, Staging Visible

In this scenario, the Windows Client can see the Linux cluster staging area via a Samba UNC or mapped
drive.
92

If SSH communication is required, then the General tab can be configured with SSH by choosing
Uses non-RSM communication to a remote cluster node (e.g. SSH).
2. On the Cluster tab:
On the Cluster tab, set the appropriate Custom Cluster Type as described in Customizing Server-Side
Integration (p. 79) or Customizing Client-Side Integration (p. 85).
If SSH communication is required, then you will have to enter Remote Cluster SSH credentials here.
Set Cluster Shared Directory to the path of the actual (cluster) shared directory on the cluster. It should
be in the form of /path/to/shared/cluster/directory and all of the compute nodes should
be able to access this share.
If not using SSH, RSM will check to see if \\Machine_Name\RSM_CS is the same as
/path/to/shared/cluster/directory and use a simple OS network copy.
If SSH Communication is required, then you will select Existing Network Share and entire the
name of the network share here in the form of \\Machine_Name\Share_Name.
If using local scratch, set to the path of the desired (cluster) local scratch space on the cluster. This local
scratch directory must be exactly the same location on all of the nodes and should be in the form of
/path/to/cluster/nodes/individual/scratch.
6.2.3.2.2. Windows-to-Linux, Staging Not Visible

In this scenario, the Windows Client cannot see the Linux cluster staging area.
If not using SSH, RSM will copy jobs from the client to this location but it will use built in RSM file copy
mechanism which is slightly slower the one noted above in Windows-to-Linux, Staging Visible (p. 92).
If SSH communication is required, then you will select Transferred by an external mechanism and
you will have to copy an example transfer script (or modify/write your own) such as transfer_<YourKeyword>.py as shown in Creating Copies of Sample Code Using a Custom Client Keyword (p. 88).
93
Customizing RSM
6.2.3.3. Linux Client to Linux Cluster

In the following two scenarios, a Linux Client machine is integrated with a Linux cluster. Linux to Linux
SSH is supported, so additional commentary about SSH is included in these sections.
6.2.3.3.1. Linux-to-Linux, Staging Visible

In this scenario, the Linux Client can see the Linux cluster staging area because the staging area is
mounted on the Client machines.
Since this is the Staging Visible section, the above directory should be mounted directly on the Linux
Client.
If SSH communication is required, then you will select Existing Network Share and the entire the
name of the Shared Directory again.
6.2.3.3.2. Linux-to-Linux, Staging Not Visible

In this scenario, the Linux Client cannot see the Linux cluster staging area.
94
Writing Custom Code for RSM Integration

If not using SSH, RSM will copy jobs from the client to this location but it will use built-in RSM file copy
mechanism that is slightly slower than the one noted above in Linux-to-Linux, Staging Visible (p. 94).
If SSH communication is required, then you will select Transferred by an external mechanism and
you will have to copy an example transfer script (or modify/write your own) such as transfer_<YourKeyword>.py as shown in Creating Copies of Sample Code Using a Custom Client Keyword (p. 88).
6.3. Writing Custom Code for RSM Integration

This section provides detailed information about the code that should be provided for custom integration
with RSM.
The custom code can be in any form convenient to you, typically in the form of scripts or executables.
Generally, scripts are used to wrap the underlying cluster software (for example, LSF) commands. You
can review sample Python scripts in the [RSMInstall]\Config\scripts directory.
The scripts have access to environment variables that are set to override default RSM behavior and to
environment variables that are dynamically set by RSM to provide information about job related variables.
A detailed description of the environment variables that the scripts can access is given in Custom Integration Environment Variables (p. 99).
This section discusses the following topics:
6.3.1. Parsing of the Commands Output
6.3.2. Customizable Commands
6.3.3. Custom Integration Environment Variables
6.3.4. Providing Client Custom Information for Job Submission
6.3.1. Parsing of the Commands Output

Since some of the commands used for custom integration are wrappers around cluster-specific commands,
it is necessary to parse the output of the cluster commands. The output of the cluster command provides
information such as cluster Job ID or status. It can also be used to report error and debugging messages.
6.3.1.1. Commands Output in the RSM Job Log

The output for all cluster command scripts should be sent directly to stdout or stderr. The contents
of stdout will be added to the RSM job log as standard messages. This content is also searched in
order to parse the information necessary as a result of the command execution. The handling of the
command output depends upon the value of the environment variable RSM_HPC_PARSE. The environRelease 16.0 - SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information
95
Customizing RSM
ment variable defines what type of output RSM should expect from the command. If the underlying
cluster used for the integration is one of the supported types (LSF/PBS Pro/TORQUE with Moab/SGE/MSCC)
you should set the value of RSM_HPC_PARSE to the corresponding type. Printing the output of the
command will allow the RSM code to extract the appropriate information. For example, if the LSF option
is used, RSM is expecting the output of the Submit command to contain output from LSF bsub command.
If your cluster is not one of the supported ones, you should set RSM_HPC_PARSE to CUSTOM. In this
case, it is your responsibility to parse the output of the commands and provide to RSM a variable with
the result. An optional RSM_HPC_PARSE_MARKER option can be set to a marker string of an output
line in order to indicate the line after which parsing should start. If no "start marker" is found, then RSM
will parse all of the output as the start marker was at the beginning of the output
6.3.1.2. Error Handling

Error messages and warnings information are written to stdout as necessary. If they are properly
labeled as indicated below they appear in the RSM log as orange for warnings and bold red for errors.
Output format:
RSM_HPC_ERROR=<errormessage>
RSM_HPC_WARN=<warning>
Example Python snippet:
Print(RSM_HPC_WARN=This is what a warning displays like)
6.3.1.3. Debugging
Debugging information, typically used for troubleshooting purposes, is shown on the RSM job log only
if the Debug Messages option is selected from the job log context menu. (To access this option, rightclick anywhere inside the job log pane of the RSM application main window.)
Output format:
RSM_HPC_DEBUG=<debugmessage>
6.3.2. Customizable Commands

RSM will invoke a custom implementation for the following commands:
6.3.2.1. Submit Command
6.3.2.2. Status Command
6.3.2.3. Cancel Command
6.3.2.4.Transfer Command
6.3.2.5. Cleanup Command
6.3.2.1. Submit Command

The Submit command is invoked to submit a job to the cluster. The command should return as soon
as the queuing system has taken ownership of the job and a unique Job ID is available.
If using CUSTOM parsing, the command must write a unique Job ID with the following format:
RSM_HPC_JOBID=<jobid>. If using (LSF/PBS Pro/TORQUE with Moab/SGE/MSCC) parsing, the
script only needs to send the direct output from the submission command (bsub/qsub/job submit).
96

The custom integration infrastructure provides the Python script, ClusterJobs.py, in the [RSMInstall]\Config\scripts directory. The script serves as a layer of abstraction that allows a userselected operation (such as a component update for one or more of the applications or a design point
update) to be invoked without the need to be aware of the command line arguments and options required for the appropriate submission of the job.
In the Submit command, the ClusterJobs.py script should be invoked (rather than executing the
individual applications). This Python script should be considered as a layer that builds the appropriate
command line and sets the appropriate environment variables for the remote execution. The usage of
application specific command line in the Submit script is strongly discouraged and cannot be properly
supported in a general way.
For user convenience, the complete Python command that contains the job to be executed by the
Submit command (for instance, by LSF bsub) is provided through the environment variable
RSM_HPC_COMMAND.
Examples:
Custom server examples for LSF, PBS Pro, SGE, and MSCC are located in the [RSMInstall]\Config\scripts\EXAMPLES directory.
A generalized custom client example (for all cluster types) is provided in the file submitGeneric.py,
located in the [RSMInstall]\Config\scripts directory.
More examples may be available on the ANSYS Customer Portal. For further information about tutorials
and documentation on the ANSYS Customer Portal, go to http://support.ansys.com/docinfo.
6.3.2.2. Status Command

The Status command has access to the Job ID through the environment variable RSM_HPC_JOBID.
Given a Job ID, the command should query the cluster for the status of the job and return the status
of that job in string format. If using CUSTOM parsing, the output should be parsed in order to provide
the status information with format RSM_HPC_STATUS=<jobstatus>, where jobstatus is:
CANCELED
FAILED
FINISHED
QUEUED
RUNNING
Examples:
Custom server examples are not provided for this command.
A generalized custom client example (for all cluster types) is provided in the file statusGeneric.py,
located in the [RSMInstall]\Config\scripts directory.
97
Customizing RSM
6.3.2.3. Cancel Command

The Cancel command has access to the Job ID through the environment variable RSM_HPC_JOBID.
Given a Job ID, the command should invoke the cluster command to cancel the job.
No output is required from the Cancel command. However, an output statement should be given for
verification in the RSM log.
Examples:
Custom server examples are not provided for this command.
A generalized custom client example (for all cluster types) is provided in the file cancelGeneric.py,
located in the[RSMInstall]\Config\scripts directory.
6.3.2.4. Transfer Command

The Transfer command is invoked in order to transfer files to and from the cluster.
No output is required from the Transfer command. However, it is suggested to output the files that are
being copied for verification in the RSM log.
The Transfer command can check if the environment variable RSM_HPC_FILEDIRECTION equals
UPLOAD or DOWNLOAD to detect whether files should be uploaded to the cluster or downloaded from
the cluster.
The Transfer command is invoked to upload files to and retrieve files from the cluster, as follows:
Uploading of files is invoked for input files and also when the user interrupts an application. (Applications
typically look for an interrupt file in a specified location.)
Retrieving of files is invoked for output files once the job is completed. It is also invoked for inquiring
(downloading) files during the execution of the job. Inquiring of files is typically invoked from Workbench
for small files (such as convergence information).
The list of files to be uploaded or downloaded is provided through a semi-colon delimited list in the
environment variable RSM_HPC_FILELIST. File names can possibly contain wildcards (for example
*.out). The files are located in the current Working Directory in which the script is invoked (that is,
the RSM job Working Directory).
The command can also access the environment variable RSM_HPC_FILECONTEXT is set to INPUTS
(beginning of job), OUTPUTS (end of job), CANCEL (cancelling a job) or INQUIRE (request for files
while job running). This information may be useful especially in the case of inquire, when extra processing
may be required to locate files for a running job.
Examples:
Custom server integrations do not use this command.
A custom client example is provided in the file transferSSH.py, located in the [RSMInstall]\Config\scripts directory.
98
6.3.2.5. Cleanup Command

The Cleanup command is called at the very end of the execution when all the other actions have been
completed. It can be used by the user to perform clean-up operation or other actions that are needed
at the end of a job.
No output is required from the Cleanup command. However, an output statement should be given for
verification in the RSM log.
Examples:
Custom server integrations do not use this command.
A custom client example is provided in the file cleanupSSH.py, located in the [RSMInstall]\Config\scripts directory.
6.3.3. Custom Integration Environment Variables

Workbench/RSM makes job settings available to custom commands via environment variables. Some
environment variables are set automatically by RSM at runtime, providing necessary information to the
custom scripts or executables in the HPC commands file. Other environment variables can be set by
your RSM administrator, if appropriate to your job management process.
6.3.3.1. Environment Variables Set by RSM

RSM will set the following environment variables at runtime, communicating job-specific data to the
HPC commands. These variables will need to be used in your scripts to do the job handling.
Environment Variable
Description
RSM_HPC_CLUSTER_TARGET_PLATFORM
Set as "Windows" or "Linux". Defines the platform on

which the final scripts are meant to run. The target
platform can be different than the local platform
when the Compute Server is not the computer that
will be running the solver. The CLUSTER variable is
used whether the remote machine is a cluster or
simply a single remote machine.
As an example, this would be used when you are
using a localhost Compute Server and using SSH
from the Compute Server to another remote
execution host. The platform of the remote execution
host could be Linux even if the local platform is
Windows.
RSM_HPC_CORES
The number of cores requested by the user for the

job.
RSM_HPC_DISTRIBUTED
Indicates whether a distributed (multi-node) cluster

job is allowed.
99
Customizing RSM
Set to TRUE if the target solver (specified in
RSM_HPC_JOBTYPE) supports distributed execution.
Set to FALSE if cores can be used on only one node.
RSM_HPC_FILECONTEXT
Used only by Transfer command/script. Specifies the

context in which files are being transferred in case
any special handling is required. Possible values are
CANCEL, INPUTS, INQUIRE, and OUTPUTS.
RSM_HPC_FILEDIRECTION
Used only by Transfer command/script. Specifies the

direction of file transfers. Possible values are UPLOAD
(which moves files from the client to the cluster) or
DOWNLOAD (which moves files from the cluster to
the client).
RSM_HPC_FILELIST
Used only by Transfer command/script. Semi-colon

delimited list of files to transfer for the job
submission or status request. Dynamically generated
because the list can depend on the job type or the
specific UI action. May contain wildcards.
RSM_HPC_JOBID
Identifier for the cluster job returned by the

successful Submit command. RSM sets this variable
so it is available to subsequent commands.
RSM_HPC_JOBTYPE
The solver being used for the job. Possible values are
Mechanical_ANSYS, Mechanical_AUTODYN,
Mechanical_RBD, Mechanical_CONTACT,
Workbench_ANSYS, Workbench_CFX, Workbench_FLUENT, Workbench_POLYFLOW, and
Workbench_DESIGNPOINT.
The job types with the Workbench prefix are jobs
executed from within Workbench as part of the
component update. Workbench_DESIGNPOINT is
the job type corresponding to the execution of the
Workbench Update Design Points operation.
The job types with the Mechanical prefix
correspond to jobs executed from ANSYS Mechanical.
RSM_HPC_LOCAL_PLATFORM
Set as "Windows" or "Linux" and defines the platform

on which the Compute Server is running.
RSM_HPC_NATIVEOPTIONS
Value(s) of the Job Submission Arguments property

on the Cluster tab of the Compute Server
Workbench/RSM does not define or manipulate these
administrator-specified options.
RSM_HPC_PROTOCOL_OPTION1 Used only when Uses non-RSM communication to

a remote cluster node (e.g. SSH) or Communicates
with a remote computer which performs the work
(e.g. SSH) is checked on the General tab of the
Compute Server Properties dialog box.
100

Contains the value of the remote account name.
Contains the value of the Remote Computer Name
(or Cluster Node).
Contains the value of the local environment variable
%KEYPATH% to be used for remote machine
authentication.
The queue requested by the user for the job.
RSM_HPC_QUEUE
The list of available queues is defined by the

Workbench/RSM administrator.
Path for the clusters central staging area for job files.
Typically needed when client and cluster platforms
are different.
RSM_HPC_STAGING
Defined by the Shared Cluster Directory property

on the Cluster tab of the Compute Server
RSM_HPC_STDERRFILE
A request that cluster job stderr be redirected into

the named file. The contents of this file will be added
to the RSM job log.
RSM_HPC_STDOUTFILE
A request that cluster job stdout be redirected into

the named file. The contents of this file will be added
to the RSM job log.
6.3.3.2. Optional Environment Variables Set by Customer

The following optional environment variables can be set by your RSM administrator on the Compute
Server side and they will be passed to the Compute Server as environment variables to be used in
scripting. Additionally, the user can set any number of variables that follow in Providing Client Custom
Information for Job Submission (p. 102).
Note
For client-side custom integration, the RSM Compute Server is running on the Client machine.
Environment Variable
Description
101
Customizing RSM
Specifies what type of output RSM should expect from these
commands, choose LSF, PBS, TORQUE, SGE, MSCC, or CUSTOM.
RSM_HPC_PARSE
If the underlying cluster used for the integration is one of the

supported clusters (LSF/PBS Pro/TORQUE with Moab/SGE/MSCC),
set the value of RSM_HPC_PARSE to the corresponding type. For
these supported types, RSM can extract the relevant information
from the output of the command. For unsupported types,
set RSM_HPC_PARSE to CUSTOM and see Customizable
Commands (p. 96) for what variables must be set in each command.
RSM_HPC_PARSE_MARKER
Specifies a marker string of an output line. The marker string is

used in order to indicate the line after which parsing should start.
6.3.4. Providing Client Custom Information for Job Submission

When executing a job, you can provide custom information from the client side that allows you to
perform custom actions prior the submission of a job to the Compute Server or cluster. Custom information that you define on the RSM Client machine can be picked up by RSM and then passed to the
Compute Server or cluster machine where the job is being executed.
Note
For a custom client Integration, the Compute Server is the Client machine therefore the information is made available to the custom scripts on the Client machine. In this case, the
environment variables are also passed to cluster machine on remote side.
Examples of custom information that can be provided to the cluster are:
The username of the submitter (which, for instance, provides the ability to monitor jobs submitted by a
particular user for accounting purposes) and
The license necessary to execute the job, which can be used to integrate with cluster resource management
to check ANSYS license availability before a job starts running.
For more information on how to integrate licensing with cluster software, contact your cluster administrator or ANSYS customer support.
As an example, well pass the submitters username from the client to a PBS Pro cluster.
The following sections detail the steps for providing custom information for job submissions to clusters.
6.3.4.1. Defining the Environment Variable on the Client
6.3.4.2. Passing the Environment Variable to the Compute Server
6.3.4.3. Verify the Custom Information on the Cluster
6.3.4.1. Defining the Environment Variable on the Client

First, you must define the information on the RSM Client machine by creating an environment variable.
The environment variable must begin with the prefix RSM_CLIENT_ in order for RSM to detect it and
pass the information from the Client machine to the Compute Server or cluster.
In the example below, weve defined the environment variable RSM_CLIENT_USERNAME. The name
is arbitrary as long as it begins with the RSM_CLIENT_ prefix.
102
6.3.4.2. Passing the Environment Variable to the Compute Server

Once youve defined the environment variable on the RSM Client machine, this environment variable
will be passed along with other job files to the Compute Server or cluster machine. You can access this
environment variable value from your custom cluster job scripts. In our example, we will add the client
job user name as a new command line argument to PBS Pro qsub command defined in the commands
file RSM uses for PBS Pro clusters, hpc_commands_PBS.xml (located in the [RSMInstall]\Config\xml directory).
In the code sample below, you can see that the environment variable is added to the qsub command.
Note, also, that it is preceded by A, which defines the account string associated with the job for the
PBS Pro cluster.
<application>
<app>qsub</app>
</application>
<arguments>
<arg>
<value>-q %RSM_HPC_QUEUE%</value>
<condition>
<env name="RSM_HPC_QUEUE">ANY_VALUE</env>
</condition>
</arg>
<arg>
<value>-A %RSM_CLIENT_USERNAME%</value>
<condition>
<env name="RSM_CLIENT_USERNAME">ANY_VALUE</env>
</condition>
</arg>
<arg>
<value>-l select=%RSM_HPC_CORES%:ncpus=1:mpiprocs=1</value>
<condition>
</condition>
</arg>
<arg>
<value>-l select=1:ncpus=%RSM_HPC_CORES%:mpiprocs=%RSM_HPC_CORES%</value>
<condition>
</condition>
</arg>
<arg>-N "%RSM_HPC_JOBNAME%" %RSM_HPC_NATIVEOPTIONS% -V -o "%RSM_HPC_STAGING%/%RSM_HPC_STDOUTFILE%" -e
"%RSM_HPC_STAGING%/%RSM_HPC_STDERRFILE%" "%RSM_HPC_STAGING%/%RSM_HPC_COMMAND%"</arg>
</arguments>
</primaryCommand>
103
Customizing RSM
To view a sample of this file before the addition of custom information, see Modifying the ClusterSpecific HPC Commands File (p. 90).
6.3.4.3. Verify the Custom Information on the Cluster

To verify that the custom information has been successfully passed from the RSM Client to the cluster,
run a job that will call the script youve customized. The environment variable should show up in the
Reading environment variables section of the RSM job log.
Reading environment variables...
RSM_CLIENT_USERNAME = myname
Since we added the environment variable to the qsub command in the PBS Pro commands file, it will
also show up in the area of the job log indicating that the qsub command has been run.
qsub -q %RSM_HPC_QUEUE% -A %RSM_CLIENT_USERNAME% -1
select=1:ncpus=%RSM_HPC_CORES%:mpiprocs=%RSM_HPC_CORES% ...
qsub -q WB_pbsnat -A myname -1 select=1:ncpus=1:mpiprocs=1 ...
104
Chapter 7: RSM Troubleshooting

This chapter contains troubleshooting tips for RSM.
Generating RSM Service Startup Scripts for Linux

The scripts for manually starting RSM services are usually generated during installation. In the event
that the scripts are not generated as part of the install or if you have removed the generated scripts,
you can generate the scripts manually in either of the following ways:
Generate scripts for all of the services by running rsmconfig (without command line options).
Generate the script for a specific service by running generate_service_script. Specify the service
by using command line options, as shown below:
tools/linux> ./generate_service_script
Usage: generate_service_script -mgr|-svr|-xmlrpc
Options:
-mgr: Generate RSM Job Manager service script.
-svr: Generate RSM Compute Server service script.
-xmlrpc: Generate RSM XML-RPC Server service script.
Configuring RSM for Mapped Drives and Network Shares for Windows
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:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
In the example below, full trust is opened to files on a shared network drive to enable software to run
from that share:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CasPol.exe
-q -machine -ag 1 -url "file://fileserver/sharename/*"
FullTrust -name "Shared Drive Work Dir"
For more information on configuring RSM Clients and Compute Servers using a network installation,
refer to Network Installation and Product Configuration.
Temporary Directory Permissions on Windows Clusters

Some applications executed through RSM (for example, Fluent) require read/write access to the system
temporary directory on local compute nodes. The usual location of this directory is C:\WINDOWS\Temp.
All users should have read/write access to that directory on all nodes in the cluster to avoid job failure
due to issues related to the creation of temporary files.
105
RSM Troubleshooting
Firewall Issues
If you have a local firewall turned on for the server and/or RSM Client machines, you will need to attach
two ports to the Exceptions List for RSM, as follows:
Add port 8160 to (Ans.Rsm.SHHost.exe).
Add port 9160 to (Ans.Rsm.JMHost.exe).
Enabling or Disabling Microsoft User Account Control (UAC)

To enable or disable UAC:
1. Open Control Panel > User Accounts > Change User Account Control settings.
2. On the User Account Control settings dialog box, use the slider to specify your UAC settings:
Always Notify: UAC is fully enabled.
Never Notify: UAC is disabled.
Note
Disabling UAC can cause security issues, so check with your IT department before changing
UAC settings.
Internet Protocol version 6 (IPv6) Issues

When running a cluster, you will receive an error if connection to a remote RSM Manager is not possible
because the RSM Manager has not been configured correctly as localhost.
If you are not running a Microsoft HPC cluster, test the localhost configuration by opening a command
prompt and running the command, ping localhost. If you get an error instead of the IP address:
1. Open the C:\Windows\System32\drivers\etc\hosts file.
2. Verify that localhost is not commented out (with a # sign in front of the entry). If localhost is commented
out, remove the # sign.
3. Comment out any IPv6 information that exists.
4. Save and close the file.
Note
If you are running on a Microsoft HPC cluster with Network Address Translation (NAT) enabled,
Microsoft has confirmed this to be a NAT issues and is working on a resolution.
Multiple Network Interface Cards (NIC) Issues

When multiple NIC cards are used, RSM may require additional configuration to establish desired communications between tiers (in other words, the RSM Client, RSM Manager, and Compute Server machines).
106
In most cases you will need to configure the RSM Manager and/or Compute Server machine(s) depending
on which one has multiple NIC cards installed. For instructions, refer to Configuring Computers with
Multiple Network Interface Cards (NIC) (p. 18).
RSH Protocol Not Supported

The RSH protocol is not officially supported and will be completely removed from future releases.
SSH File Size Limitation

The PuTTY SSH/SCP client has file size limitations that RSM circumvents by splitting and joining very
large files (greater than 2 GB). The Windows Compute Server and the Linux machine may also have file
system limitations that are beyond the control of RSM. You must configure the Linux machine with
large file support, and the Windows file system must be NTFS in order to transfer files larger than approximately 2 GB. If any job output file is not successfully retrieved, all job output files are left on the
Linux machine. Consult the job log in the RSM Job Log view to learn the temporary directory name
used to store the job files. You can then manually retrieve the files from the temporary directory (using
Samba or a similar application) so the results can be loaded back into your ANSYS client application.
Note
This limitation does not apply if files are being transferred via a network share.
107
108
Appendix A. ANSYS Inc. Remote Solve Manager Setup Wizard

The ANSYS Remote Solve Manager Setup Wizard is designed to guide you through the process of setting
up and testing Remote Solve Manager (RSM). Once the setup and testing is complete, you will be able
to use RSM to submit jobs from Workbench to be executed on remote machines or clusters.
The following sections contain detailed information on using the ANSYS Remote Solve Manager Setup
Wizard:
A.1. Overview of the RSM Setup Wizard
A.2. Prerequisites for the RSM Setup Wizard
A.3. Running the RSM Setup Wizard
A.4.Troubleshooting in the Wizard
A.1. Overview of the RSM Setup Wizard

The RSM Setup Wizard can help you to configure all the machines that will be part of your RSM Layout
(the actual physical configuration of machines to be used for initiating, queuing, and solving jobs). It
allows you to perform the following tasks:
Automate the Workbench setup before starting RSM services for certain cluster scenarios. As part of
the optional auto-configuration process, the wizard performs the following setup tasks to ensure that
Workbench is available to each node in the cluster:
If it does not already exist, create a share to the cluster head node Workbench installation directory.
Run ANSYS Workbench configuration prerequisites.
Note
In order for the wizard to install prerequisites, UAC must be disabled on any cluster
node where prerequisites are missing and need to be installed.
Installed prerequisites include MS.NET Framework 4.0 Redistributable and MS VC++
2010 Redistributable x64. (If needed, packages from previous versions, such as MS VC++
2008 Redistributable x64, among others, could be included by editing the AutoConfig.AllPrereqInstaller entry in the Ans.Rsm.Wizard.exe.config file).
Once you have completed the RSM setup, it is recommended that you reboot the machine(s) on which MS.NET Framework 4.0 and/or MS VC++ 2010 Redistributable x64
have been installed.
Set up Workbench environment variables on each node in the cluster.

Start RSM services locally or remotely for the RSM Manager and Compute Server (that is, both on the
local machine on which you are currently running the wizard and on remote machines).
109
ANSYS Inc. Remote Solve Manager Setup Wizard

It is best to perform these tasks from the RSM Manager/Compute Server machine.
Configure machines locally and/or remotely to serve as an RSM Client, the RSM Manager, or a Compute
Server.
It is best to perform these tasks from the RSM Manager/Compute Server machine.
Integrate RSM with the following third-party job schedulers (without requiring job script customization):
LSF (Linux only)
PBS Pro (Linux only)
TORQUE with Moab (Linux only)
Microsoft HPC (Windows only)
UGE (SGE) (Linux only)
Configure a cluster.
It is best to perform cluster configuration tasks from the machine that is the head node of the
cluster. When you indicate that you are configuring the cluster head node, the wizard will walk
you through the steps to configure it as both RSM Manager and Compute Server and to configure
all the compute nodes in the cluster.
Create a Project Directory, Working Directory, and where applicable, a Shared Cluster Directory for the
storage of project inputs, outputs, solver files, and results. Options for allowing the wizard to select
directory paths and to automatically configure the Working Directory and Shared Cluster Directory are
available. Automation of these steps helps to ensure consistency for your RSM setup.
Define one or more Queues that will receive jobs from the RSM Manager and send the jobs to one or
more Compute Servers.
Create primary accounts or alternate accounts. Alternate accounts may be required to allow access to
all the Compute Servers to which jobs will be sent.
Test the Compute Servers to ensure that your RSM configuration is working properly. When there are
issues, the wizard will attempt to diagnose and provide you with information on the problem. If the
wizard cannot diagnose the problem, it will offer suggestions for troubleshooting outside of the wizard.
It is best to perform testing from the RSM Client machine. For details, see Step 3: Test Your RSM
Configuration (p. 115).
Note that there are a number of setup tasks that the RSM Setup Wizard cannot perform. The wizard
cannot:
Start Compute Server or RSM Manager services from a network installation. You must start services
locally on the Compute Server or RSM Manager machine before running the wizard.
Perform certain tasks without correct permissions. For details on necessary Windows and Linux permissions, see Prerequisites for the RSM Setup Wizard (p. 111).
Detect file permissions issues in the Compute Server or RSM Manager until the final step of the setup.
110
Prerequisites for the RSM Setup Wizard

Perform some cluster setup tasks and checks remotely from the RSM Manager or Compute Server machine; these tasks must be performed locally on each of the machines in the cluster.
Create parallel environments (PEs), which are required for UGE (SGE) Clusters.
Diagnose Test Compute Server configuration issues from a machine other than the RSM Client.
Correct some connection problems, typically issues related to hardware, firewalls, IPv6, and multiple
NIC, and so on. For details on these issues, see RSM Troubleshooting (p. 105).
A.2. Prerequisites for the RSM Setup Wizard

1. RSM must already be installed on all the machines to be included in the RSM Layout.
For a machine that will serve as an RSM Client or a Compute Server (in any combination), the installation
of ANSYS Workbench, RSM, and client applications is required.
For a machine that will serve solely as the RSM Manager, the installation of RSM is required (so it can
connect with the RSM Client and Compute Server machines). However, if it will also serve as an RSM
Client or Compute Server, you must install ANSYS Workbench and client applications as well.
Note
RSM and Workbench are both installed by default as product components to most ANSYS,
Inc. products. RSM can also be installed independently as a standalone package.
For cluster configurations, when you configure the head node of the cluster as an RSM Manager, it will also be configured as a Compute Server. The compute nodes in the cluster will
be configured via the head node.
2. Before starting the wizard, exit Workbench and verify that no RSM jobs are running.
3. Different privileges are necessary for different parts of the setup process. Verify that you have the appropriate privileges for the setup tasks you will perform.
For Windows,administrative privileges means that the user either has Windows administrative privileges
on the RSM Manager machine, launches the wizard via the right-click Run as administrator menu option,
or is added to the RSM Admins user group. For RSM Admins privileges, you must create the RSM Admins
user group and add users to it manually. For instructions, see RSM User Accounts and Passwords (p. 47).
For Linux,administrative privileges can be root or non-root.Non-root administrative privileges means
that the user is added to the rsmadmins user group. As a member of this group, you have administrative,
non-root permissions, which are necessary for certain parts of the setup. When a root user starts RSM
services, if the rsmadmins user group and rsmadmin account do not already exist, the rsmadmins group
is automatically created on the RSM Manager machine and an rsmadmin account is added to the group.
This account can then be used to add additional users to the group.
For Linux, if the user prefers to start the non-daemon services from the RSM Setup Wizard (as
opposed to installing and starting the services as daemons with a root account), then a user account
from the rsmadmins user group must be used. Note that if the RSM services are not installed as
daemons, the rsmadmins user group is not automatically created. Therefore, in order to start
non-daemon services via the wizard, prior to running the wizard your IT department must:
111

Create the rsmadmins user group manually
Add the user(s) who will be running/starting non-daemon services to the rsmadmins group
Starting RSM services.
For Windows, you must have administrative privileges.
Note
To start RSM services when UAC is enabled on Windows 7, you must use the rightclick Run as administrator menu option to launch the wizard. For instructions on
enabling or disabling UAC, see RSM Troubleshooting (p. 105).
For Linux, you must have either root user or rsmadmins (non-root administrative) privileges.
Note
If you start the services with an rsmadmins non-root user account, the service will
be run by that account in non-daemon mode. Root user privileges are required for
starting RSM services as daemons. If you start RSM services as daemons, any nondaemon services will be killed.
Configuring new or existing machines, queues, and accounts.

For Windows, you must have administrative privileges.
For Linux, you must have rsmadmins (non-root administrative) privileges. (You cannot perform this
step with root permissions.)
To test the final RSM configuration, you must be logged in as a user who will be sending jobs from the
RSM client.
For Windows, you can have either administrative or non-administrative privileges.
For Linux, you can have either rsmadmin (non-root administrative) or non-administrative privileges.
4. In most cluster scenarios, client users (other than the user who set up the cluster) must cache their password
with the cluster prior to using the wizard for RSM configuration testing. The only exception is for MS HPC
clusters, where if you are logged in with administrative privileges, the wizard asks you to cache and verify
your password in order to use the wizards auto-configuration functionality.
5. If you are running an UGE (SGE) cluster, parallel environments (PEs) must have already been defined by
your cluster administrator. For more information, see Properties on the Cluster Tab (p. 71).
6. If you are running a Microsoft HPC cluster with multiple network interface cards (NIC), additional configurations are required to establish communications between the RSM Client and Compute Server machines.
For more information, see RSM Troubleshooting (p. 105).
112
Running the RSM Setup Wizard
A.3. Running the RSM Setup Wizard

This section divides running the RSM Setup Wizard into the following steps:
A.3.1. Step 1: Start RSM Services and Define RSM Privileges
A.3.2. Step 2: Configure RSM
A.3.3. Step 3: Test Your RSM Configuration
A.3.1. Step 1: Start RSM Services and Define RSM Privileges

In this part of the setup, you will start RSM services and define RSM administrative privileges for yourself
or other users.
Required Privileges
For Windows, you must either have Windows administrative privileges on the RSM Manager machine,
have RSM Admin privileges, or launch the wizard via the right-click Run as administrator menu option.
Note
To start RSM services when UAC is enabled on Windows 7, you must use the rightclick Run as administrator menu option to launch the wizard.
For Linux, you must have either root user or rsmadmins (non-root administrative) privileges. (To start
RSM services as daemons, root user privileges are required. In some cases, these tasks may need to be
performed by a member of your IT department.)
1. Log into the machine that will serve as the RSM Manager. If you are configuring a cluster, this is the head
node of the cluster.
2.
Launch the wizard:

For Windows, select Start > All Programs > ANSYS 16.0 > Remote Solve Manager > RSM Setup
Wizard 16.0. Alternatively, you can navigate to the [RSMInstall]\bin directory and double-click
Ans.Rsm.Wizard.exe.
For Linux, open a terminal window in the [RSMInstall]\Config\tools\linux directory and
run rsmwizard.
Note
For a quick-start guide on using the wizard, see the Readme file. To access this file:
For Windows: Select Start > All Programs > ANSYS 16.0 > Remote Solve Manager
> Readme - RSM Setup Wizard 16.0.
For Linux: Navigate to the [RSMInstall]\Config\tools\linux directory and
open rsm_wiz.pdf.
3. Specify if you are configuring the head node of a cluster.

If yes, specify the cluster type.
113

If yes and MS HPC cluster, indicate whether you want to automate the setup to ensure that Workbench
is available to each node in the cluster.
Note
UAC must be disabled on any cluster node where ANSYS Workbench prerequisites are
missing and need to be installed.
If no, verify prerequisites when prompted and then specify the service role(s) for which the local machine
is being configured.
4. Start RSM services on the local machine. If the necessary services havent already been started, the wizard
will start them when you click the Start Services button.
5. Provide RSM administrative privileges to users as necessary.
For Windows, to provide users with RSM administrative privileges, you must manually create an RSM
Admins user group and add users to this group.
For Linux, When the RSM services are started by running the wizard with root user privileges, if the
rsmadmins user group and an rsmadmin account do not already exist, the group is automatically created
on the RSM Manager machine. An rsmadmin user account is created in the new user group. This account
has administrative, non-root privileges and can be used to perform RSM administrative and configuration
tasks via the wizard on Linux.
On Linux, to provide additional users with RSM administrative privileges, you must add them to
the rsmadmins user group.
6. If you are logged in with:
Windows administrative or RSM Admin permissions, you can continue the RSM setup process via your
current wizard session.
Linux root permissions, there are no further steps that you can perform with the wizard. All further wizard
configurations must be performed by a user with rsmadmin permissions. You can close the wizard now
via the exit button and log back in with rsmadmins permissions to continue the setup.
A.3.2. Step 2: Configure RSM

In this part of the setup, you will configure the RSM Manager and Compute Server(s) in your RSM Layout.
If you are using a cluster, you will do the configurations that can be performed by the wizard. You will
also define queues and accounts.
Required Privileges
For Windows, you must have administrative permissions. For Linux, you must have rsmadmins (nonroot administrative) privileges.
Note
If you are on a Windows RSM Manager and continuing your existing wizard session, you have
already performed the first three steps. Skip to step #4.
114
Running the RSM Setup Wizard

1. Log into the machine that will serve as the RSM Manager. If you are configuring a cluster, this is the head
node of the cluster.
2. Launch the wizard as described in Step 1: Start RSM Services and Define RSM Privileges (p. 113).
3. Specify if you are configuring the head node on a cluster as described in Step 1: Start RSM Services and
Define RSM Privileges (p. 113).
4. Follow the steps provided by the wizard to perform the following setup tasks. The tasks will vary according
to your RSM Layout.
Configure the RSM Manager(s)
Configure the Compute Server(s)
Configure Queues
Create Accounts
5. When the configuration is complete, exit the wizard.
A.3.3. Step 3: Test Your RSM Configuration

In this part of the setup, you will accomplish two tasks: you will specify the RSM Manager to be used
and test the final RSM configuration before submitting jobs. You should perform these tasks by logging
into a machine that will serve as an RSM Client.
Note
Under certain circumstances, testing can also be performed from an RSM Manager machine
with remote access to the RSM Client. However, testing from the RSM Manager may prevent
the wizard from performing some of the setup tasks, such as those for cluster configuration.
Required Privileges
For Windows, you can have either administrative or non-administrative permissions. For Linux, you must
have non-root permissions.
1. Once the setup is finished, log into a machine that will be an RSM Client. You must log in under an account
that will be used to send jobs via RSM.
Note
In most cluster scenarios, client users (other than the user who set up the cluster) must
cache their password with the cluster prior to using the wizard for RSM configuration
testing. The only exception is for MS HPC, where if you are logged in with administrative
privileges, the wizard asks you to cache and verify your password in order to use the
wizards auto-configuration functionality.
For instructions on caching the password, see Manually Running the Password Application in the Remote Solve Manager User's Guide.
115

2. Launch the wizard as described in Step 1: Start RSM Services and Define RSM Privileges (p. 113).
3. Follow the steps in the wizard as before, identifying your local machine as an RSM Client.
4. When you reach the Test Compute Servers step, select the Queue and Compute Servers to be tested and
click Start Test.
To view a live job log during the test, click View Test Status. You can save the job log as a .txt or
.html file.
5. If the tests pass, you can exit the wizard. If the tests fail, click the Diagnose Failure button for information
on the reason for the failure.
If the wizard specifies what caused the error, correct the problems identified in the error message and
retry the test.
If the wizard is unable to identify the exact problem, it will suggest possible troubleshooting steps. For
details, see RSM Troubleshooting (p. 105).
A.4. Troubleshooting in the Wizard

This section contains information on the sorts of problems that the wizard can diagnose. The wizard
can potentially diagnose the following problems.
RSM Manager problems, such as:
RSM services have not been started
File send or compression errors
Script or job errors
Compute Server problems, such as:
Account authentication issues
Job code compilation or load failures
Missing files
Job Script problems, such as:
AWP_ROOT environment variable undefined
Remote command execution errors
Command runtime exceptions
Script class exceptions
Shared directory path creation failure
Project Directory or Working Directory creation or path issues
Cluster-specific problems, such as:
116
Troubleshooting in the Wizard

Invalid cluster type
Unavailable cluster nodes
AWP_ROOT environment variable undefined on execution node
Queue issues (RSM queue does not exist on cluster, queue list unavailable)
Execution node directory issues (failure to create Working Directory, failure to locate cluster shared directory)
Cluster control file reading errors
SSH-specific problems, such as:
Authentication failures (issues with public, private, or host keys)
KEYPATH errors (environment variable undefined, KEYPATH file missing)
Proxy machine name undefined
Host nonexistent or unavailable
Network error
Client API problems, such as:
File transfer exceptions (upload, download)
File compression exceptions (compression, decompression)
RSM Manager Project Directory unshared
RSM Manager project file missing
For instructions on addressing problems that the wizard cannot diagnose, see RSM Troubleshooting (p. 105) and view the following entries:
Firewall Issues (p. 106)
Multiple Network Interface Cards (NIC) Issues (p. 106)
Internet Protocol version 6 (IPv6) Issues (p. 106)
117
118
Appendix B. Integrating Windows with Linux using SSH/SCP

RSM supports using SSH/SCP (Secure Shell/Secure Copy) in custom job scripts. The built-in job scripts
for the RSM job submissions have been tested using the PuTTY SSH client (http://www.chiark.greenend.org.uk/~sgtatham/putty).
SSH/SCP is used for integrating a Windows RSM Manager with a Linux Compute Server. The RSM Manager
and the Compute Server proxy (the Compute Server defined on the General tab of the Compute
Server Properties dialog) are typically on the same Windows machine. The actual Compute Server is
on a remote Linux machine (defined on the Cluster tab of the Compute Server Properties dialog).
Jobs are sent via the SSH/SCP protocol from the Windows Compute Server proxy to the actual Linux
Compute Server for processing.
Communications to the Compute Server can be configured either for single Linux machine or for a
Linux cluster. Note that this section focuses primarily on setting up SSH for connection to a single remote
Linux Compute Server. If you are using SSH with a Linux LSF, PBS Pro, TORQUE with Moab, or UGE (SGE)
cluster, you can use the cluster setup instructions contained in the Configure PuTTY SSH (p. 120) section
of this appendix. Then, for detailed instructions on configuring the LSF, PBS Pro, TORQUE with Moab,
or UGE (SGE) cluster Compute Server, refer to the cluster configuration instructions in Integrating RSM
with a Linux Platform LSF, PBS Pro, TORQUE with Moab, or UGE (SGE) Cluster.
Note
SSH is not a recommended communication protocol and should be used only if it is required
by your IT policy. For ease of configuration and enhanced performance, native RSM is the
recommended communication protocol. Before proceeding with this configuration, see
Configuring RSM to Use a Remote Computing Mode for Linux (p. 11) and Configuring Native
Cross-Platform Communications (p. 11) for more information.
Before You Begin

These instructions assume the following:
Workbench and RSM have been installed on the Windows machine.
RSM has been installed on both the Windows and Linux machines.
PS, AWK, GREP, LS, and the ANSYS160 command must exist on the Linux machine.
You are able to install and run ANSYS, Inc. products, including Licensing, on both Windows and Linux systems.
For information on product and licensing installations, go to the Downloads page of the ANSYS Customer
Portal. For further information about tutorials and documentation on the ANSYS Customer Portal, go to http://
support.ansys.com/docinfo.
119
Integrating Windows with Linux using SSH/SCP
SSH Job Limitations

File Size Limitation The Windows Compute Server and the Linux machine may have file system
limitations that are beyond the control of RSM. You must configure the Linux machine with large file
support, and the Windows file system must be NTFS in order to transfer files larger than approximately
2 GB. If any job output file is not successfully retrieved, all job output files are left on the Linux machine.
Consult the job log in the RSM Job Log view to learn the temporary directory name used to store the
job files. You can then manually retrieve the files from the temporary directory (using Samba or a similar application) so the results can be loaded back into your ANSYS client application.
Note
This limitation does not apply if files are being transferred via a network share.
High Maximum Number of Jobs Value When you use SSH as protocol to run RSM jobs and set a
high maximum number of jobs, some jobs could fail, providing a message such as Server unexpectedly
closed network connection. This happens because too many SSH calls are made simultaneously from
different jobs. In this case, you may need to reduce the maximum number of jobs that can be run
concurrently. To do so, go to the General tab of the Compute Server Properties dialog box and lower
the value for the Maximum Number of Jobs field.
B.1. Configure PuTTY SSH

In order to send RSM jobs to a remote 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 Linux machine.
Note
SSH configuration must be completed by your IT administrator. This section provides instructions for a PuTTY SSH implementation. Other SSH implementations are possible, and your IT
administrator can determine which one is best for your site.
Download and install PuTTY.

Download and install PuTTY from the following location: http://www.chiark.greenend.org.uk/~sgtatham/
putty/download.html
If this link is invalid, perform a web search for "PuTTY".
Create a cryptographic key.

Create a cryptographic key using PuTTYGen (puttygen.exe) as follows:
1. On the PuTTY Key Generator dialog box, click Generate.
2. Change the Key comment to include your machine name and Windows username.
3. Do not enter a key passphrase.
4. Save the private key file without a passphrase.
120
Configure PuTTY SSH

For example, <drive>:\Program Files\Putty\id_rsa.ppk.
If you use a pass phrase, jobs will hang a prompt for you to enter the pass phrase. Be sure to secure
the private key file using some other means. For example, if only you will be using the key, save it
to a location where only you and administrators have access to the file, such as the My Documents
folder. If multiple users share the same key, allow the owner full control, then create a group and
give only users in that group access to this file.
5. If your Linux cluster uses OpenSSH, convert the key to OpenSSH format by selecting Conversions > Export
Open SSH key in the PuTTY Key Generator dialog box.
6. Move the public portion of the key to the Linux machine. This requires you to edit the ~/.ssh/authorized_keys file on the Linux machine as follows:
Open an SSH session to one of your cluster nodes, cd into ~/.ssh, and open the authorized_keys
file in your favorite editor (for example, VI or EMACS).
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 Linux machine for editing.
Modify system environment variables.

1. Open the Windows System Properties dialog box.
2. On the Advanced tab, select Environment Variables. The Environment Variables dialog box appears.
3. On the Environment Variables dialog box, locate the Path variable in the System variables pane.
121
4. Select the Path variable and then click the Edit button. The Edit System Variable dialog box appears.
5. Add the PuTTY install directory to the Variable value field (for example, C:\Program Files\putty)
and then click OK.
6. In the System variables pane, click the New button. The New System Variable dialog box appears.
7. In the New System Variable dialog, create a new environment variable named KEYPATH with a value
containing the full path to the private key file (for example, <drive>:\Program
Files\Putty\id_rsa.ppk).
122
Add a Compute Server
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 7 user has a key file in My Documents, the variable value
should be %USERPROFILE%\My Documents\id_rsa.ppk (this expands to <drive>:\Documents and Settings\<user>\My Documents\id_rsa.ppk).
8. Click OK.
9. Reboot the computer for environment changes to take effect.
Perform an initial test of the configuration.

1. Run the following from the command prompt (quotes around %KEYPATH% are required):
plink -i %KEYPATH% unixlogin@unixmachinename pwd
2. When prompted by plink:

If plink prompts you to store the key in cache, select Yes.
If plink prompts you to trust the key, select Yes.
B.2. Add a Compute Server

Underneath the Manager node on the RSM tree view, right-click the Compute Server node and select
Add. The Compute Server Properties dialog box displays. See Adding a Compute Server (p. 64) for
more detailed information.
123
General Tab
The General tab is used to set the properties of the Windows Compute Server. On the General tab,
set properties as described below.
For Display Name, enter a descriptive name for the Windows Compute Server.
Set Machine Name to the network machine name for the Windows Compute Server. If the RSM Manager
and Compute Server will be on the same Windows machine, enter localhost.
In the example below, the RSM Manager and the Compute Server are on the same machine.
Set What is the role of this Compute Server? to Communicates with a remote computer which performs
the work (e.g. SSH). When you select this, Working Directory Location is set to Network Share (readonly) and Working Directory Path is disabled.
Enter the Working Directory Path if youve opted to specify the location. If the location is determined by
the system, this property is blank and disabled.
Select Use SSH protocol for inter- and intra-node communications (Linux only) so that RSM and solvers
will use SSH for inter-node and intra-node communications for Linux machines. This setting applies to all
Linux Compute Servers.
Note
When ANSYS Fluent, ANSYS CFX, ANSYS Mechanical, and ANSYS Mechanical APDL are
configured to send solves to RSM, their solvers will use the same RSH/SSH settings as RSM.
124
For detailed descriptions of these and the other properties, see Properties on the General Tab (p. 65).
Remote Tab
The Remote tab is used to define details about the remote Linux machine that will execute the jobs.
For Remote Computer, enter the hostname or IP address of the remote Linux computer. Next to the field,
select the platform type (in our example, Linux 64).
For Account Name, enter the name of the user account that will be used to log into the remote computer.
If the Windows and Linux account names are the same (for example, DOMAIN\testuser on Windows
and testuser on Linux) then no additional configuration is required. If the account name is different,
use the Linux Account field to enter the name of the account being used to log into the remote
Linux machine.
This Linux account is an alternate account that allows you to send jobs from the primary Windows
account on the RSM Client and run them under the alternate account on a remote Linux Compute
Server. Both accounts are defined on the RSM Accounts dialog box. For more information, see RSM
User Accounts and Passwords (p. 47).
125
For detailed descriptions of these and the other properties, see Properties on the Remote Tab (p. 70).
File Management Tab

The File Management tab is used specify how files will be managed and transferred between your
Compute Server and the remote Linux machine.
Leave the How do files get to/from the Remote Computer? property set to Existing Network Share
(Samba, CIFS, NSF).
For Network Share, enter the path of the network share that will be used to transfer files between the
Compute Server and the remote computer. If you check back on the General tab, the value entered here
for Network Share is populated read-only to the Working Directory Path property.
For Remote Directory, enter the path of the directory on the remote Linux machine (this is the same location
as the Network Share).
126
Note
For an alternate file management scenario, you could also set the How do files get to/from
the Remote Computer? property to Transferred by an external mechanism (e.g. SSH),
and then must enter a path for Remote Directory. If you check back on the General tab,
you will see that the Working Directory Location property is now set to Reuse Manager
Storage.
For detailed descriptions of these and the other properties, see Properties on the File Management
Tab (p. 72).
Test the Compute Server configuration.

On the Linux Compute Server machine, ensure that the ANSYS Product environment variable
AWP_ROOT160 is set to the location of your ANSYS product installation. This is done by adding the
environment variable definition to your .cshrc (C shell) resource file or .bashrc (bash shell) resource
file.
To test the Compute Server configuration, right-click the name of the Compute Server in the tree view
and select Test. This runs a test job using the settings provided. You can also select Advanced Test;
the resulting dialog box allows you to choose both the type of test (basic or file transfer) and the directory in which the test job will be run. The Job Log view 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.
127
128
Appendix C. Integrating RSM with a Linux Platform LSF, PBS Pro,

TORQUE with Moab, or UGE (SGE) Cluster
The following sections divide the setup and configuration process for integrating RSM with a Linuxbased Platform LSF (Load Sharing Facility), PBS (Portable Batch System), TORQUE with Moab, or UGE/SGE
(Univa Grid Engine/Sun Grid Engine) cluster into sequential parts. The sequential parts are followed by
general integration details.
Before You Begin

Both the RSM Manager and Compute Server machines are set up on the network.
An LSF, PBS Pro, TORQUE with Moab, or UGE (SGE) cluster has been established and configured.
You are not using the SSH protocol but instead are using native RSM mode. For information on native RSM,
see Configuring RSM to Use a Remote Computing Mode for Linux (p. 11).
Note
If you will be using SSH for Windows-Linux communications, see Integrating Windows
with Linux using SSH/SCP for SSH setup instructions. Then refer back to this appendix for
instructions on configuring RSM to send jobs to a Linux LSF, PBS Pro, TORQUE with Moab,
or UGE (SGE) cluster.
You have the machine name of the LSF, PBS Pro, TORQUE with Moab, or UGE (SGE) submission host.
RSM has been installed on the LSF, PBS Pro, TORQUE with Moab, or UGE (SGE) submission host.
If you are using a UGE (SGE) cluster, parallel environments have already been defined by your cluster administrator.
You are able to install and run ANSYS, Inc., products, including Licensing, on both the RSM Manager and
Compute Server machines. For information on product and licensing installations, go to the Downloads
page of the ANSYS Customer Portal. For further information about tutorials and documentation on the
ANSYS Customer Portal, go to http://support.ansys.com/docinfo.
C.1. Add a Linux Submission Host as a Compute Server

In this step, well add the Linux submission host as a Compute Server. Underneath the Manager node
on the RSM tree view, right-click the Compute Server node and select Add. The Compute Server
Properties dialog box displays. See Adding a Compute Server (p. 64) for more detailed information.
129
Integrating RSM with a Linux Platform LSF, PBS Pro,TORQUE with Moab, or UGE (SGE)
Cluster
General Tab
On the General tab, set properties as described below.
If both the RSM Manager and Compute Server services will be on the submission host of the cluster, set
Machine Name to localhost. Otherwise, enter the network name of the submission host node that will run
the Compute Server.
In the example below, pbsclusternode1 is the name of the submission host being defined as the
Compute Server.
Select This Compute Server is integrating with an HPC cluster.
Since we are not using SSH in this example, set the How does this Compute Server communicate with
the cluster? property to Able to directly submit and monitor cluster jobs.
When you select this, Working Directory Location is set to Shared Cluster Directory (read-only)
and Working Directory Path is disabled.
130
Add a Linux Submission Host as a Compute Server
Cluster Tab
On the Cluster tab, set properties as described below.
Set Cluster Type to LSF, PBS Pro, TORQUE with Moab, or UGE (SGE).
If you set Cluster Type to SGE, enter names for the predefined Shared Memory Parallel and Distributed
Parallel environments that will be used for parallel processing.
These fields default to pe_smp and pe_mpi. To use one of the default names, your cluster administrator must create a PE with the same name. The default PE names can also be edited to match the
names of your existing parallel environments.
For detailed descriptions of these and the other properties, see Properties on the Cluster Tab (p. 71).
When you are finished entering values on the Cluster tab, click OK.
File Management Tab

Compute Server and the cluster.
(Samba, CIFS, NSF).
For Cluster Network Share, enter the path of the network share that will be used to transfer files between
the Compute Server and the remote computer. (If you check back on the General tab, the value entered
here for Cluster Network Share is populated read-only to the Working Directory Path property.)
Leave the In which directory does the cluster job run? property set to In the shared cluster directory selected. When this option is selected, the Shared Cluster Directory and the Working Directory are in the
same location and cluster jobs are run here.
Mount this directory on all execution hosts so that the cluster job has access.
131
Cluster
Note
the Remote Computer? property to In a scratch directory local to the execution node,
and then you must enter a path for Cluster Scratch Directory.
In this case, the Cluster Scratch Directory and the Working Directory are the same location,
so cluster jobs will be run locally on the cluster execution node. The path to this directory
must exist on all nodes.
Tab (p. 72).
C.2. Complete the Configuration

Create a queue.
To complete the configuration, create a new queue and add the Compute Server to it. The RSM queue
name must match the cluster queue name exactly (where the cluster queue name can be found by executing
the LSF bqueues command or the PBS Pro qstat -Q command on the cluster head node).
Jobs can now be submitted to this queue and then forwarded to the cluster queue for scheduling. See
Creating a Queue (p. 61) for details.

Test the configuration by right-clicking on the newly added Compute Server in tree view and selecting
Test. You can also select Advanced Test; the resulting dialog box allows you to choose both the type
of test (basic or file transfer) and the directory in which the test job will be run. The Job Log view displays
132
Additional Cluster Details

a log message that shows if the test finished or failed. If the test finishes, you can successfully run jobs
on the Compute Server.
When the Compute Server is part of a cluster:
When the server test is performed from a compute server node under a Queue parent node, the name of
the parent queue will be used by default.
For cluster types other than Microsoft HPC, you must have already defined a queue in order to perform a
server test from a compute server node under a Compute Servers parent node. If no queue is defined, you
will receive an error.
For both of these scenarios, you can define a cluster queue and specify that it is used for subsequent
server tests. To do so:
1. Right-click the compute server node and select Properties.
2. In the Compute Server Properties dialog box, open the Cluster tab.
3. In the Job Submission Arguments (optional) field, enter the following argument:
-q queuename
4. Click OK.
Note
If -q <queuename> is entered from Job Submission Arguments (optional) field, this
queue name is always used, even when you submit a job or perform server test from a
compute server node under a Queue parent node. In other words, the -q <queuename>
argument takes a higher priority in specifying the cluster queue to be used.
C.3. Additional Cluster Details

Adjusting the Maximum Number of Jobs
You can set the Max Running Jobs property on the General tab to the value appropriate to your
cluster. Note that the RSM job could be in a Running state, but LSF, PBS Pro, TORQUE with Moab, or
UGE (SGE) may not yet be able to execute the job due to limited resources. Refer to the Job Log view
to determine the job ID and state.
Integration Details
RSM essentially forwards the job to the LSF, PBS Pro, TORQUE with Moab, or UGE (SGE) job scheduler.
This RSM job must build and execute the job submission command of the scheduler youve selected
in the Cluster Type drop-down of the Cluster tab of the Compute Server Properties dialog box. The
RSM job does not really do any real work; rather, it monitors the status of the job it has submitted to
the job scheduler, performing the actions listed below:
1. Reads the control file containing paths, inputs and outputs.
2. Makes temporary directories on all nodes assigned for the job.
133
Cluster
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.
134
Appendix D. Integrating RSM with a Microsoft HPC Cluster

The following sections divide the setup and configuration process for integrating RSM with a Windowsbased Microsoft HPC (High-Performance Computing) cluster. The sequential parts are followed by additional information about working with a Microsoft HPC cluster.
Before You Begin

A Microsoft HPC cluster has been established and configured.
You have administrative privileges on the head node of the HPC cluster you are configuring.
You have the machine name of the HPC head node.
You have already configured and verified communications between RSM and the HPC head node. See the
HPC installation tutorials on the Downloads page of the ANSYS Customer Portal. For further information
about tutorials and documentation on the ANSYS Customer Portal, go to http://support.ansys.com/docinfo.
RSM is installed on the HPC head node. This allows you to use both 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.
You are able to install and run ANSYS, Inc. products, including Licensing, on both Windows and Linux systems.
For information on product and licensing installations, go to the Downloads page of the ANSYS Customer
Portal. For further information about tutorials and documentation on the ANSYS Customer Portal, go to http://
support.ansys.com/docinfo.
D.1. Configure RSM on the HPC Head Node

1. In your RSM installation directory, navigate to C:\Program Files\ANSYS Inc\v160\RSM\bin.
2. Configure and start RSM services on the head node by running the following command from the command
prompt:
AnsConfigRSM.exe -mgr -svr
3. Set your RSM password. This is the password RSM will use to run jobs on the Compute Server.
4. Note that you need to update your RSM password when you update your password on the RSM client
machine.
For details, see Working with Account Passwords (p. 54).
135
D.2. Add the HPC Head Node as a Compute Server

Underneath the Manager node on the RSM tree view, right-click the Compute Server node and select
Add. The Compute Server Properties dialog box displays. See Adding a Compute Server (p. 64) for
more detailed information on properties available on the Compute Server Properties dialog box.
General Tab
On the General tab, set properties as described below.
Set Machine Name to localhost if both the RSM Manager and Compute Server services will run on the head
node of the cluster. Otherwise, enter the network name of the head node machine that will run the Compute
Server.
In the example below, HPCHeadNode is the network name of the head node being defined as the
Compute Server.
Select This Compute Server is integrating with an HPC cluster.
Since we are not using SSH in this example, leave the How does this Compute Server communicate with
the cluster? property set to Able to directly submit and monitor cluster jobs.
With this selected, Working Directory Location is set to Shared Cluster Directory (read-only) and
Working Directory Path is disabled.
136
Add the HPC Head Node as a Compute Server
Cluster Tab
On the Cluster tab, set the Cluster Type property to Windows HPC.
For detailed descriptions of these and the other properties, see Properties on the Cluster Tab (p. 71).
137
File Management Tab

Compute Server and the cluster.
(Samba, CIFS, NSF).
For Cluster Network Share, enter the path of the network share that will be used to transfer files between
the Compute Server and the remote computer. (If you check back on the General tab, the value entered
here for Cluster Network Share is populated read-only to the Working Directory Path property.)
Leave the In which directory does the cluster job run? property set to In the shared cluster directory.
When this option is selected, the Shared Cluster Directory and the Working Directory are in the same
location and cluster jobs are run here.
Mount this directory on all execution nodes so that the cluster job has access. This directory should
be accessible by all execution nodes and must be specified by a UNC (Universal/Uniform Naming
convention) path.
Note
If you will be sending CFX jobs to a Microsoft HPC Compute Server, the In the shared cluster
directory option will always be used, regardless of the propertys setting.
138
Complete the Configuration
Note
the Remote Computer? property to In a scratch directory local to the execution node,
and then must enter a path for Cluster Scratch Directory.
In this case, the Cluster Scratch Directory and the Working Directory are the same location, so cluster
jobs will be run locally on the cluster execution node. The path to this directory must exist on all nodes.\
Tab (p. 72).
Test the Compute Server

Test the configuration by right-clicking on the newly added Compute Server in the tree view and selecting
Test Server from the right-click context menu.
D.3. Complete the Configuration

Configure a queue.
To complete the configuration, create a new queue and add the Compute Server to it. Jobs can now
be submitted to this queue and then forwarded to the Microsoft HPC cluster for scheduling. See Creating
a Queue (p. 61) for details.
139

Test the configuration by right-clicking on the newly added Compute Server in tree view and selecting
Test. You can also select Advanced Test; the resulting dialog box allows you to choose both the type
of test (basic or file transfer) and the directory in which the test job will be run. The Job Log view 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.
Test the cluster configuration by submitting a job to RSM.
D.4. Additional HPC Details

Integration Details
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 youve selected in the Cluster Type drop-down of the
Cluster tab of the Compute Server Properties dialog box. The RSM job does not really do any real
work; rather, it monitors the status of the job it has submitted to HPC, performing the actions listed
below:
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 node.
4. Runs the command (for example, solver).
5. Copies the outputs to the staging folder on the head node.
6. Cleans up.
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 used cores 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.
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.
However, if you still see the error messages regarding the password in the RSM log, such as "Failed to
cache password with HPC" or "Account password MUST be cached with MS Compute Cluster," you may
need to verify that the Service Packs for Microsoft HPC Pack and Windows Server have been properly
installed. If you have not installed the Service Packs, you may still need to run cluscfg setcreds
command from cluster head node to cache the HPC password.
Temporary Directory Permissions on Windows Clusters

Some applications executed through RSM (for example, Fluent) require read/write access to the system
temporary directory on local compute nodes. The usual location of this directory is C:\WINDOWS\Temp.
140
Additional HPC Details

All users should have read/write access to that directory on all nodes in the cluster to avoid job failure
due to temporary file creation issues.
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. 18) for configuration instructions.
Network Path Configuration

If the RSM working directory or ANSYS software installation is referenced using a UNC path specification
(for example, \\nodename\path), refer to 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.
Troubleshooting
If RSM jobs submitted to a Microsoft HPC cluster are failing for unknown reasons, you can gain additional
diagnostic information by running the HPC Job Manager (supplied as part of the Microsoft HPC Pack),
selecting the failed job, and examining the output section of the jobs tasks.
Depending on the installed version of Microsoft HPC, registry modification may be required to enable
the execution of commands via UNC paths. Special configuration is required if the task shows the following error:
UNC paths are not supported. Defaulting to Windows directory.
Input Error: Can not find script file "C:\Windows\ClusterJob.py".
To resolve this issue, create a text file of the following contents and save to a file (for example, 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
141

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.
142
Glossary
Abort
The Abort command immediately terminates a running job. Jobs terminated via this command have a Status of Canceled.
alternate account
An alternate account is necessary if the remote Compute Server machine

does not recognize the primary account used on the RSM Client machine.
An alternate account allows you to send jobs from the primary account
on the RSM Client machine and run them on a remote Compute Server
under the alternate account.
client application
A client application is the ANSYS application run on the local RSM Client
machine and is used to submit jobs to RSM, and then to solve those jobs
as managed by RSM. Examples include ANSYS Workbench, ANSYS Fluent,
ANSYS CFX, and so on.
client-side integration
A client-side integration is a custom integration scenario in which RSM

functionality is replaced by the 3rd-party scripts. Only a thin layer of the
RSM architecture is involved, in order to provide the APIs for execution
of the custom scripts, which are located on the client machine.
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.
Compute Server
A Compute Server is a machine on which jobs are run. In most cases, a

Compute Server is a remote machine, but it can also be your local machine ("localhost").
compression threshold
The compression threshold is the lower limit at which larger files will
be compressed before transferring them. File compression reduces file
sizes, so is useful for file transfers on slower networks.
custom cluster integration
Custom cluster integration is the mechanism provided by RSM that allows third parties to use custom scripts to perform the tasks needed to
integrate ANSYS Workbench with the cluster. Both client-side and serverside customizations are possible.
daemon services
Daemon services are scripts or programs that run persistently in the

background of the machine, and which are usually executed at startup.
RSM services are recommended to be installed as daemon service. Once
an RSM service is installed as a daemon, it will be started automatically
without rebooting. The next time the machine is rebooted, the installed
service will be started automatically.
execution node
An execution node is a machine in a cluster that actually executes jobs

that have been submitted. Jobs are distributed from the cluster head
node/submission host to be run on available execution nodes.
head node
The head node is the machine in a cluster that is configured as the

control center for communications between the RSM Manager and the
execution nodes in the cluster. Typically, it serves as the submission host;
it accepts jobs from the RSM Manager (which, in some cases, may be
143
Glossary
installed on the head node itself ) and distributes them across the cluster
for execution.
Interrupt
The Interrupt command terminates a running job, but allows for cleanup of running processes before termination. Jobs terminated via this
command have a Status of Finished.
job
A job consists of a job template, a job script, and a processing task submitted from a client application such as ANSYS Workbench. An example
of a job is the update of a group of design points for an ANSYS Mechanical simulation.
job log
In the main RSM window, the job log displays the progress and log
messages for the job selected in the list view.
job script
A job script is a component of an RSM job. It runs an instance of the

client application on the Compute Server(s) used to run the processing
task.
job template
A job template is a component of an RSM job. It is an XML file that

specifies input and output files of the client application.
LSF
IBM Platform Load Sharing Facility is a batch queuing system supported

by RSM.
native mode
Native mode is the recommended cross-platform RSM configuration, in

which a Linux Compute Server has RSM installed and running locally so
that the SSH protocol isnt needed to provide communications between
a Windows Compute Server and a Linux Compute Server.
non-root privileges
Non-root privileges give the user a limited subset of administrative

privileges. With RSM, non-root privileges are conferred by an rsmadmin
account (that is, membership to the rsmadmins user group. It is recommended that non-root privileges are used for starting and running RSM
services.
OS Copy
OS Copy is a method of file transfer provided by RSM which allows for

full utilization of the network bandwidth and uses direct access to directories across machines.
parallel processing
In parallel processing, jobs are executed on multiple CPU cores simultaneously.
parallel environment (PE)
A parallel environment allows for parallel execution of jobs. By default,

RSM is configured to support Shared Memory Parallel and Distributed
Parallel environments for SGE clusters.
PBS Pro
Altair PBS Professional is a batch queuing system supported by RSM.
primary account
A primary account is the main account that is used to access the RSM
Client machine. Typically, it is the account used with the client application
(ANSYS Workbench) on the RSM Client machine.
144
queue
A queue is a list of one or more Compute Servers available to run jobs.

When a job is sent to a queue, the RSM Manager selects an idle Compute
Server in the queue to execute the job.
root privileges
Root privileges give the user administrative access to all commands and
files on a Linux system. It is recommended that root privileges are not
used for starting and running RSM services.
RSM Admins group
The RSM Admins group is a Windows user group that confers administrative privileges for RSM. Also refers to the privileges conferred on
members of this group (that is, RSM Admins privileges).
RSM Client
The RSM Client is the local machine from which RSM jobs are submitted
to a Compute Server. It runs both RSM and a client application such as
ANSYS Workbench.
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). The RSM Manager service can
be run locally (on the same machine as the RSM Client) or remotely (on
a standalone remote machine or as part of a cluster). For clusters, it is
typically installed on the head node.
In the RSM interface, the RSM Manager may be referred to as the
Solve Manager or simply as the Manager.
rsmadmin user account
An rsmadmin user account is a Linux account with membership in the

rsmadmins user group; as such, the account has RSM administrative
privileges.
rsmadmins user group
The rsmadmins user group is a Linux user group that confers administrative privileges for RSM.
scratch space
Using scratch space is the practice of storing solver files in a local directory on the Compute Server machine. Recommended to optimize performance when there is a slow network connection between execution nodes
and the Shared Cluster Directory or when the solver used produces many
relatively large files.
serial processing
In serial processing, jobs are executed on only one CPU core at a time.
server-side integration
Server-side integration is a custom integration scenario in which RSM

is used in conjunction with a cluster (either supported or unsupported),
with the cluster head node typically configured as both RSM Manager
and Compute Server. The cluster acts as a server with respect to the RSM
Client where from the jobs are submitted.
SGE
Sun Grid Engine is not technically supported by RSM because UGE is

the latest version, though many SGE installations will still work without
modification. See UGE.
SSH
Secure Shell is a network protocol providing a secure channel for the

exchange of data between networked devices. RSM can use SSH for cross-
145
Glossary
platform communications, but native mode is the recommended method.
See native mode.
submission host
A submission host is the machine or cluster node to which the RSM

Manager submits jobs. In most cluster scenarios, the RSM Manager is installed on the head node of a cluster; in this case, the submission host,
head node, and RSM Manager are all the same machine.
TORQUE
An open-source resource manager based on OpenPBS that provides

control over batch jobs and distributed compute nodes.
UGE
Univa Grid Engine is a batch queuing system supported by RSM.
146
Explicit Dynamics systems, 16
Index
F
A
accounts, 47
alternate, 52
changing passwords, 56
Linux with SSH, 57
password, 54
primary, 50
set password manually, 57
setting passwords, 54
adding a Compute Server, 64
administration, 59
C
client application
defining, 1
file handling, 4
integration, 5
integration with Workbench, 5
supported solvers, 5
clusters
integration, 6
code template, 1, 75
Compute Server
adding a Compute Server, 64
Compute Server properties, 64-65
Cluster tab, 71
General tab, 65
Remote tab, 70
defining, 1
file handling, 4
remotely connecting to a Compute Server, 18
startup scripts, 12
testing, 73
configuration file, 27
configuring RSM
Linux, 11
multi-user machines, 16
multiple network interface cards, 18
remote computing, 11, 17
starting Linux RSM services at boot time, 13
Windows, 9
Configuring RSM
RSM Setup Wizard, 109
configuring RSM Services, 9
custom architecture, 75
custom integration, 75
E
EKM Servers, 12
file handling, 4
File Transfer, 19
Network Files Systems, 25
OS Copy, 19
I
installing RSM, 7
service installation, 10
Installing RSM
RSM Setup Wizard, 109
integrating
using LSF, PBS or TORQUE, 129
using Microsoft HPC, 135
using SSH/SCP, 119
J
job
defining, 1
job template, 75
L
Linux
configuration, 11
Explicit Dynamics systems, 16
native mode, 11
remote computing, 11
starting services at boot time, 13
Linux Path considerations, 16
LSF, 129
M
mapped drives, 105
Microsoft HPC, 135
multi-user machines, 16
N
native mode, 11
Network File System, 4
Network Files Systems, 25
O
OS Copy Operation, 19
P
passwords, 47
caching, 54
caching manually, 57
changing, 56
147
Index
setting, 54
PBS, 129
primary, 50
Compute Server, 12
EKM Servers, 12
RSM Manager, 12
supported clusters, 6
Q
T
queue
creating, 61
defining, 1
R
remote computing
configuration, 17
remotely connecting to a Compute Server, 18
remotely connecting to an RSM Manager, 17
Remote Solve Manager Setup Wizard, 109
RSM Client
defining, 1
file handling, 4
RSM Manager
file handling, 4
remotely connecting to an RSM Manager, 17
RSM Manager properties, 62
startup scripts, 12
RSM Solve Manager
defining, 1
RSM user interface
Accounts dialog box, 42
context menu, 43
desktop alert window, 41
Job Log, 32
Job Log View, 39
List View, 32, 37
main window, 32
Menu Bar, 32
Notification Area icon, 43
Options dialog, 40
server test dialog, 43
Status Bar, 32, 39
system tray icon, 43
Toolbar, 32, 34
Tree view, 32, 34
terminology, 1
third-party job schedulers
integration, 6
TORQUE, 129
troubleshooting, 105
U
user interface, 31
W
Windows
configuration, 9
installation, 10
integration with Linux using SSH/SCP, 119
integration with Platform LSF, PBS Pro or TORQUE
Cluster, 129
Wizard for RSM Setup, 109
workflows, 2
S
server test, 43
Setup Wizard, 59
SSH
integrating Windows with Linux, 119
job limitations, 120
selecting a remote computing mode, 11
SSH/SCP configuration, 119
starting RSM services manually, 12
startup scripts
148

ANSYS Remote Solve Manager - Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ANSYS Remote Solve Manager - Guide

Uploaded by

Copyright:

Available Formats

ANSYS Remote Solve Manager User's Guide

Copyright and Trademark Information

U.S. Government Rights

Remote Solve Manager (RSM)

Remote Solve Manager (RSM)

Chapter 1: RSM Overview

1.1. RSM Roles and Terminology

1.2. Typical RSM Workflows

Typical RSM Workflows

1.3. File Handling

RSM Integration with ANSYS Client Applications

1.4. RSM Integration with ANSYS Client Applications

1.4.1. RSM Supported Solvers

1.4.2. RSM Integration with Workbench

1.5. RSM Supported Third-Party Job Schedulers/Commercial BatchQueuing Systems

Chapter 2: RSM Installation and Configuration

2.1. RSM Software Installation

2.1.1. Installing a Standalone RSM Package

RSM Installation and Configuration

2.2. Using the RSM Setup Wizard

2. Configure the machines to be included in your RSM Layout.

RSM Service Installation and Configuration

2.3. RSM Service Installation and Configuration

2.3.1. Installing and Configuring RSM Services for Windows

RSM Installation and Configuration

2.3.1.1. Installing RSM Services for Windows

RSM Command Line Options for Windows

Configuring RSM Services to Start Automatically at Boot Time for Windows

5. Run the command.

RSM Service Installation and Configuration

2.3.2. Installing and Configuring RSM Services for Linux

2.3.2.1. Configuring RSM to Use a Remote Computing Mode for Linux

Uses RSM application to execute

Uses an external SSH application to

Requires RSM to be installed and

Requires installation of SSH client (Putty

Most efficient data transfer for

Communication overhead slows solution

Supported on Windows & Linux only

Supported on all platforms

Configuring Native Cross-Platform Communications

RSM Installation and Configuration

Adding Common Job Environment Variables for Native Jobs

2.3.2.2. Installing RSM Services for Linux

2.3.2.2.1. Starting RSM Services Manually for Linux

RSM Service Installation and Configuration

2.3.2.2.1.1. Manually Running RSM Service Scripts for Linux

Stopping an RSM Service Manually

Checking the Status of an RSM Service Manually

Restarting an RSM Service Manually

2.3.2.2.2. Starting RSM Services Automatically at Boot Time for Linux

RSM Installation and Configuration

2.3.2.2.2.1. Installing RSM Automatic Startup (Daemon) Services for Linux

Daemon Service Installation Methods

RSM Service Installation and Configuration

Installing RSM Services as Daemons

Checking the Status of the Daemon Service

Restarting the Daemon Service

RSM Installation and Configuration

2.3.2.3. Additional Linux Considerations

Linux Path Configuration Requirements

RSH/SSH Settings for Inter/Intra-Node Communications

Explicit Dynamics Systems