Ansys Remote Solve Manager User's Guide

Ansys Remote Solve Manager User's Guide
ANSYS, Inc. Release 2022 R1

Southpointe January 2022
2600 Ansys Drive
Canonsburg, PA 15317 ANSYS, Inc. and
[email protected] ANSYS Europe,
Ltd. are UL
http://www.ansys.com registered ISO
(T) 724-746-3304 9001: 2015
(F) 724-514-9494 companies.
Copyright and Trademark Information
© 2022 ANSYS, Inc. Unauthorized use, distribution or duplication is prohibited.
ANSYS, Ansys Workbench, AUTODYN, CFX, FLUENT 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 located 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. FLEXlm and FLEXnet are trademarks of Flexera Software LLC.
Disclaimer Notice
THIS ANSYS SOFTWARE PRODUCT AND PROGRAM DOCUMENTATION INCLUDE TRADE SECRETS AND ARE CONFID-
ENTIAL 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. and ANSYS Europe, Ltd. are UL registered ISO 9001: 2015 companies.
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, contact ANSYS, Inc.
Published in the U.S.A.

Table of Contents
1. RSM Overview ....................................................................................................................................... 11
1.1. RSM Roles and Terminology ............................................................................................................ 12
1.2. How RSM Works .............................................................................................................................. 14
1.3. File Handling .................................................................................................................................. 15
1.4. RSM Integration with Ansys Applications ......................................................................................... 16
1.4.1. RSM-Supported Applications and Solvers ............................................................................... 16
1.4.2. RSM Integration with Workbench ........................................................................................... 17
1.5. RSM Supported Third-Party Job Schedulers/Commercial Batch-Queuing Systems ............................ 17
2. RSM Installation and Startup ................................................................................................................ 19
2.1. RSM Software Installation ................................................................................................................ 19
2.1.1. Installing a Standalone RSM Package ...................................................................................... 19
2.2. Installing and Configuring the RSM Launcher Service ...................................................................... 20
2.2.1. Supported Platform Combinations ......................................................................................... 20
2.2.1.1. Configuring Windows-to-Linux Communication ............................................................. 20
2.2.2. Installing and Configuring the RSM Launcher Service for Windows .......................................... 21
2.2.3. Installing and Configuring the RSM Launcher Service for Linux ................................................ 22
2.2.3.1. Adding Common Job Environment Variables for Jobs ..................................................... 22
2.2.3.2. Installing the RSM Launcher Service for Linux ................................................................. 23
2.2.3.2.1. Starting the RSM Launcher Service Manually for Linux ........................................... 23
2.2.3.2.1.1. Manually Running the RSM Launcher Service Script for Linux ........................ 24
2.2.3.2.2. Starting the RSM Launcher Service Automatically at Boot Time for Linux ................ 24
2.2.3.2.2.1. Installing the RSM Automatic Startup (Daemon) Service for Linux .................. 25
2.2.3.2.2.2. Working with the RSM Automatic Startup (Daemon) Service for Linux ........... 26
2.2.4. Configuring a Network Installation of RSM .............................................................................. 27
2.3. Uninstalling RSM ............................................................................................................................. 28
2.4. Uninstalling the RSM Launcher Service ............................................................................................ 28
2.4.1. Uninstalling the RSM Launcher Service for Windows ............................................................... 28
2.4.2. Manually Uninstalling the RSM Launcher Service for Linux ...................................................... 29
2.4.3. Uninstalling the RSM Automatic Startup (Daemon) Service for Linux ....................................... 29
3. RSM Configuration ................................................................................................................................ 31
3.1. Setting the RSM Configuration Directory ......................................................................................... 32
3.2. Launching the RSM Configuration Application ................................................................................ 33
3.3. Defining RSM Configurations .......................................................................................................... 33
3.3.1. Creating a New RSM Configuration ......................................................................................... 35
3.3.2. Specifying RSM Configuration Settings ................................................................................... 35
3.3.2.1. Specifying HPC Resource Information ............................................................................ 36
3.3.2.2. Specifying File Management Properties ......................................................................... 41
3.3.2.2.1. File Management Properties for a Cluster .............................................................. 41
3.3.2.3. Defining and Testing RSM Queues .................................................................................. 49
3.3.3. Deleting an RSM Configuration ............................................................................................... 54
3.4. Sharing and Accessing RSM Configurations ..................................................................................... 54
3.5. Setting Up Job Directories and File Transfers .................................................................................... 57
3.5.1. Setting Up Client Working Directories to Eliminate the Need for File Transfers .......................... 58
3.5.2. Enabling OS Copy to the HPC Staging Directory ...................................................................... 58
3.5.2.1. Windows-to-Windows File Transfer ................................................................................. 58
3.5.2.2. Linux-to-Linux File Transfer ............................................................................................ 59
3.5.2.3. Windows-to-Linux File Transfer ...................................................................................... 59
3.5.3. Configuring a Computer with Multiple Network Interface Cards (NICs) .................................... 60
3.5.4. Using SSH for File Transfers ..................................................................................................... 61
Release 2022 R1 - © ANSYS, Inc. All rights reserved. - Contains proprietary and confidential information
of ANSYS, Inc. and its subsidiaries and affiliates. iii
Remote Solve Manager (RSM)
3.5.5. Custom Client Integration ...................................................................................................... 61

4. Ansys RSM Cluster (ARC) Configuration ............................................................................................... 63
4.1. Important Considerations and Requirements for the Ansys RSM Cluster (ARC) .................................. 64
4.2. Overview of an Ansys RSM Cluster (ARC) Configuration .................................................................... 64
4.3. The Default 'Localhost' Configuration .............................................................................................. 68
4.4. Creating and Deploying an Ansys RSM Cluster (ARC) ........................................................................ 70
4.4.1. Prerequisites for ARC Configuration ........................................................................................ 71
4.4.2. Configuring an Ansys RSM Cluster (ARC) Using the ARC Configuration Application .................. 71
4.4.3. Configuring an Ansys RSM Cluster (ARC) Using the Command Line (arcdeploy) ........................ 81
4.5. Defining an RSM Configuration for an Ansys RSM Cluster (ARC) ........................................................ 86
4.6. Ansys RSM Cluster (ARC) Command Usage and Options ................................................................... 88
4.6.1. Installing ARC Cluster Services on Windows (installservice) ...................................................... 88
4.6.1.1. Installing the ARC Master Service on a Windows Head Node ........................................... 89
4.6.1.2. Installing the ARC Node Service on Windows Execution Nodes ....................................... 89
4.6.2. Uninstalling ARC Cluster Services on Windows (uninstallservice) ............................................. 89
4.6.3. Installing ARC Cluster Services on Linux .................................................................................. 89
4.6.3.1. Adding Common Environment Variables for an ARC on Linux ......................................... 90
4.6.3.2. Starting ARC Cluster Services Manually on Linux (arcmaster | arcnode) ........................... 90
4.6.3.3. Starting ARC Cluster Services Automatically at Boot Time for Linux (install_daemon) ...... 91
4.6.4. Uninstalling ARC Cluster Daemon Services on Linux (uninstall_daemon) ................................. 92
4.6.5. Commands for ARC Job Management ..................................................................................... 92
4.6.5.1. Submitting a Job (arcsubmit) ......................................................................................... 92
4.6.5.2. Getting the Status of a Job (arcstatus) ............................................................................ 93
4.6.5.3. Cancelling a Job (arckill) ................................................................................................. 94
4.6.6. Configuring ARC Cluster Nodes (arcconfig node modify) ......................................................... 94
4.6.6.1. Associating ARC Execution Nodes with the Master Node ................................................ 95
4.6.6.2. Setting the Maximum Number of Cores to be Used on an Execution Node ...................... 95
4.6.6.3. Setting the Maximum Resource Allocation on an Execution Node ................................... 96
4.6.7. Displaying Resource Availability on ARC Nodes (arcnodes) ...................................................... 97
4.6.8. Configuring ARC Queues (arcconfig queue) ............................................................................ 97
4.6.8.1. Adding a Cluster Queue ................................................................................................. 98
4.6.8.2. Removing a Cluster Queue ............................................................................................. 98
4.6.8.3. Modifying a Cluster Queue ............................................................................................ 98
4.6.9. Displaying the Status and Details of ARC Queues (arcqueues) .................................................. 99
4.6.10. Caching Credentials for Cluster Job Submission (arccredentials) .......................................... 100
4.6.11. Migrating an ARC Setup from a Previous Version (arcconfig migration) ................................ 100
4.7. Setting the ARC_ROOT Environment Variable for Ansys RSM Cluster (ARC) Job Submission ............. 103
4.8. Dealing with a Firewall in a Multi-Node Ansys RSM Cluster (ARC) .................................................... 103
4.9. Example: Setting Up a Multi-Node Ansys RSM Cluster (ARC) ........................................................... 104
5. RSM Integration with a Cluster or Cloud Portal .................................................................................. 121
5.1. Configuring RSM to Use SSH for Job Submission and/or File Transfers to a Remote Linux Cluster ..... 121
5.1.1. Defining a Configuration for a Remote Linux Cluster (SSH) .................................................... 122
5.1.2. Configuring PuTTY SSH ........................................................................................................ 123
5.1.3. Linux Path Configuration Requirements ................................................................................ 127
5.2. Integrating RSM with a Microsoft HPC or Windows-Based Cluster ................................................... 127
5.3. Integrating RSM with a Cloud Portal .............................................................................................. 129
6. RSM User Accounts and Passwords ..................................................................................................... 131
6.1. Automatic Account Creation ......................................................................................................... 131
6.1.1. Credential Caching from Workbench .................................................................................... 132
6.2. Adding a User Account .................................................................................................................. 132
6.3. Changing an Account Password .................................................................................................... 134
iv of ANSYS, Inc. and its subsidiaries and affiliates.
6.4. Deleting a User Account ................................................................................................................ 134

6.5. Manually Running the Password Application ................................................................................. 135
7. RSM Settings and Utilities ................................................................................................................... 137
7.1. Specifying the Job Cleanup Period ................................................................................................ 137
7.2. Performing Administrative Tasks with the RSM Utilities Application ................................................ 138
7.2.1. Managing RSM Configurations and Queues (rsm.exe | rsmutils config) ................................... 138
7.2.1.1. Creating an RSM Configuration .................................................................................... 139
7.2.1.2. Deleting a Configuration .............................................................................................. 143
7.2.1.3. Creating an RSM Queue ............................................................................................... 143
7.2.1.4. Deleting an RSM Queue ............................................................................................... 143
7.2.1.5. Listing RSM Configurations and Queues ....................................................................... 144
7.2.2. Editing RSM Application Settings (rsm.exe | rsmutils appsettings) .......................................... 145
7.2.2.1. Specifying a Port Range for User Proxy Processes .......................................................... 146
7.2.2.2. Specifying a Port Range for User Proxy Socket File Transfers .......................................... 146
7.2.2.3. Specifying a Directory for RSM Configuration Files ........................................................ 147
7.2.2.3.1. Querying the Location of the RSM Configuration Directory .................................. 147
7.2.2.3.2. Specifying the Location of the RSM Configuration Directory ................................. 147
7.2.3. Managing Credentials for RSM Queues (rsm.exe creds) .......................................................... 148
7.2.3.1. Caching Credentials for an RSM Queue ......................................................................... 149
7.2.3.2. Validating Credentials for an RSM Queue ...................................................................... 149
7.2.3.3. Listing the RSM Configurations Associated with an Account ......................................... 150
7.2.3.4. Listing the Accounts Associated with an RSM Queue .................................................... 150
7.2.4. Migrating RSM from a Previous Version ................................................................................. 150
7.3. Refreshing the View ...................................................................................................................... 153
8. RSM Custom Integration ..................................................................................................................... 155
8.1. Understanding RSM Custom Architecture ...................................................................................... 155
8.1.1. Job Templates ...................................................................................................................... 155
8.1.2. Job Scripts ........................................................................................................................... 156
8.1.3. HPC Commands File ............................................................................................................. 157
8.1.4. Job Configuration File .......................................................................................................... 157
8.2. Custom Cluster Integration Setup .................................................................................................. 159
8.2.1. Customizing Cluster-Side Integration .................................................................................... 160
8.2.1.1. Creating Copies of Standard Cluster Code Using a Custom Cluster Keyword .................. 160
8.2.1.2. Modifying the Job Configuration File for a New Cluster Type ......................................... 161
8.2.1.3. Modifying the Cluster-Specific HPC Commands File ...................................................... 161
8.2.1.4. Creating a Configuration for the Custom Cluster ........................................................... 164
8.2.2. Customizing Client-Side Integration ...................................................................................... 165
8.2.2.1. Creating Copies of Sample Code Using a Custom Client Keyword .................................. 166
8.2.2.2. Modifying the Job Configuration File for a New Cluster Type ......................................... 167
8.2.2.3. Modifying the Cluster-Specific HPC Commands File ...................................................... 168
8.2.2.4. Creating a Configuration for the Custom Cluster ........................................................... 169
8.2.3. Configuring SSH/Custom File Transfers ................................................................................. 170
8.3. Writing Custom Code for RSM Integration ...................................................................................... 172
8.3.1. Parsing of the Commands Output ......................................................................................... 173
8.3.1.1. Getting Output from Primary Commands in the Parsing Scripts .................................... 173
8.3.1.2. Outputting Variables from the Parsing Scripts ............................................................... 173
8.3.1.3. Required Output from Commands ............................................................................... 173
8.3.1.4. Commands Output in the RSM Job Log ........................................................................ 175
8.3.2. Customizable Commands ..................................................................................................... 175
8.3.2.1. Submit Command ....................................................................................................... 176
8.3.2.2. queryStatus Command ................................................................................................ 176
of ANSYS, Inc. and its subsidiaries and affiliates. v
8.3.2.3. getAllStatus Command ................................................................................................ 177

8.3.2.4. queryQueues Command .............................................................................................. 177
8.3.2.5. getAllQueues Command .............................................................................................. 177
8.3.2.6. Cancel Command ........................................................................................................ 177
8.3.2.7. createStorage Command ............................................................................................. 178
8.3.2.8. deleteStorage Command ............................................................................................. 178
8.3.2.9. uploadToStorage Command ........................................................................................ 178
8.3.2.10. downloadFromStorage Command ............................................................................. 178
8.3.2.11. listStorageContents Command .................................................................................. 178
8.3.3. Custom Integration Environment Variables ........................................................................... 178
8.3.3.1. Environment Variables Set by RSM ............................................................................... 179
8.3.3.2. Optional Environment Variables Set by Customer ......................................................... 181
8.3.4. Providing Custom Client Information for Job Submission ...................................................... 181
8.3.4.1. Defining the Environment Variable on the Client .......................................................... 182
8.3.4.2. Passing the Environment Variable to the Cluster ........................................................... 182
8.3.4.3. Verify the Custom Information on the Cluster ............................................................... 183
9. RSM Job Monitoring ............................................................................................................................ 185
9.1. Launching the RSM Job Monitoring Application ............................................................................ 185
9.2. Monitoring Jobs in the RSM Job Monitoring Application ................................................................ 185
9.2.1. Viewing the Status of Jobs .................................................................................................... 187
9.2.2. Enabling Live Job Monitoring ............................................................................................... 187
9.2.3. Controlling the Job List Display ............................................................................................. 188
9.2.4. Filtering the Job List ............................................................................................................. 188
9.3. Viewing a Job Log ......................................................................................................................... 188
9.3.1. Controlling the Job Log Display ............................................................................................ 189
9.3.2. Copying Text in the Job Log Display ...................................................................................... 190
9.3.3. Saving a Job Report .............................................................................................................. 190
9.3.4. Hiding/Showing the Job Log Pane ........................................................................................ 191
9.4. Managing Jobs ............................................................................................................................. 191
9.4.1. Terminating a Job ................................................................................................................. 191
9.4.2. Removing a Job .................................................................................................................... 192
10. RSM Cluster Load Monitoring ........................................................................................................... 193
10.1. Launching the RSM Cluster Load Monitoring Application ............................................................. 193
10.2. Monitoring a Cluster in the RSM Cluster Load Monitoring Application .......................................... 193
10.3. Viewing Cluster Job Information .................................................................................................. 195
10.3.1. Sorting and Filtering the Cluster Job List ............................................................................. 196
10.4. Controlling the Display of Cluster Monitors .................................................................................. 198
11. RSM Troubleshooting ........................................................................................................................ 199
11.1. Accessing RSM Log Files .............................................................................................................. 199
11.2. Troubleshooting RSM-Related Issues ........................................................................................... 200
11.3. Troubleshooting Product-Related Issues ...................................................................................... 206
11.4. Known Issues and Limitations ...................................................................................................... 207
Glossary ................................................................................................................................................... 209
vi of ANSYS, Inc. and its subsidiaries and affiliates.
List of Figures
1.1. General RSM Workflow .......................................................................................................................... 15
of ANSYS, Inc. and its subsidiaries and affiliates. vii
viii of ANSYS, Inc. and its subsidiaries and affiliates.
List of Tables
4.1. Overview of ARC Setup Options ............................................................................................................ 65
4.2. Options for 'arcsubmit' .......................................................................................................................... 92
4.3. Options for 'arcconfig node modify' ...................................................................................................... 94
4.4. Options for 'arcconfig queue modify' ..................................................................................................... 98
4.5. Operators for Migration ....................................................................................................................... 101
4.6. Options for Migration .......................................................................................................................... 101
7.1. Options for Creating an RSM Configuration ......................................................................................... 139
7.2. Arguments Used for Managing Credentials .......................................................................................... 148
7.3. Operators for Migration ....................................................................................................................... 151
7.4. Options for Migration .......................................................................................................................... 151
11.1. Key RSM Log Files .............................................................................................................................. 199
of ANSYS, Inc. and its subsidiaries and affiliates. ix
x of ANSYS, Inc. and its subsidiaries and affiliates.
Chapter 1: RSM Overview
Ansys Remote Solve Manager (RSM) provides the central framework for configuring and monitoring job
submission to HPC resources. Whether jobs are submitted to a cluster or to a Cloud portal, RSM's integ-
rated environment and tools enable you to easily connect to existing IT infrastructure, providing you
with seamless access to powerful compute resources when needed.
Jobs can be submitted directly to RSM from client applications such as Ansys Workbench, or indirectly
via a Cloud portal.
RSM provides the following key capabilities:
• RSM Configuration. Define configurations that enable you to run Ansys applications on HPC resources.
With its wizard-like interface, the RSM Configuration application lets you easily create configurations
for cluster or portal job submission.
RSM configurations enable you to integrate RSM with a third-party job scheduler such as Microsoft
HPC or LSF, or with an Ansys RSM Cluster (ARC). You can also create a configuration for job submission
to a third-party Cloud compute service. Regardless of the resource type, all RSM configurations are
defined in a consistent way.
Configuration tasks include establishing communication protocols, specifying file handling methods,
setting up RSM queues, and caching account credentials. For more information, see RSM Configura-
tion (p. 31).
• Ansys RSM Cluster (ARC). If you are not using a third-party job scheduler such as Microsoft HPC or
LSF, you can use the built-in Ansys RSM Cluster (ARC) system that is provided with every RSM install-
ation. An ARC operates in the same way that a commercial cluster does, running Ansys applications
in local or distributed mode, but uses its own scheduling capability rather than that of a third-party
job scheduler.
An ARC that comprises a single node (whether it be either a user's local machine or a specific machine
in your network) does not require any special setup. An ARC that comprises multiple nodes requires
service configuration and node setup, but provides more powerful features and enables you to run
distributed parallel jobs in a multi-node environment. For more information, see Ansys RSM Cluster
(ARC) Configuration (p. 63).
• Job Monitoring. View the status of submitted jobs, view job logs, and troubleshoot failed jobs directly
from the Workbench, or using the RSM Job Monitoring application.
– For information on monitoring jobs in Workbench, see Monitoring and Controlling Remote Solve
Manager Jobs in Workbench in the Workbench User's Guide.
– For information about monitoring jobs using the RSM Job Monitoring application, see RSM Job
Monitoring (p. 185) in the RSM User's Guide.
The following topics are discussed in this overview:
of ANSYS, Inc. and its subsidiaries and affiliates. 11
RSM Overview
1.1. RSM Roles and Terminology

1.2. How RSM Works
1.3. File Handling
1.4. RSM Integration with Ansys 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 processing task submitted from a client application such as Ansys Workbench. Examples include
solution updates, project updates, and design point updates submitted to RSM for remote processing.
Certain files in RSM are used to define and control RSM jobs. A job script is used to perform a
processing task (such as running a finite element solver). A job template can be used to further
customize a job.
Client Machine
The computer on which Ansys Workbench and Ansys applications are installed, and on which jobs
are submitted to RSM. RSM is automatically installed with Ansys Workbench products.
Client Application
The Ansys application that submits jobs to RSM. Examples include Ansys Workbench, Ansys Fluent,
and Ansys CFX.
HPC Resource
A system that supports High Performance Computing, such as a cluster, or a cloud computing en-
vironment. The system uses a queueing system to make optimal use of all available resources.
Node
A single computer. A multi-node HPC system consists of a head node, where jobs are submitted
for scheduling, and one or more execution nodes, which are used for computational work.
12 of ANSYS, Inc. and its subsidiaries and affiliates.
RSM Roles and Terminology
Note:
• The head node can serve as an execution node as well.
• The local machine (localhost) can be an execution node if it is serving as the HPC
resource.
Queue
A list of execution nodes that are suited to run a particular class of jobs.
When you submit a job to RSM, you submit it to an RSM Queue, which maps to an HPC Queue.
The HPC Queue has one or more execution nodes assigned to it, and determines when and where
the job will run based on resource requests and current available resources. Queue definitions are
part of the configurations that are defined in RSM.
HPC Configuration
A set of properties defined in RSM which specify the following information about an HPC resource:
• HPC type (ARC, Windows HPC, LSF, PBS Pro, SLURM, UGE (SGE), Custom)
• For a cluster, the machine name of submit host
• For a Cloud portal, the URL of the web portal
• Client-to-HPC communication protocols
• File transfer mechanisms, HPC staging directory, HPC job directory
• A set of HPC queues that will be used for running Ansys applications
RSM Overview
1.2. How RSM Works

RSM integrates with many Ansys applications (see RSM Integration with Ansys Applications (p. 16)).
Ansys solvers provide the ability to submit solutions to RSM, and ANSYS WorkbenchAnsys Workbench
enables you to submit project updates, solution component updates, design point updates, and design
optimization studies. This enables you to take advantage of HPC computing resources when performing
computationally intensive tasks.
When you submit a job to RSM, you select an RSM queue in the solve properties. The RSM queue is
associated with a configuration that is defined in RSM. The RSM configuration specifies how the client
machine will communicate with the HPC resource, and identifies HPC queues.
Every RSM installation contains a default Ansys RSM Cluster (ARC) that can be used on the local machine
or configured on a remote machine. For more information see Ansys RSM Cluster (ARC) Configura-
tion (p. 63). If your organization uses a commercial cluster, such as Windows HPC, LSF or PBS Pro, you
can configure RSM to submit jobs to that cluster as well. For more information see RSM Integration
with a Cluster or Cloud Portal (p. 121).
Working with Ansys Support, it is also possible to create a custom configuration that enables users to
submit jobs to a third-party Cloud.
If jobs will be submitted to a remote cluster, a Launcher Service must be installed on the cluster submit
host if the client cannot communicate directly with the remote resource. This service is used to launch
a User Proxy process, which authenticates the account prior to job submission.
Note:
The Launcher Service is not required if SSH is being used as a communication protocol, or
if the remote resource is a Cloud. In these cases, authentication is already taken care of.
The Cluster API manages cluster operations such as handling inputs and outputs, carrying out job
commands, and retrieving cluster status information.
File Handling
Figure 1.1: General RSM Workflow
1.3. File Handling

Generally, when you submit a job to RSM from a client application, job input files are transferred from
the client working directory to an HPC staging directory. When the job has finished, any output files
requested by the client are transferred back to the client application.
Below is more detailed information about how files are handled in RSM.
Client Working Directory
When you are setting up a solve job in a client application (for example, Ansys Workbench), job
input files are placed in a working directory on the client machine. The location of this directory is
controlled by the client application. Refer to the client application documentation to determine
where input files are placed when submitting jobs to RSM.
HPC Staging Directory
The HPC staging directory is a shared directory that all HPC nodes can access.
If the client working directory is always set under the HPC staging directory in the client application,
then no file transfer is needed, because the client files will already be in the HPC staging directory.
If files need to be transferred, you can specify the desired transfer method in the RSM configuration.
RSM Overview
HPC Job Directory
HPC jobs can be run in the HPC staging directory, or in a scratch directory local to the execution
node. You specify this in the File Management properties when defining a configuration in RSM.
File Transfer Methods
RSM provides the following options for transferring files from the client to the HPC resource:
• RSM internal socket file transfer
• Operating System file transfer (network share)
• External mechanism (such as SSH)
• No file transfer (client directory is under the HPC staging directory)
You can also customize the file transfer process using your own mechanism.
In the case of a Cloud portal, client files will be transferred to HPC resources as needed using the
portal mechanism. File management operations related to job execution are configured on the HPC
side.
The file transfer method and HPC staging directory are specified in the File Management properties
of an RSM configuration. For more information, see Specifying RSM Configuration Settings (p. 35).
1.4. RSM Integration with Ansys Applications

RSM is integrated with a number of Ansys applications. Solutions and updates can be submitted to RSM
from Workbench/Mechanical.
When you submit a job to RSM in a client application, you can specify a number of solve settings to be
used for the job. For example, the Mechanical application contains a Max number of used cores setting
that enables you to limit the number of CPUs/nodes allocated for the HPC job. This information is passed
along on the solver command line. The command line is parsed in the job script, and this information
is passed on to the HPC resource.
For information about how RSM integrates with Ansys applications, refer to the following:
1.4.1. RSM-Supported Applications and Solvers
1.4.2. RSM Integration with Workbench
1.4.1. RSM-Supported Applications and Solvers

RSM supports the following applications and solvers:
• Workbench (p. 17)
• CFX
• Fluent
• Forte
RSM Supported Third-Party Job Schedulers/Commercial Batch-Queuing Systems
• Icepak
• Mechanical (excluding the Samcef and ABAQUS solvers)
• Mechanical APDL
• Polyflow
• System Coupling of Mechanical and Fluid solvers
• Explicit Dynamics
• Rigid Body Dynamics
Note:
Rigid Body Dynamics jobs can be submitted only to an Ansys RSM Cluster (ARC).
1.4.2. RSM Integration with Workbench

For information on how RSM integrates with Workbench, see the following topics in the Workbench
User's Guide:
• Working with Ansys Remote Solve Manager
• Submitting System Coupling Jobs to Remote Solve Manager
• Submitting Solutions to Remote Solve Manager
• Updating Design Points in Remote Solve Manager
Many Ansys Workbench applications enable you to use RSM; however, the following considerations
may apply:
• Some applications may not be able to run on remote machines.
• When a client application is restricted to the local machine, RSM may enable the client application
to run in the background.
• When a client application can send jobs to a remote machine, the job may be run completely on
one node, or may be broken into pieces so that each piece can run in parallel on multiple nodes
(possibly including the client machine). In the case where a job is being run in parallel on multiple
machines, you need to ensure that the software that controls the parallel processing (for example,
MPI) is supported on all of the execution nodes.
1.5. RSM Supported Third-Party Job Schedulers/Commercial Batch-

Queuing Systems
RSM supports the following commercial batch-queuing systems on the specified operating systems:
• Platform LSF
RSM Overview
Operating systems: Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise (SLES)
• PBS Professional
• Slurm Workload Manager
• Univa Grid Engine (UGE/SGE)
• Windows HPC
Operating systems: Windows Server 2012 R2 (Standard) with Microsoft HPC Pack 2012 R2, Windows
Server 2016 with HPC Pack
Some stand-alone Ansys applications support a slightly different list of third-party job schedulers. Refer
to the Job Schedulers and Queuing Systems Support document at http://www.ansys.com/solutions/solutions-
by-role/it-professionals/platform-support/previous-releases.
Chapter 2: RSM Installation and Startup
For successful job submission to an HPC resource via RSM, the RSM application must be installed on
the same machine where the client application (for example, Workbench) is installed.
If jobs will be submitted to a remote cluster, then the RSM launcher service must also be installed and
running on the cluster submit host. This does not apply if SSH is being used for client-to-HPC commu-
nication, or if the remote HPC resource is a Cloud.
Important:
If after installing RSM and starting the RSM launcher service you wish to install another Ansys
product using the Ansys unified installer, make sure that you stop the RSM launcher service
before proceeding with the installation, and then restart it after the installation. See Installing
and Configuring the RSM Launcher Service (p. 20).
In this chapter:
2.1. RSM Software Installation
2.2. Installing and Configuring the RSM Launcher Service
2.3. Uninstalling RSM
2.4. Uninstalling the RSM Launcher Service
2.1. RSM Software Installation

RSM is automatically installed with Ansys Workbench products when you use the standard Ansys product
installation.
You can also use the standard Ansys product installation to install RSM by itself (see Installing a Stan-
dalone RSM Package (p. 19)).
Administrator privileges are not required to install or uninstall RSM.
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 the RSM
application and RSM launcher service, but without 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:
RSM Installation and Startup
a. Under Ansys Additional Tools, select the Remote Solve Manager Standalone Services
check box.
b. Deselect all the other check boxes.
3. Continue the installation process as directed.
Note:
When you install a standalone RSM package, this does not mean that the RSM launcher
service is installed at the same time. You still need to install the RSM launcher service on
the cluster submit host. For instructions, see Installing and Configuring the RSM Launcher
Service (p. 20).
2.2. Installing and Configuring the RSM Launcher Service

This step is generally required if jobs will be submitted to a remote cluster from the client machine. It
is not required if the client machine uses SSH as a communication protocol, or if the remote HPC resource
is a Cloud.
You must install the RSM launcher service on the cluster submit host.
Refer to the instructions below that pertain to the machine on which the RSM launcher service is being
installed:
2.2.1. Supported Platform Combinations
2.2.2. Installing and Configuring the RSM Launcher Service for Windows
2.2.3. Installing and Configuring the RSM Launcher Service for Linux
2.2.4. Configuring a Network Installation of RSM
2.2.1. Supported Platform Combinations

The following platform combinations are supported when submitting jobs from an RSM client to an
HPC submit host:
• Windows to Windows
• Linux to Linux
• Windows to Linux
Submitting jobs from a Linux RSM client to a Windows submit host is not supported.
2.2.1.1. Configuring Windows-to-Linux Communication

There are two ways in which you can configure communication between a Windows RSM client
and a Linux submit host:
Installing and Configuring the RSM Launcher Service
Method 1: Use RSM's built-in communication capability (recommended)

This method, which can be used for all supported platform combinations (p. 20), is the most efficient
way for a Windows RSM client to communicate with a Linux cluster.
To use this method, you must install the RSM launcher service on the Linux submit host. This
eliminates the need for an external communication protocol such as SSH, and enables RSM to
communicate directly with the submit host.
There are two options for starting the RSM launcher service on the Linux submit host:
• OPTION A: Run the [RSMInstall]/RSM/Config/tools/linux/rsmlauncher script to

manually start the RSM launcher service.
• OPTION B: Configure RSM to start the RSM launcher service at boot.
For more information refer to Installing and Configuring the RSM Launcher Service for Linux (p. 22).
Method 2: Use the SSH Protocol

This method is not recommended unless your organization's IT policy requires the use of SSH to
communicate with the Linux resource. Using SSH will likely result in slower performance when
launching processes and retrieving results.
For instructions, refer to Configuring RSM to Use SSH for Job Submission and/or File Transfers to a
Remote Linux Cluster (p. 121).
2.2.2. Installing and Configuring the RSM Launcher Service for Windows
When RSM is installed on a Windows machine, you can configure and install the RSM launcher process
as a Windows service so that it can be started automatically when the Windows system starts up. You
can also uninstall and restart the service using RSM-provided tools.
Note:
• The RSM launcher service cannot be started from a network installation. It is recommen-
ded 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 Guides.
To configure the RSM launcher service to start automatically at boot time:
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. Run the following command:
AnsConfigRSM.exe -launcher
Note:
• Windows 7 users may need to select the Run as administrator option.
• Running this command will close any open RSM processes.
If the RSM launcher service has been removed, you can also use the above sequence of steps to re-
configure the service.
Important:
• If you change any system environment variables, you must restart the RSM launcher
service 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.
• If the launcher service does not start, consult the rsmlauncher221-

<timestamp>.log file in the C:\Windows\Temp directory on Windows, or the /tmp
directory on Linux.
2.2.3. Installing and Configuring the RSM Launcher Service for Linux
When installing the RSM launcher service on Linux, you can start the service manually via startup
scripts, or install it as a daemon that will start the service automatically when the machine is booted.
The following RSM configuration topics for Linux are discussed in this section:
2.2.3.1. Adding Common Job Environment Variables for Jobs
2.2.3.2. Installing the RSM Launcher Service for Linux
2.2.3.1. Adding Common Job Environment Variables for Jobs

Before installing and starting the RSM launcher service on Linux, you can edit the rsm_env_pro-
file file under the [RSMInstall]/Config/tools/linux directory. In this file, you can add
any common job environment variables for 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 launcher 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 user’s $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
Note:
• This profile only works on Linux. Windows users should modify their environment via
the environment interface in Windows.
• This profile only works when jobs are submitted to a remote HPC resource in non-SSH
mode. It does not work when running jobs locally (for example, on localhost using
the local queue), or if SSH is being used.
• This profile can only be written in /bin/sh->bash.
2.2.3.2. Installing the RSM Launcher Service for Linux

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

2.2.3.2.1. Starting the RSM Launcher Service Manually for Linux
2.2.3.2.2. Starting the RSM Launcher Service Automatically at Boot Time for Linux
Note:
When installing RSM to a multi-user Linux machine, Ansys strongly recommends that
you set up RSM as a daemon (see Starting the RSM Launcher Service Automatically at
Boot Time for Linux (p. 24)). 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.
2.2.3.2.1. Starting the RSM Launcher Service Manually for Linux

When jobs are to be submitted to a remote resource, the RSM launcher service must be running
on the HPC submit host. You can start the RSM launcher service manually by running the
rsmlauncher script.
This script is generated as part of the RSM installation process and is located in the [RSMIn-
stall]/RSM/Config/tools/linux directory. If for some reason this script was not generated
during installation or is for other reasons not available, you can generate it yourself. For instruc-
tions, see Generating the RSM Service Startup Script for Linux (p. 200) in the RSM Troubleshoot-
ing (p. 199) section.
2.2.3.2.1.1. Manually Running the RSM Launcher Service Script for Linux
You can run the RSM launcher service script to manually start, stop, check the status of, and
restart the RSM launcher service.
Starting the RSM Launcher Service Manually
You can start the RSM launcher service manually by running the service script with the
command line option start, as shown below:
[RSMInstall]/RSM/Config/tools/linux/rsmlauncher start
Note:
Running this script will close any open RSM processes.
Stopping the RSM Launcher Service Manually
You can stop the RSM launcher service manually by running the service script with the
command line option stop, as shown below:
[RSMInstall]/RSM/Config/tools/linux/rsmlauncher stop
Checking the Status of the RSM Launcher Service Manually
You can check the status of the RSM launcher service manually by running the service script
with the command line option status, as shown below:
[RSMInstall]/RSM/Config/tools/linux/rsmlauncher status
Restarting the RSM Launcher Service Manually
You can restart the RSM launcher service manually by running the service script with the
command line option restart, as shown below:
[RSMInstall]/RSM/Config/tools/linux/rsmlauncher restart
2.2.3.2.2. Starting the RSM Launcher Service Automatically at Boot Time for Linux
You can configure the RSM launcher service to start automatically when the machine is booted
by configuring it as a “daemon” service (if the service is not configured to start automatically,
then it must be started manually, as described in Starting the RSM Launcher Service Manually
for Linux (p. 23)). Daemon services are scripts 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.2.3.2.2.1. Installing the RSM Automatic Startup (Daemon) Service for Linux
2.2.3.2.2.2. Working with the RSM Automatic Startup (Daemon) Service for Linux
2.2.3.2.2.1. Installing the RSM Automatic Startup (Daemon) Service for Linux
Security Requirements for Daemon Service Configuration
To install the RSM launcher service as a daemon, you must have system administrative permis-
sions (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 the RSM launcher service as the
root user. Many Linux versions allow only root users to listen to specific ports, so the ports that
are required by RSM 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 launcher service 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 the RSM daemon service script.
• 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 launcher service executable can be started by a non-root user.
Daemon Service Installation Methods
There are two ways to install the RSM launcher service as a daemon: 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 a fresh service script before starting
the service installation, the install_daemon script assumes that the service script is always
available in the WBInstallDir/RSM/Config/tools/linux directory and uses the existing
script for service installation, allowing the system administrator to perform advanced script
customizations before the service is installed.)
Both scripts are located in the RSM/Config/tools/linux directory and have the same
command line option.
tools/linux#> ./rsmconfig -help
Options:
-launcher: Install RSM Launcher service.
tools/linux# ./install_daemon
Usage: ./install_daemon [-launcher]
Options:
-launcher: Install RSM Launcher service.
Installing the RSM Launcher Service as a Daemon
To install the RSM launcher service as a daemon service, 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, adding the command line option -launcher.
For example:
tools/linux#> ./rsmconfig -launcher
tools/linux#> ./install_daemon -launcher
5. Run the command.
Once the daemon service is installed, the RSM launcher service will be started automatically
without rebooting. The next time the machine is rebooted, the installed RSM launcher 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 service is running by typing the appropriate ps command and looking for
Ans.Rsm in the resulting display:
ps aux | grep Ans.Rsm
2.2.3.2.2.2. Working with the RSM Automatic Startup (Daemon) Service for Linux
Once the 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/rsmlauncher221 stop
Checking the Status of the Daemon Service
To check the status of the daemon service:

./etc/init.d/rsmlauncher221 status
Restarting the Daemon Service
To restart the daemon service:
./etc/init.d/rsmlauncher221 restart
Important:
If you change any system environment variables, you must restart the RSM launcher
service 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.2.4. Configuring a Network Installation of RSM

RSM's application, service, and database location settings are stored in the Ans.Rsm.AppSet-
tings.config file in each local installation of RSM. If you have a network installation of the same
RSM package that may be shared by multiple machines, it is important to remember that the
Ans.Rsm.AppSettings.config file is shared by all machines. If you want each machine to have
a different RSM configuration, you will need to point each machine to local RSM configuration direct-
ories.
Perform the following steps on each machine where the same RSM package is used:
1. 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, add a
sub-directory for the RSM version (for example, v221). Copy the Ans.Rsm.AppSettings.config
file into the version sub-directory (for example, C:\rsmconfigs\v221). This file is located in the
RSM\Config folder where Ansys products are installed on a network drive.
Note:
On Linux:
• If you are installing the RSM launcher service as a daemon, and/or installing Ansys
RSM Cluster (ARC) services as daemons, you must set the ANSYS_RSM_APPSET-
TINGS_DIR variable in the sudo environment.
To ensure that the variable is passed correctly when installing these services as
daemons, run the applicable command below:
Launcher service: sudo -E [RSMInstall]/RSM/Config/tools/linux/in-

stall_daemon -launcher
ARC services: sudo -E [RSMInstall]/RSM/ARC/tools/linx64/in-

stall_daemon -arcmaster -arcnode
• If you are using the launcher startup script [RSMInstall]/RSM/Con-

fig/tools/linux/rsmlauncher to manually start the RSM launcher service, you can
set the variable in the script.
2. Set the system environment variable ANSYS_RSM_CONFIGURATION_DIR to point to the new

RSM configuration directory. This should be a local path on the machine. For more information
about the RSM configuration directory, see Specifying a Directory for RSM Configuration Files (p. 147).
For information about setting environment variables in Linux, see Adding Common Job Environment
Variables for Jobs (p. 22).
3. If the RSM launcher service was installed on the HPC submit host, restart the launcher service on
that machine:
• For Windows: On your Administrative Tools or Administrative Services page, open the Services
dialog box. Right-click 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. In a terminal window, run the following command:
2.3. Uninstalling RSM
Uninstalling 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 Uninstallation wizard
and click the Select All button to remove all products.
Uninstalling a Standalone RSM Package

To uninstall a standalone RSM package, run the Ansys Product Uninstallation wizard and select only
the Remote Solve Manager Standalone Services check box.
2.4. Uninstalling the RSM Launcher Service

The RSM launcher service is automatically uninstalled when you uninstall RSM (see Uninstalling
RSM (p. 28)).
If only the launcher service is installed on a machine, follow the steps below to uninstall it.
2.4.1. Uninstalling the RSM Launcher Service for Windows
2.4.2. Manually Uninstalling the RSM Launcher Service for Linux
2.4.3. Uninstalling the RSM Automatic Startup (Daemon) Service for Linux
2.4.1. Uninstalling the RSM Launcher Service for Windows

To uninstall the RSM launcher service on Windows, 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.
Uninstalling the RSM Launcher Service
4. Enter AnsUnconfigRSM.exe -launcher into the command line.
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 stop the service only if it was started by and is owned by the
user performing the uninstall.
6. After the service has been uninstalled, delete the RSM installation directory.
2.4.2. Manually Uninstalling the RSM Launcher Service 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 -launcher
5. Run the script.
Note:
• The uninstaller can only stop the service if it was started by and is owned by the user
performing the uninstall.
• If the service was running as a normal user account, this account may not have enough
permission to stop and kill other users' processes running on the same machine. In this
case, you may need root permission to kill those processes.
2.4.3. Uninstalling the RSM Automatic Startup (Daemon) Service for Linux
As with RSM daemon service installation, only a system administrator can uninstall the RSM daemon
service. Also, the uninstaller can only stop the service if it was started by and is owned by the user
performing the uninstall.
You can uninstall the RSM daemon service in one of two ways:
• Option 1: Run the rsmunconfig script located in the WBInstallDir/RSM/Con-

fig/tools/linux directory. For example:
tools/linux#> ./rsmunconfig
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).
If you later decide that you do not want to keep the user account and user group, you can remove
them manually (p. 30) if needed.
• Option 2: Run the uninstall_daemon script located in the WBInstallDir/RSM/Con-

fig/tools/linux directory. Specify the service by using the command line options shown below:
tools/linux# ./uninstall_daemon
Usage: ./uninstall_daemon [-launcher] [-rmadmin]
Options:
-launcher: Uninstall RSM Launcher service.
-rmadmin : Remove 'rsmadmin' user and 'rsmadmins' group service account.
This script enables you to uninstall the RSM daemon service as well as the rsmadmin user account
and rsmadmins user group. For example:
tools/linux#> ./uninstall_daemon -launcher -rmadmin
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.
If you decide to remove the account and user group, you can do so by manually by adding the
-rmadmin command line option to the uninstall_daemon script located in the WBIn-
stallDir/RSM/Config/tools/linux directory. For example:
tools/linux#> ./uninstall_daemon -rmadmin
Important:
The service account and group cannot be deleted if the RSM launcher service is 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.
Chapter 3: RSM Configuration
RSM serves as a gateway for users wanting to submit jobs to a local or remote compute resource from
applications such as Workbench.
The following are the main types of HPC resources to which RSM can be configured to submit jobs:
• Commercial Cluster. Windows HPC, LSF, PBS Pro, SLURM, UGE (SGE), and custom clusters are suppor-
ted. In this scenario, a third-party application takes care of job scheduling.
• Ansys RSM Cluster (ARC). If you are not using a third-party job scheduler, you can use an Ansys RSM
Cluster (ARC) as your scheduling system. This system is installed along with RSM. An ARC can be
configured on the local machine, or on a remote one.
• Third-Party Cloud. Provides access to Cloud-hosted compute services. Refer to RSM Custom Integra-
tion (p. 155) and contact Ansys customer support for assistance with integrating RSM with a Cloud.
Job submission is established through configurations that are defined using the RSM Configuration ap-
plication. An RSM configuration for a cluster contains information about the cluster submit host, the
system used for job scheduling, desired communication protocols, and the location of job directories.
An RSM configuration for a Cloud portal identifies the portal URL. When defining an RSM configuration
you also define RSM queues that will appear in client applications when users choose to submit jobs
to RSM. Each RSM queue maps to a particular HPC queue. For more information about the components
of an RSM configuration, refer to RSM Roles and Terminology (p. 12), or the Glossary (p. 209).
When configured successfully, RSM will:
• Transfer job files from the client working directory to the HPC staging directory (if necessary)
• Submit jobs to a cluster's job scheduler or a portal 's server application for scheduling and distribution
• Monitor the job while it is running
• Transfer requested output files back to the client working directory
Every RSM installation has one predefined configuration named localhost. This configuration uses
a basic Ansys RSM Cluster (ARC) to submit jobs to the local machine. This enables users to run certain
types of local jobs or Mechanical background jobs right out of the box, without any special setup.
You can create as many RSM configurations as you need. Each RSM configuration that you define is
stored in an .rsmcc file, and RSM queue definitions are stored in a single queues.rsmq file. These
files are stored in a specified RSM configuration directory. Users who want to submit jobs to an HPC
RSM Configuration
resource must have access to these files from their local machines. This can be accomplished by making
the RSM configuration directory a shared directory, or having users copy the files to their local machines.
Important:
• RSM should be configured by a system administrator.
• If you will be defining RSM configurations that multiple people will use for remote job
submission, and want to make them accessible to users through a shared directory, we
recommend that you first change the location of the RSM configuration directory (the
directory in which new configurations are saved). For more information see Setting the
RSM Configuration Directory (p. 32) and Sharing and Accessing RSM Configurations (p. 54).
In this section:
3.1. Setting the RSM Configuration Directory
3.2. Launching the RSM Configuration Application
3.3. Defining RSM Configurations
3.4. Sharing and Accessing RSM Configurations
3.5. Setting Up Job Directories and File Transfers
3.1. Setting the RSM Configuration Directory

Before creating RSM configurations you should determine who will be using them, where they will be
stored, and how they will be accessed.
The Default RSM Configuration Directory

By default, RSM configurations are stored in the following location:
Windows: %APPDATA%\ANSYS\v221\RSM
The path to this directory might be C:\users\%username%\appdata\Roaming\Ansys\V221\RSM,

where %username% is the name of the RSM or system administrator.
Linux: ~/.ansys/v221/RSM
On Linux, ~ is the home directory of the account under which RSM is being run.
To verify the location of your RSM configuration directory, see Querying the Location of the RSM Con-
figuration Directory (p. 147).
Important:
The default directory is appropriate if you will be the only one running jobs on the local
machine, as you will have full control of this directory. However, if you want to share RSM
configurations with other users, we recommend that you do not share the default RSM
configuration directory because it is associated with a specific user account, and is therefore
Defining RSM Configurations
not suitable for sharing. In this case you should change the RSM configuration directory before
creating RSM configurations, as described below.
Creating a Shareable RSM Configuration Directory

If you plan to share RSM configurations with users via a shared directory, you will need to create or
choose a folder other than the default for your RSM configuration files.
1. Create a folder in a location that is not associated with a user account (for example,
C:\some\folder).
2. If you have already created RSM configurations, and are looking to copy them to the shareable
folder, or share the folder in which they currently reside, add the following required sub-folders to
the selected folder: ANSYS\v221\RSM.
Otherwise, RSM will add these sub-folders when you start RSM. This sub-location (for example,
C:\some\folder\ANSYS\v221\RSM) is where RSM configurations must reside.
3. Use the RSM Utilities application to set the JobManagement ConfigurationDirectory setting
to the new folder. See Specifying the Location of the RSM Configuration Directory (p. 147).
Once you have set the RSM configuration directory you can begin creating RSM configurations. See
Launching the RSM Configuration Application (p. 33).
Any new RSM configurations that you create will be saved to the specified directory (in this example,
C:\some\folder\ANSYS\v221\RSM).
If you will be sharing configurations with users, see Sharing and Accessing RSM Configurations (p. 54).
3.2. Launching the RSM Configuration Application

To launch the RSM Configuration application:
• If you are using a Windows system, select Start > Ansys 2022 R1 > RSM Configuration 2022 R1.
You can also launch the application manually by double-clicking Ans.Rsm.ClusterConfig.exe

in the [RSMInstall]\bin directory.
• If you are using a Linux system, run the <RSMInstall>/Config/tools/linux/rsmcluster-

config script.
3.3. Defining RSM Configurations

RSM is able to integrate with established clusters and Cloud portals via configurations that you define
directly in RSM. Information specified in an RSM configuration includes:
• Details about the HPC resource to which jobs will be submitted, such as the domain name of a cluster
submit host, or the URL of a Cloud portal
• Client-to-HPC communication protocols
RSM Configuration
• File transfer method (from client machine to HPC staging directory)
• Queues to made available for simulation jobs
The RSM Configuration application provides a friendly, wizard-like interface that enables you to define
RSM configurations quickly and easily. Defining a configuration involves a 3-part series of steps.
Initially, the list of HPC Resources will include a localhost configuration, which is a basic, single-
node Ansys RSM Cluster (ARC) installed on the local machine. By default it has one RSM queue named
Local, which maps to an HPC queue named local. This queue will run Ansys applications on the
local machine.
Note:
If you will be sharing your RSM configurations with other users, do not edit the existing
localhost configuration to create a new configuration. The localhost configuration
always refers to "the local machine", which could be the cluster submit host or a user's local
machine depending on where job submission is being initiated.
If you want to run Ansys applications on machines other than the local machine, then you will need to
create configurations for the HPC resources that you want to access (Ansys RSM Cluster, third-party
cluster, Cloud portal).
The following topics provide a general overview of creating and managing RSM configurations:
3.3.1. Creating a New RSM Configuration
3.3.2. Specifying RSM Configuration Settings
3.3.3. Deleting an RSM Configuration
For detailed information about setting up specific types of clusters, and creating RSM configurations
for those cluster types, see Ansys RSM Cluster (ARC) Configuration (p. 63) and RSM Integration with a
Cluster or Cloud Portal (p. 121).
3.3.1. Creating a New RSM Configuration

You can create a new RSM configuration in one of two ways:
• To create an RSM configuration from scratch, click , or right-click in the HPC Resources list in
the left pane and select Add HPC Resource.
• To create an RSM configuration by copying an existing RSM configuration (and making changes
to the copy), select the existing configuration in the HPC Resources list and click , or right-
click and select Duplicate HPC Resource. This method is ideal when you already have an RSM
configuration defined and want to create another configuration that is similar, but has one setting
that is different, such as the file transfer method.
Note:
To access or change the directory in which RSM configuration files are generated, refer to
Specifying a Directory for RSM Configuration Files (p. 147).
3.3.2. Specifying RSM Configuration Settings

RSM provides an intelligent and responsive interface for defining configurations.
As you define an RSM configuration for an HPC resource, RSM validates paths and machine names
that you enter, and presents settings that are specific to the HPC type and options that you have
chosen.
The process consists of the following main steps:
1. On the HPC Resource tab, specifying HPC information (p. 36) such as the HPC type, machine
name of the cluster submit host, or URL of the Cloud portal
2. On the File Management tab, specifying file management (p. 41) properties that determine how
job input files get transferred to the HPC staging directory
3. On the Queues tab, importing or adding HPC queues (p. 49), and mapping them to RSM queues
RSM Configuration
When you finish specifying information on a tab, click Apply to validate the information and apply
it to the configuration. Colored icons indicate the status of information on each tab:
If information is missing or invalid, a warning icon is displayed on the tab.
An overview of each step is provided below.

3.3.2.1. Specifying HPC Resource Information
3.3.2.2. Specifying File Management Properties
3.3.2.3. Defining and Testing RSM Queues
For detailed instructions and examples of specific configuration types, refer to the following:
• Ansys RSM Cluster (ARC) Configuration (p. 63)
• RSM Integration with a Cluster or Cloud Portal (p. 121)
3.3.2.1. Specifying HPC Resource Information

The first step in defining an RSM configuration is specifying information about the HPC resource,
and how the client communicates with the resource. This information is specified on the HPC Re-
source tab in the editing pane:
General settings include:
HPC Configuration
Name
The name of the configuration as it appears in the HPC Resources list in the left pane. Do not
use the name of an existing configuration.
HPC type
Choose one of the following from the drop-down:
• ARC (Ansys RSM Cluster)
Choose this option if you are not integrating with a third-party cluster or Cloud portal.
• Windows HPC
• LSF
• PBS Pro
• SLURM
RSM Configuration
• UGE (SGE)
• Custom
To configure RSM for job submission to a third-party Cloud, contact Ansys Customer Support
for assistance.
If UGE (SGE) is selected as the HPC type, settings become available to specify Parallel Environ-
ment (PE) names:
Shared memory parallel processing enables you to distribute solve power over multiple pro-
cessors on the same machine. Distributed parallel processing enables you to distribute solve
power across multiple cores on a single node, or across multiple nodes. For information on
configuring parallel environments, consult the documentation of the simulation product you
are using.
RSM integrates with Windows HPC, LSF, PBS Pro, SLURM, and UGE (SGE) without requiring job
script customization. For custom cluster types, customization will likely be necessary to make
job submission work. Refer to RSM Custom Integration (p. 155).
If integrating with a cluster:
Submit host
Identify the machine that serves as the cluster submit host. This is the machine that handles
job scheduling. In other words, it is the machine on which scheduling software is installed, or,
in the case of an Ansys RSM Cluster (ARC), the machine on which the ARC Master service has
been installed.
• If jobs will be submitted to the cluster submit host from any other machine, enter the submit
host's full domain name (for example, machineName.company.com), even if the machine
on which you are currently working (the local machine) is the submit host.
• If the machine on which you are currently working (the local machine) is the cluster submit
host, and jobs will not be submitted to it from any other machine, you can enter localhost
in this field.
Important:
• Correctly identifying the submit host is a crucial step, as this is the key piece of
information that enables RSM to communicate with the cluster.
• If the current (local) machine is the submit host, do not enter localhost in the
Submit host field if jobs will be submitted to this machine from other machines.
You must use the full domain name in this case.
• If you specify the full domain name for the Submit host and choose to use the
RSM internal socket-based file transfer method, you will see a file transfer error
such as "port number cannot be zero" when you try to use this configuration locally.
If you intend to submit only local jobs using this configuration, change the Submit
host value to localhost and use the OS file transfer method. Otherwise, ensure
that the client machine and submit host are different machines.
Job submission arguments
Scheduler-specific arguments that will be added to the job submission command line of the
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.
Use SSH protocol for inter and intra-node communication (Linux only)
This setting is used for distributed computing with multiple nodes involved. It specifies that
RSM and solvers use SSH for communications between Linux execution nodes, and within the
nodes themselves. If left deselected, this indicates that RSH is used.
This setting will be applied to all Linux HPC nodes, allowing for solvers to run in distributed
parallel mode.
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.
If integrating with a custom cluster, portal, or Cloud:
Submit host or URL
If integrating with a custom cluster, enter the domain name of the cluster submit host (for ex-
ample, machineName.company.com), then select the platform of this machine in the adjacent
drop-down.
If integrating with a custom portal or Cloud, enter the URL of the resource to which jobs will
be submitted, then make any random selection from the platform drop-down. (Since Custom
is a general option that can be used for a variety of HPC resource types, a selection must be
made in the OS drop-down in order to proceed. In the case of a portal or Cloud, the value se-
lected is unimportant and will simply not be used.)
RSM Configuration
Custom HPC type
This is a keyword of your choosing that represents the HPC resource. It is a short word or phrase
that you will append to the file names of your custom integration files. For more information,
see RSM Custom Integration (p. 155).
How does the client communicate with [HPC resource]?

(Available if you have selected ARC, LSF, PBS Pro, SLURM, UGE (SGE), or Custom as the HPC type)
Note:
Communication on the HPC Resource tab refers mainly to the submission of jobs to the
cluster submit host. The transfer of job files is handled independently according to the
settings on the File Management tab. For example, if you select Use SSH or custom
communication to the submit host on the HPC Resource tab, this does not mean that
you have to use SSH for file transfers. You may instead want to use a custom mechanism
or different file transfer method altogether. See Specifying File Management Proper-
ties (p. 41).
Able to directly submit and monitor HPC jobs
Specifies that the RSM client can use the RSM internal communication mechanism to directly
submit jobs to the HPC resource, and monitor HPC jobs. This requires that an IT administrator
open ports and adjust firewall settings on the HPC submit host to allow communication from
the RSM client.
When the submit host is a remote machine, the RSM launcher service launches a user proxy
process on the submit host which performs operations such as job submission, monitoring, and
file transfer on the user's behalf. The RSM launcher service will use one port, while each user
proxy process will use a separate port chosen by RSM. Ports for user proxy processes are chosen
from a port range if one has been specified in the RSM application settings (see Specifying a
Port Range for User Proxy Processes (p. 146)). Otherwise, RSM will randomly select a port that
is free.
Use SSH or custom communication to the submit host
This option is only available when the submit host is a Linux machine and the RSM client is a
Windows machine.
When a job from Windows client is submitted to a remote Linux cluster, this specifies that SSH
will be used to communicate with the submit host instead of RSM's internal communication
mechanism. Use this option if your IT administrator does not want to open ports and adjust
firewall settings to allow communication from the RSM client, in adherence with your organiz-
ation's IT policy. In this scenario, no RSM services need to be running on the remote submit
host.
In the Account name field, specify the account name that the Windows RSM client will use to
access the remote Linux submit host.
Note:
• This account must be set up before this mode can be used. For information on
configuring SSH to allow access from a Windows machine, see Configuring PuTTY
SSH (p. 123).
• This is not an account that is specified in the Credentials section of the RSM
Configuration application. The accounts listed there are RSM client accounts, not
user proxy accounts.
3.3.2.2. Specifying File Management Properties

For jobs to be successfully executed on the HPC resource, client job files need to be staged in a
location that the HPC resource can access. Also, job output files may need to be transferred back
to the client after a job has been executed.
When you submit a job to RSM in a client application, a client working directory is created to which
all necessary job files are written. The location of this directory is configured in the client application.
For more information, refer to Setting Up Client Working Directories to Eliminate the Need for File
Transfers (p. 58).
If the client working directory is created under a shared directory that is visible to all HPC nodes
(in other words, it is already inside the shared HPC staging directory), then it is possible for the job
to be run directly in the working directory. Otherwise, if files need to be transferred from the client
working directory to an HPC staging directory, you will need to specify this in your RSM configuration.
You will also need to specify where jobs will run on the HPC side.
File management properties are specified on the File Management tab in the editing pane.
File management properties will differ depending on the HPC type:

3.3.2.2.1. File Management Properties for a Cluster
3.3.2.2.1. File Management Properties for a Cluster

When integrating with an Ansys RSM Cluster or third-party cluster, you will need to specify client-
to-HPC and HPC-side file management properties:
RSM Configuration
Tip:
Use the Tell me more options to view detailed information about each file transfer
method so that you can select the method that best suits your IT environment, file
storage strategy, and simulation requirements.
Client-to-HPC File Management
Specify how files will get to the HPC staging directory.
Important:
The HPC staging directory must a shared directory that is visible to all HPC nodes.
Operating system file transfer to existing network share (Samba, CIFS, NFS)
Use this option when the HPC staging directory is a shared location that client machines can access.
The RSM client finds the HPC staging directory via a Windows network share or Linux mount
point that has been set up on the client machine, and copies files to it using the built-in op-
erating system copy commands.
In the Staging directory path from client field, specify the path to the shared file system
as the RSM client sees it. A Windows client will see the shared file system as a UNC path (for
example, \\machine\shareName), while a Linux client will see a mounted directory (for
example, /mounts/cluster1/staging).
In the Staging directory path on cluster field, specify a path to the HPC staging directory
which all execution nodes can see. This is a path on the HPC side (for example, \\ma-
chine\staging on a Windows machine, or /staging on a Linux machine). This is the
path to which the client-side network share or mount point is mapped. The minimum path
is the location shared to the network (for example, from the Samba configuration). The rest
of the path can include subdirectories or they will be inferred from the client path.
If jobs will be running directly on the client machine or a single-node cluster (for example,
ARC operating in basic mode), the staging area may just be a preferred local scratch area,
and may not need to be a shared path.
RSM Configuration
When using this option, you must ensure that the HPC staging directory is both visible to
and writable by the client machine. For more information, see Enabling OS Copy to the HPC
Staging Directory (p. 58).
No file transfer needed. Client files will already be in an HPC staging directory.
Use this option if the client files are already located in a shared file system that is visible to
all cluster nodes.
When the client and cluster are running on the same platform, or the submit host is local-
host, further action is not required in most cases.
When the client and cluster platforms differ, it is necessary to map the client-visible path to
a cluster-visible path. The most common scenario is a user working on a Windows client, but
their work files are located in a network shared 'home' directory. For example, they work with
their files using \\homeServer\myhome, but on the Linux cluster side, this can be referred
to as $HOME.
The Network share paths on the HPC resource table is displayed if the submit host is a
Linux machine that is not localhost, and SSH is not being used. Use the table to specify
network paths that map to HPC paths:
Client working directories in Windows UNC format (\\machine\shareName) are mapped to

Linux format using these mapped directories. On the cluster side, each network share path
is the root of the HPC staging directory, meaning that the Linux mapping directory is substi-
tuted for only the \\machine\shareName portion of the client UNC path. For example,
Client directory: \\homeServer\myHome\projects\project1\model1
Mapping directory: $HOME (expands to /nfs/homes/joed). This is the path to which the client-
side network share or mount point is mapped. The minimum path is the location shared to
the network (from the Samba configuration, for example), as shown in the example here. The
rest of the path can include subdirectories or they will be inferred from the client path.
Resulting Linux directory: /nfs/homes/joed/projects/project1/model1
Note:
• The client directory must be visible to all cluster nodes.
• If jobs will be submitted from Linux clients to a Linux submit host, you may not
need to enter a path in the Network share paths on the HPC resource table
if the client working directory can be used as an HPC staging directory.
In all other cases (for example, SSH is being used), you will be prompted to specify the Staging
directory path on cluster (or nothing at all):
RSM Configuration
For information on creating client working directories under a shared HPC directory, see
Setting Up Client Working Directories to Eliminate the Need for File Transfers (p. 58).
RSM internal file transfer mechanism
Use this option when the HPC staging directory is in a remote location that is not visible to client
machines.
RSM uses TCP sockets to stream files from the client machine to the submit host machine. In
this case you must specify the path to the directory where job files will be staged (as the
cluster sees it):
When transferring files to a single-node cluster, it may not be necessary for the staging dir-
ectory to be a shared path (for example, UNC path on Windows).
External mechanism for file transfer (SCP, Custom)
Use this option when the HPC staging directory is in a remote location that is not visible to client
machines, and you need to use an external mechanism such as SCP for file transfers
For a Linux cluster, you can use either SCP via SSH or a Custom mechanism for file transfers
to the HPC staging directory. For a Windows cluster, only the Custom option is available.
RSM has built-in support for SCP transfer. In using the SCP protocol for communication and
file transfer, it is not necessary to have any RSM components running on the remote submit
host.
If using a Custom mechanism, the RSM launcher service may or may not need to be running
on the submit host. This will depend on whether or not the client needs to communicate
with RSM's launcher service on the remote side to handle the file transfer.
Whether you are using SCP via SSH or a Custom mechanism, you will need to specify the
path to the HPC staging directory as the cluster sees it (for example, /staging on a Linux
machine, or \\server\staging on a Windows machine):
RSM Configuration
If using a Custom mechanism for file transfers, you will also need to specify the Custom
transfer type. This is a keyword of your choosing that represents the transfer type. It is a
short word or phrase that you will append to the file names of your custom integration files:
If using SCP via SSH, the Custom transfer type is predetermined and cannot be edited.
Finally, specify the Account name that the RSM client will use to access the remote submit
host. For a Linux cluster, if you selected Use SSH or custom communication to the submit
host on the HPC Resource tab, the account name that you specified on that tab will auto-
matically populate the Account field on the File Management tab, and cannot be edited. If
you selected Able to directly submit and monitor HPC jobs on the HPC Resource tab, the
Account field on the File Management tab can be edited. Note, however, that if you are
using a Custom mechanism, the Account name is optional.
If using SCP via SSH, you can customize the SSH-specific cluster integration files to suit your
needs. If using a Custom mechanism, you will need to create custom versions of these files.
For details refer to Configuring SSH/Custom File Transfers (p. 170).
HPC Side File Management
Available if the HPC type is set to a cluster type, or Custom.
Specify the working directory on the cluster side where job (or solver) commands will start running.
HPC staging directory
This option is recommended if one or both of the following is true:
• There is a fast network connection between the cluster nodes and the HPC staging 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).
Scratch directory local to the execution node(s)
This option is recommended to optimize performance when one or both of the following is
true:
• There is a slower network connection between the cluster nodes and the HPC staging dir-
ectory.
• 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).
All input files will be copied from the HPC staging directory into that local scratch directory.
Then, when the job finishes running, the requested output files generated by the job will be
copied back to the HPC staging directory.
In the Local HPC scratch directory field, enter the local path of a scratch directory on the
cluster node (for example, C:\Shares\Local_Share\ScratchDir on Windows). You
can enter the path of the scratch directory manually, or use an environment variable in the
format %VAR%.
If the cluster is running on Windows, you must create a network share path for the local
scratch directory on each node. In the Share path for local scratch field, enter the network
share path of the local scratch directory. This path starts with a non-editable [Execution-
Node] variable. When a job is submitted, the [ExecutionNode] variable will be replaced
with the actual machine name of each execution node assigned to the job.
By default, job files will be deleted from the HPC staging directory after the job has run.
Choosing Keep job files in staging directory when job is complete may be useful for
troubleshooting failed jobs. However, retained job files will consume disk space, and require
manual removal.
3.3.2.3. Defining and Testing RSM Queues

When you choose to submit a job to RSM, you must choose an RSM queue for the job. An RSM
queue maps to a queue on the HPC side, and provides a way to link to the RSM configuration.
RSM queues are defined on the Queues tab in the editing pane:
RSM Configuration
Defining an RSM Queue

RSM queues are the queues that users will see in client applications when they choose to submit
jobs to RSM. RSM queue names can match the names of queues or queueing mechanisms defined
on the HPC resource. The important thing to remember is that each RSM queue name must be
unique.
RSM provides two ways of defining RSM queues: you can either import a list of HPC queues and
define an RSM queue for each HPC queue, or you can manually add an RSM queue and assign an
HPC queue to it.
• To import a list of HPC queues, or refresh the list if you have imported HPC queues previously,
click . Then, for each HPC queue, double-click in the RSM Queue field and specify a unique
RSM queue name.
• To add an RSM queue to the list, click , then specify a unique name for the queue in the
RSM Queue field.
Double-click in the HPC Queue field and enter the name of an existing HPC queue. RSM will
check to see if the HPC queue is valid.
Enabling/Disabling an RSM Queue

When you create an RSM queue it is enabled by default. This means that it will be available for se-
lection in client applications.
To control whether or not an RSM queue is available for use, select or clear the queue's Enabled
check box.
Testing an RSM Queue

When you test an RSM queue, RSM sends a test job to the HPC resource via the associated HPC
queue.
To test an RSM queue, click in the queue's Test column, or right-click the queue in the tree
in the left pane and select Submit Test.
Note:
• You may need to click Apply on the Queues tab before being able to submit test
jobs.
• Only enabled queues can be tested.
The status of the test is displayed in the Status column:
Job is being submitted
Job is queued
Job is in progress
Job completed successfully
Job completed successfully and
released
Job aborted
Job aborted and released
Job failed
Job failed and released
When a job is running, the button is replaced by an button, enabling you to abort
the test job if desired.
Performing an Advanced Queue Test

In an advanced test of an RSM queue you can select a client working directory in which to run the
test. This is a good way of testing whether or not files are being transferred to the HPC staging
directory (if, for example, the client working directory is a network share of the HPC staging directory).
RSM Configuration
To perform an advanced RSM queue test:
1. Right-click the queue in the tree in the left pane, then select Advanced Test.
2. In the Advanced Test dialog box, select or specify the client directory that you want to use
for the test job. You can leave it set to the default %TEMP% environment variable, or enter a
path or environment variable manually. Manually entered items will be added as drop-down
options.
3. If you want to clean up the client directory after the test job is done, enable the Cleanup Client
Directory check box.
4. Click Submit.
The status of the test is displayed in the Status column of the queue table, as described in Testing
an RSM Queue (p. 51).
Viewing a Test Job Report

If you have submitted a test job to an RSM queue, you can view a detailed test report by clicking
in the queue's Report column.
Saving a Test Job Report

You can save a job report to an HTML file that can be shared with others.
To save the job report:
1. Click in the job report window.
2. Accept or specify the save location, file name, and content to include.
RSM Configuration
3. Click Save.
Deleting an RSM Queue

You can delete an RSM queue that appears on the Queues tab in one of three ways:
• Select the queue(s) in the queue list, then click on the queues toolbar.
• Right-click the queue in the queue list, then select Delete Selected RSM Queue(s).
• Right-click the queue in the tree in the left pane, then right-click and select Delete Queue. Note
that only enabled queues appear in the tree.
3.3.3. Deleting an RSM Configuration

You can delete any configuration defined in RSM except the localhost configuration. When you
delete an RSM configuration, any RSM queues defined in the configuration will no longer be available
in client applications when submitting jobs to RSM. The configuration will also be removed from the
RSM configuration database.
To delete an RSM configuration, select the configuration in the left pane, then click on the
toolbar, or right-click and select Delete HPC Resource.
3.4. Sharing and Accessing RSM Configurations

RSM configurations and queue definitions (.rsmcc and .rsmq files) are the key to successful HPC job
submission, as they contain vital information about the HPC resource and how files will be handled.
In order for users to be able to submit jobs to an HPC resource, they must have access to the RSM
configurations that you have defined. To accomplish this, there are two approaches that you can take:
Method 1: Share the RSM configuration directory

If you are an administrator who has defined RSM configurations for multiple people to use, you can
make the RSM configurations accessible to users by making the RSM configuration directory a shared
directory. This method ensures that all users have the most accurate and up-to-date RSM configurations,
as files are centrally stored and managed.
Sharing and Accessing RSM Configurations
• If you changed the RSM configuration directory to a share-friendly folder before creating configurations
(as described in Creating a Shareable RSM Configuration Directory (p. 33)), you can go ahead and
share that folder. Make sure that the folder has read-only permission to prevent others from modifying
your RSM configurations.
• If you did not change the RSM configuration directory before creating configurations, your configur-
ations are located in the default RSM configuration directory (p. 32), which is a user-specific directory
that is not suitable for sharing.
In this case, follow these steps:
Windows
C:\some\folder).
2. Add the following required sub-folders to the folder: ANSYS\v221\RSM.
In this example, the resulting path will be C:\some\folder\ANSYS\v221\RSM. This location

will serve as the new RSM configuration directory.
3. If the RSM service is currently running, stop it. As an administrator, run net stop
RSMLauncherService221.
5. Issue the following command, replacing the path with the desired value:
rsm.exe appsettings set JobManagement ConfigurationDirectory

C:\some\folder\ANSYS\v221\RSM.
You can specify a local path if the directory is on the local machine, or a UNC path if the directory
is a network share.
6. Go to the default RSM configuration directory:
%APPDATA%\ANSYS\v221\RSM
The path to this directory might be C:\users\%username%\appdata\Roaming\An-

sys\V221\RSM, where %username% is the name of the RSM or system administrator.
7. Copy the .rsmcc and .rsmq files from the default RSM configuration directory to the new dir-
ectory (for example, C:\some\folder\ANSYS\v221\RSM).
8. Set read-only permission on the folder to prevent others from modifying the configurations.
9. Share the folder.
10. Restart the RSM service.
Linux
/some/folder).
RSM Configuration
2. Add the following required sub-folders to the folder: ANSYS/v221/RSM.
In this example, the resulting path will be /some/folder/ANSYS/v221/RSM. This location

will serve as the new RSM configuration directory.
3. If the RSM service is currently running, stop it using rsmlauncher stop.
If the RSM service is running as a daemon, stop it using ./etc/init.d/rsmlauncher221

stop.
4. Run the rsmutils shell script located in the [RSMInstall]\Config\tools\linux direct-

ory. Issue the following command, replacing the path with the desired value:
rsmutils appsettings set JobManagement ConfigurationDirectory

/some/folder/ANSYS/v221/RSM
You can specify a local path or a mounted file system depending on where the directory resides.
5. Go to the default RSM configuration directory:
~/.ansys/v221/RSM
6. Copy the .rsmcc and .rsmq files to the new directory (for example, /some/folder/AN-
SYS/v221/RSM).
7. Set read-only permission on the folder to prevent others from modifying the configurations.
8. Share the folder.
Once the RSM configuration directory has been shared, Workbench client users should set the RSM
configuration directory on their local machines to the path of the shared RSM configuration directory.
For example, the share path might be something like \\machineName\Share\RSM for Windows
users, or /clusternodemount/share/RSM for Linux users. For details, see Specifying the Location
of the RSM Configuration Directory (p. 147).
Note:
One potential drawback of this method is that users may not be able to access the shared
RSM configurations if the host goes offline or cannot be accessed for some reason (for ex-
ample, if a user is working off-site and does not have access to the network). In this case
RSM will automatically switch the RSM configuration directory back to the default RSM con-
figuration directory (p. 32) on their local machines. This means that users will, at a minimum,
be able to submit jobs to the Ansys RSM Cluster (ARC) already installed on their local machines
using the localhost configuration that is generated in the default RSM configuration dir-
ectory when RSM is installed.
Setting Up Job Directories and File Transfers
Method 2: Have users copy RSM configuration files to their local machines
If you are a user looking to access RSM configurations that have been defined by your RSM or system
administrator, you can do so by setting your RSM configuration directory to the shared RSM configuration
directory that was set by the administrator (see Method 1 above). Alternatively you can copy the RSM
configuration database to the appropriate directory on your machine.
As a user, you will need to:
1. Obtain the RSM configuration files (.rsmcc and .rsmq files) from the RSM or system administrator.
If the administrator has put the files in a shared directory that you can access, you can retrieve them
directly from there.
2. On your local machine, copy the files into your RSM configuration directory. For information about
the location of this directory, see Setting the RSM Configuration Directory (p. 32).
Note:
If any of the shared files that you are copying have the same name as files in your local RSM
configuration directory, you will need to rename your local files if you do not want them to
be overwritten. For example, you may want to rename your localhost.rsmcc file to
mylocalhost.rsmcc to distinguish it from the remote localhost.rsmcc file, as its
settings may be different.
Alternatively, to avoid this issue altogether:
1. Create a new folder on your local machine (for example, C:\SharedRSMConfig).
In this example, the resulting RSM configuration directory will be C:\SharedRSMCon-

fig\ANSYS\v221\RSM.
3. Use the RSM Utilities application to set the JobManagement ConfigurationDir-

ectory setting to the new folder. See Specifying the Location of the RSM Configuration
Directory (p. 147).
4. Copy the RSM configurations from the network share to the new directory (for example,
C:\SharedRSMConfig\ANSYS\v221\RSM).
3.5. Setting Up Job Directories and File Transfers

When setting up an RSM job in a client application, a working directory is created to capture the necessary
job input files before the job is submitted. Settings in client applications enable you to specify where
job working directories are created.
The files in the working directory must be made accessible to the HPC resource. You can accomplish
this in one of two ways:
RSM Configuration
• In the client application, specify that working directories should be created under a shared HPC dir-
ectory.
• Make it possible for files to be transferred from the working directory to a shared HPC directory.
You must also specify the file transfer method that you want to use on the File Management tab of
an RSM configuration (see Specifying File Management Properties (p. 41)).
For detailed information, refer to the following topics:

3.5.1. Setting Up Client Working Directories to Eliminate the Need for File Transfers
3.5.2. Enabling OS Copy to the HPC Staging Directory
3.5.3. Configuring a Computer with Multiple Network Interface Cards (NICs)
3.5.4. Using SSH for File Transfers
3.5.5. Custom Client Integration
3.5.1. Setting Up Client Working Directories to Eliminate the Need for File
Transfers
If you set the working directory location to be under a shared HPC directory, file transfers will not be
necessary, because the files will already be in the HPC staging directory. In this case you will be able
to select the No file transfer needed option on the File Management tab of an RSM configuration.
For details about this option, refer to Specifying File Management Properties (p. 41).
The Workbench project directory or Mechanical client scratch directory determines the location of
the client working directory.
3.5.2. Enabling OS Copy to the HPC Staging Directory

If files will be transferred from the client working directory to a remote HPC staging directory via
operating system commands (in other words, you have selected Operating system file transfer to
existing network share (Samba, CIFS, NFS) on the File Management tab), you must ensure that
the HPC staging directory is both visible to and writable by the RSM client machine. RSM finds the
HPC staging directory via a Windows network share or Linux mount point.
The steps for configuring the HPC staging directory for the OS Copy operation are different between
Linux and Windows.
3.5.2.1. Windows-to-Windows File Transfer

System Administrator permissions are required to configure a directory for Windows-to-Windows
OS Copy file transfers.
For Windows-to-Windows file transfers, RSM uses the HPC staging network share name specified
on the File Management (p. 41) tab of the RSM configuration to locate and identify the HPC staging
directory. You must configure the directory by performing the following setup tasks:
• Share the HPC staging directory out to the RSM client machine.
• Provide full read-write permissions for the shared directory.
Perform these steps for the HPC staging directory:
1. In Windows Explorer, right-click the HPC staging 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. For example, if you wanted to create a network share named staging for the HPC
staging directory D:\ClusterStaging on a machine named winclusterhost, you would
enter staging for the share name. This would allow other machines to access the directory
via a UNC path: \\winclusterhost\staging.
5. Ensure that full read-write permissions are defined for the directory.
3.5.2.2. Linux-to-Linux File Transfer

Root permissions are required to configure the HPC staging directory for Linux-to-Linux OS Copy
file transfers.
For Linux-to-Linux file transfers, RSM uses mount points to locate and identify the HPC staging
directory. You must configure the directory by performing the following setup tasks:
1. Ensure that the HPC staging directory belongs to a file system that is mounted, so that it
is visible to the RSM client machine. Use the full path for the directory.
2. Provide full read-write privileges for the HPC staging directory.
3.5.2.3. Windows-to-Linux File Transfer

Root permissions on the Linux machine are required to configure the HPC staging directory for
Windows-to-Linux OS Copy file transfers.
For Windows-to-Linux transfers (using Samba or a similar Linux utility), entries in the Samba config-
uration file map the actual physical location of the Linux HPC staging directory to a predefined
Windows share name that RSM uses to locate and identify the HPC staging directory. The following
example shows how to configure a Samba share on Linux for the HPC staging directory. 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 the Linux HPC staging dir-
ectory. The example below shows Samba’s default values for the Linux target directories.
[staging]
path = /staging
browseable = yes
writable = yes
create mode = 0664
directory mode = 0775
guest ok = no
The path should point to the actual physical location of the existing target directory.
RSM Configuration
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 \\linuxmachine-
name\staging, using your specific machine name in place of linuxmachinename.
3.5.3. Configuring a Computer with Multiple Network Interface Cards (NICs)

When multiple NIC cards are used on a remote HPC submit host, additional configuration may be
necessary to establish communications between the RSM client and the submit host.
1. Stop the RSM launcher service if it is running.
2. Use the RSM Utilities application to specify the correct IP address of the HPC submit host. 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). Examples are 1.2.3.4 and ma-
chine.mycompany.com.
Windows: Run the following command in the [RSMInstall]\bin directory:
rsm.exe appsettings set Global RemotingMachineNameAttribute <IP ad-

dress>
Linux: Run the following command in the [RSMInstall]/Config/tools/linux directory:
rsmutils appsettings set Global RemotingMachineNameAttribute <IP ad-

dress>
3. If using the RSM internal file transfer mechanism (p. 28), which uses TCP sockets to stream files
from the client machine to the submit host, use the RSM Utilities application to specify the correct
IP address in the SocketTransfererListenerIpAddress setting:
rsm.exe appsettings set UserProxy SocketTransfererListenerIpAddress

<IP address>
rsmutils appsettings set UserProxy SocketTransfererListenerIpAddress

<IP address>
4. Restart the RSM launcher service:
• 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. In a terminal window, run the following command:
3.5.4. Using SSH for File Transfers

SSH file transfer can be defined to transfer files between a Windows RSM client and a Linux cluster,
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 detailed information about using SSH, see Configuring RSM to Use SSH for Job Submission and/or
File Transfers to a Remote Linux Cluster (p. 121).
3.5.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 inform-
ation on custom integration techniques, see RSM Custom Integration (p. 155).
Chapter 4: Ansys RSM Cluster (ARC) Configuration
If you are not using a third-party job scheduler such as Microsoft Windows HPC or LSF, you can use the
Ansys RSM Cluster (ARC) scheduler to submit jobs to a single machine, or a group of machines. The
ARC scheduling system does not offer all of the advanced features that are available in third-party
schedulers, but does include the essential features required to schedule and run jobs that are submitted
to RSM from Ansys products. ARC enables users to get started with RSM right away, and take advantage
of HPC resources.
Every RSM installation has one predefined localhost configuration that uses the ARC scheduling
system to submit jobs to the local machine. This enables users to run certain types of local jobs or
Mechanical background jobs right out of the box, without any special setup. For details see The Default
'Localhost' Configuration (p. 68).
The ARC Configuration application provides a quick and easy way to set up a single-node or multi-node
cluster. It enables you to connect and configure cluster nodes, and start ARC services on those nodes.
Various ARC configuration commands are available to help you customize your cluster setup. For example,
you can configure individual execution nodes to have different resource allocation settings.
The command scripts used to execute ARC cluster commands are located in the
%AWP_ROOT221%\RSM\ARC\tools\winx64 directory on Windows, and the
$AWP_ROOT221/RSM/ARC/tools/linx64 on Linux.
Once you have set up the cluster, you can use the RSM Configuration application to create a cluster
configuration that enables users to submit jobs to the cluster.
Setup instructions and details about ARC command usage and options are provided in the following
sections:
4.1. Important Considerations and Requirements for the Ansys RSM Cluster (ARC)
4.2. Overview of an Ansys RSM Cluster (ARC) Configuration
4.3.The Default 'Localhost' Configuration
4.4. Creating and Deploying an Ansys RSM Cluster (ARC)
4.5. Defining an RSM Configuration for an Ansys RSM Cluster (ARC)
4.6. Ansys RSM Cluster (ARC) Command Usage and Options
4.7. Setting the ARC_ROOT Environment Variable for Ansys RSM Cluster (ARC) Job Submission
4.8. Dealing with a Firewall in a Multi-Node Ansys RSM Cluster (ARC)
4.9. Example: Setting Up a Multi-Node Ansys RSM Cluster (ARC)
Ansys RSM Cluster (ARC) Configuration
4.1. Important Considerations and Requirements for the Ansys RSM

Cluster (ARC)
Before configuring an Ansys RSM Cluster (ARC), review the important considerations below, and ensure
that any prerequisites are met.
• Ansys RSM Cluster (ARC) has basic job scheduling capabilities and provides a simple HPC workflow.
However, it is not intended to be a replacement for a commercial scheduler. If you have integrated
RSM with a third-party scheduler in the past, or require advanced functionality that the ARC system
does not offer, you should continue to work with your IT department to determine which commercial
solution will best fit your simulation and business needs. For information about configuring RSM for
use with an existing third-party scheduler, see RSM Integration with a Cluster or Cloud Portal (p. 121).
• The ARC system is not available as a standalone product. It is installed and intended to be used with
RSM, meaning that jobs can only be submitted to an ARC via RSM from an Ansys client application.
• RSM must be installed on the machine that you are designating as the submit host, as well all machines
that will accept jobs. By default, RSM is automatically installed with Ansys Workbench products when
you use the standard Ansys product installation.
• If creating a multi-node ARC, all execution nodes must be running on the same platform (Windows
or Linux).
• You cannot run two versions of an ARC (for example, 2021 R2 and 2022 R1) at the same time. To
ensure that the correct ARC version is used when jobs are submitted to an ARC via RSM, you should
set the ARC_ROOT environment variable. Refer to Setting the ARC_ROOT Environment Variable for
Ansys RSM Cluster (ARC) Job Submission (p. 103).
4.2. Overview of an Ansys RSM Cluster (ARC) Configuration

An Ansys RSM Cluster (ARC) can be a single- or multi-node cluster.
In a single-node ARC, the head node (submit host) and execution node are the same machine. This can
be a user's local machine (see The Default 'Localhost' Configuration (p. 68)), or a single remote machine
to which multiple users submit jobs.
A multi-node ARC consists of two or more machines. It is based on the head/compute model of com-
munication in which one machine or process has control over the other machines. In this scenario one
machine serves as the head node (submit host), and the other machines serve as execution nodes. The
submit host may also serve as an execution node if desired.
In order for an ARC to be operational (that is, able to accept, schedule and execute jobs), ARC services
must be running on the cluster nodes.
Important:
When a user submits a job to a single-node ARC, RSM will check to see if ARC services are
running on that node. If the services are not running, RSM will automatically start them as
the user who submitted the job. This is fine for a 'localhost' configuration where a user will
be submitting jobs locally to his or her own machine. However, if multiple users will be
Overview of an Ansys RSM Cluster (ARC) Configuration
submitting jobs to an ARC, whether it be a single- or multi-node cluster, we recommend that

you install and start ARC services as daemons before anyone submits a job to it.
The steps that you need to take to set up an ARC depend on whether the cluster will be a single- or
multi-node cluster, and who will be submitting jobs to it. The table below provides an overview of ARC
setup types and the tasks you need to perform for each setup.
You can perform most of these tasks using the automated ARC Configuration application or arcdeploy
command. See Creating and Deploying an Ansys RSM Cluster (ARC) (p. 70).
Table 4.1: Overview of ARC Setup Options
ARC Type ARC Service Installation Additional Tasks

Single-Node Cluster: RSM will automatically start • No additional setup
Single-User Access (Local Job ARC services on the single required
Submission) node (if they have not
already been started) • Every RSM installation
• User can submit jobs includes a default
locally to his or her own 'localhost' configuration
machine using Local already
queue
• Users can submit jobs to
• Submit host = local- their local machines right
host away
• Optional: Set the

maximum number of
cores that can be used for
job execution on the local
machine (see Setting the
Maximum Number of
Cores to be Used on an
Execution Node (p. 95))
Single-Node Cluster: Multi-User Before any user submits a • Create an RSM

Access (Remote Job job, you must install the ARC configuration file for the
Submission) Master service and ARC cluster and share it with
Node service on the single users (see Defining an
• Multiple users can submit node. RSM Configuration for an
jobs to a specific machine Ansys RSM Cluster
on the network You can start ARC services (ARC) (p. 86))
when using the automated
• Submit host = machine- ARC Configuration • Optional: Set the
Name.domain.com application or the arcdeploy maximum number of
command. See Creating and cores that can be used for
• Jobs execute on the Deploying an Ansys RSM job execution on the
submit host Cluster (ARC) (p. 70). cluster node (see Setting
the Maximum Number of
Or, to start ARC services Cores to be Used on an
manually, refer to one of the Execution Node (p. 95))
following:

Installing ARC Cluster
Services on Windows
(installservice) (p. 88)
Installing ARC Cluster

Services on Linux (p. 89)
Multi-Node Cluster: Multi-User Before any user submits a Required
Access (Remote Job job, you must install the ARC
Submission) Master service on the submit • Associate the execution
host (making it the master nodes with the master
• Multiple users can submit node), and the ARC Node node. If using the ARC
jobs to a specific machine service on each execution Configuration application
on the network node. or arcdeploy command
for configuration, see
• Submit host = machine- Creating and Deploying
Name.domain.com Note: an Ansys RSM Cluster
(ARC) (p. 70). Or, to
• Two built-in cluster If the head node
perform this task
queues: default will also be used
manually, see Associating
(includes all machines on to run jobs, then
ARC Execution Nodes with
which the Node service is you must install
the Master Node (p. 95).
installed) and local both the Master
(contains only the submit service and Node • If you have set up a
host) service on that firewall, traffic from the
node. execution nodes to the
• Submit host associated master node may be
with one or more You can start ARC services blocked. To resolve this
execution nodes when using the automated issue, refer to Dealing with
ARC Configuration a Firewall in a Multi-Node
• Jobs execute on the application or the arcdeploy Ansys RSM Cluster
execution node(s) but may command. See Creating and (ARC) (p. 103).
also execute on the Deploying an Ansys RSM
submit host Cluster (ARC) (p. 70). • Create an RSM
configuration file for the
Or, to start ARC services cluster and share it with
manually, refer to one of the users. See Defining an
following: RSM Configuration for an
Ansys RSM Cluster
Installing ARC Cluster (ARC) (p. 86).
Services on Windows
(installservice) (p. 88) Optional
Installing ARC Cluster • Cache the password

Services on Linux (p. 89) for accessing the
cluster. If using the
ARC Configuration
application or
arcdeploy command
Creating and
Overview of an Ansys RSM Cluster (ARC) Configuration

Deploying an Ansys
RSM Cluster
(ARC) (p. 70). Or, to
perform this task
manually, see
Caching Credentials
for Cluster Job
Submission
(arccredentials) (p. 100)
• Create additional
cluster queues (that
contain only certain
machines, for
example). Once
defined, you will be
able to import cluster
queues into an RSM
configuration so that
you can map them to
RSM queues (p. 49).
If using the ARC
Configuration
application or
arcdeploy command
Creating and
Deploying an Ansys
RSM Cluster
(ARC) (p. 70). Or, to
perform this task
manually, see
Configuring ARC
Queues (arcconfig
queue) (p. 97).
• Display the status

and details of defined
queues. See
Displaying the Status
and Details of ARC
Queues
(arcqueues) (p. 99).
• Configure resource
allocation on
individual nodes. See
Configuring ARC
Cluster Nodes

(arcconfig node
modify) (p. 94).
Important:
• If the Master service or Node service does not start, consult the ArcMaster221-
<date>.log or ArcNode221-<date>.log file to find the possible cause. For more
information, see Accessing RSM Log Files (p. 199).
• If users will be running a large number of jobs (such as Workbench design point updates)
on a single-node Ansys RSM Cluster (ARC), the single node on which jobs are executed
could become overloaded, resulting in system issues such as memory usage errors. In this
case, it would be advisable to use a multi-node ARC or commercial third-party cluster in-
stead.
• If you have a firewall set up, this may prevent communication between the master node
and execution nodes. To resolve this issue, see Dealing with a Firewall in a Multi-Node
Ansys RSM Cluster (ARC) (p. 103).
4.3. The Default 'Localhost' Configuration

Conveniently, every RSM installation has a single-node ARC already configured. This is the localhost
configuration in the HPC Resources list:
The Default 'Localhost' Configuration
The localhost configuration automatically makes each user's local machine a single-node cluster. It
provides immediate job submission capability for all users, enabling them to submit certain types of
jobs to their local machines using the Local queue that is defined in this configuration.
In the default localhost configuration, the Name and Submit host are both set to localhost, and
cannot be changed. The HPC type is set to ARC, indicating that the Ansys RSM Cluster (ARC) scheduling
system will be used to submit jobs to the cluster. Since jobs are only being submitted to the local machine
and not a remote one, only the Able to directly submit and monitor HPC jobs option is available.
When the Submit host is the local machine ('localhost'), only two file transfer options are available on
the File Management tab, because the HPC staging directory is on the local machine:
For an overview of the settings in an RSM configuration, refer to Specifying RSM Configuration Set-
tings (p. 35).
4.4. Creating and Deploying an Ansys RSM Cluster (ARC)

The ARC Configuration application provides a simple, automated way to set up and deploy an Ansys
RSM Cluster (ARC). The application connects to machines on your network, and establishes communic-
ation between them.
The application guides you easily through the following configuration tasks:
• Identifying the master node
• Identifying the execution nodes
• Starting ARC services on cluster nodes
• Associating the execution nodes with the master node
• Adding queues to the cluster
• Assigning execution nodes to each queue
Creating and Deploying an Ansys RSM Cluster (ARC)
Tasks such as starting ARC services on cluster nodes are achieved with the click of a button, with no
additional input required.
If the cluster includes multiple nodes, you can configure all execution nodes from the master node, or
run the ARC Configuration application on the execution nodes themselves. However, the master node
can only be configured directly on that machine.
Before you proceed with configuration, refer to Prerequisites for ARC Configuration (p. 71) to ensure
that all nodes are accessible and suitable for ARC configuration.
In this section:
4.4.1. Prerequisites for ARC Configuration
4.4.2. Configuring an Ansys RSM Cluster (ARC) Using the ARC Configuration Application
4.4.3. Configuring an Ansys RSM Cluster (ARC) Using the Command Line (arcdeploy)
4.4.1. Prerequisites for ARC Configuration

Before setting up the cluster, ensure that the following requirements are met:
• You must have full Administrator and/or sudo rights on all of the nodes in the cluster.
• All of the nodes in the cluster must have the same operating system.
• Ansys software must be installed on the Master node and all Execution nodes. The Ansys installation
directory should be the same on all machines (for example, /apps/ansys_inc or C:\Program
Files\ANSYS Inc).
For additional considerations, see Important Considerations and Requirements for the Ansys RSM
Cluster (ARC) (p. 64).
4.4.2. Configuring an Ansys RSM Cluster (ARC) Using the ARC Configuration
Application
To begin configuration, run the ARC Configuration application on the machine that will serve as the
cluster head node, or master node. You can configure other nodes from the master node while using
the application.
The instructions that follow focus on the deployment of a Windows cluster, but could be applied to
the deployment of a Linux cluster as well.
In this section:
• Launching the ARC Configuration Application (p. 72)
• Defining Cluster Usage and Node Usage (p. 72)
• Defining Execution Nodes (p. 74)
• Defining Queues (p. 76)
• Defining Administrative Access (p. 80)
• Caching Credentials for Cluster Job Submission (p. 81)
• Refreshing the View During ARC Configuration (p. 81)
Launching the ARC Configuration Application

1. Sign in to the master node as an Administrator.
2. On the master node, launch the ARC Configuration application as follows:
• On Windows, select Start > Ansys 2022 R1 > ARC Configuration 2022 R1.
You can also launch the application manually by double-clicking the following executable:
[RSMInstall]\ARC\bin\arcConfigConsole.exe
• On Linux, run the following script:
<RSMInstall>/ARC/Config/tools/linux/arcconfigui
When launched, the ARC Configuration application will display the hostname of the current
machine:
Defining Cluster Usage and Node Usage

1. In the Cluster Usage section, specify how the cluster will be used, and by whom:
I am the only user running jobs Jobs will be submitted, scheduled and run on the same
on this cluster and they are local machine (the local machine), and only you will be
jobs. submitting jobs to this machine (using the Local queue).
The existing localhost configuration is an example of a
single-node, single-user cluster.
I am configuring this cluster for Jobs will be submitted by one or more users to a specific
either a multi-user or multi-node machine on the network. The machine specified as the
environment. master node (cluster submit host) may also serve as an
execution node, or have additional execution nodes
associated with it. Jobs may run on the master node or on
any of the execution nodes depending on the queue
chosen.
2. In the Master Node Service section, select Yes to specify that the current machine is the master
node, then click Start to install the Master Node Service on this node. When you do so, any exe-
cution nodes and/or queues previously associated with this node are displayed in the tree view.
3. In the Execution Node Service section, specify whether or not the current machine will be used
to run jobs. If you selected Yes, click Start to install the Execution Node Service on this node.
When you do so, the node is added to the Execution Nodes list.
Note that you can also use the ARC Configuration application to stop running ARC services when
desired:
Defining Execution Nodes
Note:
You cannot define execution nodes unless the Master Node Service has been started on
the master node. This is done on the Cluster Management page.
1. If you specified that the Master node is going to run jobs, go to step 4 to specify execution
properties for this node. Otherwise, to add nodes to the cluster, right-click Execution Nodes in
the tree and select Add an execution node.
2. In the ARC Configuration Manager dialog box, enter the hostname of the machine that you
want to add as an execution node, then click Add.
3. Under Execution Nodes, select the node that you want to define:
4. Click Start to install the Execution Node Service on the selected node (if not already started).
5. Define the node's properties:
Associated Master For successful job submission in a multi-node cluster,

you must configure each execution node to report to
the master node. This is achieved by specifying the
hostname or IP address of the Master node (cluster
submit host) in this field.
The master node is where the ARC Master service is

installed. This service dispatches jobs to the execution
nodes.
Max Cores Use the Max Cores setting to reduce the number of cores
that can be used by ARC jobs on this node. By default, all
available cores can be used.
6. Click Apply to update the node with the properties that you have set.
7. Repeat these steps to add more nodes to the cluster if desired.
Defining Queues
When users want to submit a job to a cluster, they must select a queue for the job. Each queue has
specific nodes associated with it, enabling you to control where and how jobs are run.
The ARC has a built-in local cluster queue for submitting jobs to the local machine, and a default
cluster queue that can submit jobs to any of the execution nodes. You can create additional queues
that submit jobs to specific execution nodes, or have custom properties.
1. To create a cluster queue, right-click Queues in the tree view and select Add a queue.
2. In the ARC Configuration Manager dialog box, enter a name for the queue in the edit box,
then click Add.
3. Select the newly added queue in the Queues list:
Define the queue properties:
State Set the current state of the queue
Active: The queue state is Enabled, and the current

time falls within the Active Time Range.
Suspended: The queue can accept jobs, but jobs will

remain queued.
Disabled: The queue will not accept jobs.

Priority The priority that this queue's jobs will be given in relation
to other queues. It is common to create a higher priority
queue for smaller jobs so that they are processed before
running large jobs that tie up computing resources for a
long period of time. A value of -254 is the highest priority,
while 254 is the lowest priority.
Set Active Time Range? If Set Active Time Range is disabled, jobs can be
submitted to this queue 24 hours a day.
Start Time/End Time
If Set Active Time Range is enabled, you can specify
a time range in which jobs can be submitted to the
queue. To define the range, specify a Start Time and
End Time.
Note:
• Jobs cannot be submitted to the queue

at all if its State is set to Disabled.
• If a time range has been set, and the

current time does not fall within that
range, the Current queue status
displayed will be Closed.
Limit Concurrent Jobs? If Limit Concurrent Jobs is enabled, you can specify the
maximum number of jobs than can be run at one time from
Max Concurrent Jobs this queue.
4. Click Apply.
5. Go to the tree and select the queue’s Access Control option:
To specify the execution nodes to which this queue can submit jobs, enable the check boxes of
the desired nodes in the Allowed Nodes table. If you have recently added a new execution node
to the cluster, and do not see it in the list, click Refresh to update the list.
By default, all users who have access permission on the cluster nodes will be able to use this
queue. To restrict queue usage to specific users, enable the Restrict usage to specific users
option, then select all in the table and replace it with the username of the first user to whom
you would like to grant access. Continue adding usernames to the list, one username per row.
6. Click Apply.
7. Repeat the above steps to define more cluster queues if desired.
Defining Administrative Access

1. To specify the users and groups who are allowed to make cluster configuration changes (via the
master node), select Administrative Access in the tree.
2. By default, any user with admin access on the master node, as well as members of the RSM
Admins group, have permission to make cluster configuration changes:
3. To restrict configuration access to specific users or groups, use the Allowed Users and Allowed
Groups tables to specify the desired user accounts and group names.
4. Click Apply.
Caching Credentials for Cluster Job Submission

In a multi-node Ansys RSM Cluster (ARC), you can use the Cache Password action to cache the
password for the currently logged-in user account. This will allow RSM to easily access machines in
the cluster when this account is used to log in to the cluster.
To cache the password for the current user account:
1. Right-click Administrative Access in the tree, then select Cache Password.
2. Enter the password that you want RSM to use when the cluster is accessed with the current user
account, then click Confirm:
Note:
If you want RSM to use a different account to log in to the cluster, you will need to
cache the password for that account using the arccredentials command instead. For
more information, see Caching Credentials for Cluster Job Submission (arccreden-
tials) (p. 100)
Refreshing the View During ARC Configuration

When using the ARC Configuration application, you can refresh the view at any time by selecting
View > Refresh. This pulls in information from any nodes or queues that have been added or edited
via other means. For example, if you added a cluster queue using the command line, refreshing the
view in the ARC Configuration application will display that queue in the Queues list.
To set up an automatic refresh that occurs at a regular interval, select View > Auto Refresh (30s in-
terval).
4.4.3. Configuring an Ansys RSM Cluster (ARC) Using the Command Line
(arcdeploy)
The arcdeploy command provides the same functionality as the ARC Configuration application, but
delivers it via the command line for those who require or prefer this type of deployment.
Before using this command, refer to Prerequisites for ARC Configuration (p. 71) to ensure that all
nodes are accessible and suitable for ARC configuration.
The information that you enter is captured in a CSV file so that you can quickly and easily deploy the
same cluster again in the future.
Running the ARCDEPLOY Command

The arcdeploy command must be run on the machine that will serve as the Master node.
1. On the Master node, in a command window, run the following command:
%AWP_ROOT221%\RSM\ARC\tools\winx64\arcdeploy.cmd
2. Type y (for yes) to confirm that you have full Administrator and/or sudo rights on all cluster
nodes.
3. Type y to confirm that Ansys software is uniformly installed on the Master node and all Execution
nodes.
4. Type y to confirm that all nodes in the cluster are based on the same Operating System.
5. Type y to confirm that the current machine will serve as the cluster's Master node.
Information about the current node is displayed:
The path shown is the detected directory of the deployment application. This directory must
reside within the Ansys installation directory.
The hostname of the current machine is also detected and displayed.
6. To record the name shown as the Master hostname, type y. Otherwise, to record a different
Master hostname type n (for no), then type the desired name. The specified hostname must exist
in DNS or other hostname resolution system. The recorded name is the one that will appear in
the command's output when performing upcoming steps.
The ARC Master service is installed on the Master node:
You are then prompted to enter the hostnames of the Execution nodes:
7. Type the hostname of an Execution node, then press Enter. Repeat this step for each remaining
Execution node (including the Master node if it will be used to execute jobs).
8. When you have completed the list of Execution nodes, press CtrlX and then press Enter.
9. Review the list for accuracy, then type y to confirm that it is correct.
The ARC Node service is installed on each Execution node:
The ARC will have a built-in local cluster queue for submitting jobs to the local machine, and
a default cluster queue that can submit jobs to any of the execution nodes. You can create
more queues in the next step.
10. If you wish to create an additional cluster queue, type y.
a. Type the desired name for the new queue, then press Enter.
b. Verify the name entered, then type y to confirm it.
c. Specify which nodes should be assigned to this queue:
• To add all Execution nodes to this queue, type y.
All Execution nodes are added to the queue. When prompted, specify whether or not you
want to add the Master node to the queue as well, by typing either y or n:
• To add only specific Execution nodes to this queue, type n.
The queue will be established, but will not have any nodes assigned to it. You will need
to do this using different commands after the cluster has been deployed. See Modifying
a Cluster Queue (p. 98).
11. When you have finished adding queues, type n and press Enter at the Do you want to add
another queue? (Y/N) prompt.
Each queue will be created and enabled, and the appropriate nodes will be assigned to each
queue according to the responses that you entered:
12. To save all of the information that you have entered to the default CSV file name, arcde-
ploy.config.csv, simply press Enter. Otherwise, type the desired file name and press Enter.
You can use this file to instantly deploy the same cluster in the future if needed. To do this, you
will use the -f argument when issuing the arcdeploy command.
The cluster has been deployed and is ready to use.
4.5. Defining an RSM Configuration for an Ansys RSM Cluster (ARC)

In order for users to be able to submit jobs to an Ansys RSM Cluster (ARC), you must define a configur-
ation for the ARC using the RSM Configuration application (see Launching the RSM Configuration Ap-
plication (p. 33)). Defining a configuration for an Ansys RSM Cluster (ARC) is the same as defining a
configuration for a third-party cluster. The only distinction is that you set the HPC type to ARC:
Defining an RSM Configuration for an Ansys RSM Cluster (ARC)
The submit host is the machine that is responsible for submitting jobs to the cluster, and on which the
Master service is installed. You have two options when specifying the Submit host value:
• Specifying 'localhost' in the Submit host field indicates that the RSM client and the ARC submit host
are the same machine. This means that jobs will be submitted, scheduled and run on the same machine
(a user's local machine). The RSM configuration will exhibit the same behavior as the default 'localhost'
configuration described in The Default 'Localhost' Configuration (p. 68).
• Specifying a hostname or IP address in the Submit host field designates a particular machine in your
network as the ARC submit host. This could be the current machine (on which you are creating the
RSM configuration), or a remote one. Even if the current machine is the submit host, you must specify
the hostname and OS of this machine if other users will be submitting jobs to this machine:
For an overview of the settings in a cluster configuration, refer to Defining RSM Configurations (p. 33).
4.6. Ansys RSM Cluster (ARC) Command Usage and Options

Ansys RSM Cluster (ARC) command scripts are located in the following directories:
Windows commands: %AWP_ROOT221%\RSM\ARC\tools\winx64
Linux commands: $AWP_ROOT221/RSM/ARC/tools/linx64
Many of the commands have options that enable you to modify the operation of the command.
To view the available options for a command, simply type the command name with no command to
run. For example:
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>arcconfig node
Usage:
-? or -h: Display usage
In order to add a new execution node, simply start the execution node services on that host.
Modify execution node settings.

modify <machineName> <options> <arguments>
-mn <HostName> (Master machine name)
-c <Cores> (Max cores assignable - default 'all')
-r m:25[b|kb|mb|gb|tb] (Max memory assignable - default mb)
-r d:30[b|kb|mb|gb|tb] (Max disk assignable - default mb)
-r d:30tb,m:40b (Multiple resource assignments)
Basic job-related commands like arcsubmit and arcstatus are used in both single- and multi-node ARC
setups. Additional commands are available for administrators who would like to further customize an
ARC configuration.
The following sections provide details about how each command is used, and the options available for
command execution:
4.6.1. Installing ARC Cluster Services on Windows (installservice)
4.6.2. Uninstalling ARC Cluster Services on Windows (uninstallservice)
4.6.3. Installing ARC Cluster Services on Linux
4.6.4. Uninstalling ARC Cluster Daemon Services on Linux (uninstall_daemon)
4.6.5. Commands for ARC Job Management
4.6.6. Configuring ARC Cluster Nodes (arcconfig node modify)
4.6.7. Displaying Resource Availability on ARC Nodes (arcnodes)
4.6.8. Configuring ARC Queues (arcconfig queue)
4.6.9. Displaying the Status and Details of ARC Queues (arcqueues)
4.6.10. Caching Credentials for Cluster Job Submission (arccredentials)
4.6.11. Migrating an ARC Setup from a Previous Version (arcconfig migration)
4.6.1. Installing ARC Cluster Services on Windows (installservice)

To be able to run a multi-node Ansys RSM Cluster (ARC), such that jobs can be dispatched to one or
more nodes, you must install the Master service on the node that you are designating as the cluster
Ansys RSM Cluster (ARC) Command Usage and Options
submit host, and install the Node service on every node that will be used for job execution (including
the submit host if it will be used for running jobs).
For Windows, use the installservice command and options to complete the following tasks:
4.6.1.1. Installing the ARC Master Service on a Windows Head Node
4.6.1.2. Installing the ARC Node Service on Windows Execution Nodes
4.6.1.1. Installing the ARC Master Service on a Windows Head Node

To install the ARC Master service on a Windows cluster head node, run the following command:
%AWP_ROOT221%\RSM\ARC\tools\winx64\installservice -arcmaster
Upon successful installation, the following is reported in the command window:

The Ansys RSM Cluster Master Service 2022 R1 service is starting.
The Ansys RSM Cluster Master Service 2022 R1 service was started successfully.
4.6.1.2. Installing the ARC Node Service on Windows Execution Nodes

To install the ARC Node service on a Windows execution node, run the following command on
every execution node (including the head node if you are also using it as an execution node):
%AWP_ROOT221%\RSM\ARC\tools\winx64\installservice -arcnode
Upon successful installation, the following is reported in the command window:

The Ansys RSM Cluster Node Service 2022 R1 service is starting.
The Ansys RSM Cluster Node Service 2022 R1 service was started successfully.
4.6.2. Uninstalling ARC Cluster Services on Windows (uninstallservice)

If you have configured a Windows Ansys RSM Cluster (ARC) and need to uninstall the Master service
or Node service for any reason, use the uninstallservice command with the appropriate option.
To uninstall the Master service on the head node, run the following command on that node:
%AWP_ROOT221%\RSM\ARC\tools\winx64\uninstallservice -arcmaster
To uninstall the Node service on an execution node, run the following command on that node:
%AWP_ROOT221%\RSM\ARC\tools\winx64\uninstallservice -arcnode
4.6.3. Installing ARC Cluster Services on Linux

To be able to run a multi-node Ansys RSM Cluster (ARC), such that jobs can be dispatched to one or
more nodes, you must install the ARC Master service on the node that you are designating as the
cluster submit host, and install the ARC Node service on every node that will be used for job execution
(including the submit host if it will be used for running jobs).
When installing an ARC cluster service on Linux, you must determine if you want to install the service
as a daemon that will start the service automatically when the machine is booted, or if you want to
start the service manually via a startup script. Use only one of these methods.
When an ARC cluster service is started manually, it runs as a process for the user who initiated the
service. A manually started ARC cluster service is stopped each time the machine is rebooted. After
a reboot you must restart the ARC cluster service by running the startup script.
In a multi-node ARC on Linux, it is recommended that you install cluster services as daemons.
4.6.3.1. Adding Common Environment Variables for an ARC on Linux

Before installing ARC cluster services on Linux, you can edit the arc_env_profile file in the
$AWP_ROOT221/RSM/ARC/tools/linx64 directory. In this file, you can add any common en-
vironment variables to be used by the cluster. Once defined, ARC services should inherit these en-
vironments when any job is run on the ARC. 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 user’s $HOME directory.
The following shows the content of arc_env_profile file:

#!/bin/sh
# The following examples show loading environment settings specific to ARC Advanced mode.
# When defined, ARC services will inherit the environment created here
# . /home/batch/environmentVariables/conf/settings.sh
Note:
• This profile only works on Linux. Windows users should modify their environment via
the environment interface in Windows.
• This profile will work for all Ansys RSM Cluster (ARC) jobs, but the shell is dependent
on what is chosen.
– For a basic ARC configuration in which no special setup has been performed, this
file must be written in /bin/sh. This applies, for example, when a user submits a
job to a single-node ARC, and RSM auto-starts ARC services on the node if they are
not running.
– For an ARC configuration where ARC services have been configured as daemon
services, arc_env_profile should be written in whatever shell is chosen in the
LinuxShellToUse setting in the Ans.Rsm.AppSettings.config file.
• Ensure that you set this profile carefully. Setting it incorrectly could prevent RSM and
ARC from working properly.
4.6.3.2. Starting ARC Cluster Services Manually on Linux (arcmaster | arcnode)

You can run ARC cluster service scripts to manually start, stop, and check the status of ARC cluster
services.
Manually Running the ARC Master Service Script

Use the arcmaster service script and appropriate option to manually start, stop, and check the
status of the ARC Master service on a Linux cluster head node.
To start the ARC Master service, run $AWP_ROOT221/RSM/ARC/tools/linx64/arcmaster

start.
To stop the ARC Master service, run $AWP_ROOT221/RSM/ARC/tools/linx64/arcmaster

stop.
To check the status of the ARC Master service, run

$AWP_ROOT221/RSM/ARC/tools/linx64/arcmaster status.
Manually Running the ARC Node Service Script

Use the arcnode service script and appropriate option to manually start, stop, and check the status
of the ARC Node service on Linux execution nodes.
To start the ARC Node service, run $AWP_ROOT221/RSM/ARC/tools/linx64/arcnode

start.
To stop the ARC Node service, run $AWP_ROOT221/RSM/ARC/tools/linx64/arcnode stop.
To check the status of the ARC Node service, run

$AWP_ROOT221/RSM/ARC/tools/linx64/arcnode status.
4.6.3.3. Starting ARC Cluster Services Automatically at Boot Time for Linux (in-
stall_daemon)
You can configure an ARC cluster service to start automatically when the machine is booted by
configuring it as a “daemon” service (if the service is not configured to start automatically, then it
must be started manually, as described in Starting ARC Cluster Services Manually on Linux (arcmaster
| arcnode) (p. 90)). Daemon services are scripts or programs that run persistently in the background
of the machine, and which are usually executed at startup by the defined runlevel.
Once the daemon service is installed, the cluster service will be started automatically without re-
booting. The next time the machine is rebooted, the installed cluster service will be started auto-
matically.
Installing the ARC Master Service as a Daemon

To install the ARC Master service as a daemon on a Linux cluster head node, run the following
command:
$AWP_ROOT221/RSM/ARC/tools/linx64/install_daemon -arcmaster
Installing the ARC Node Service as a Daemon

To install the ARC Node service as a daemon on a Linux execution node, run the following command:
$AWP_ROOT221/RSM/ARC/tools/linx64/install_daemon -arcnode
4.6.4. Uninstalling ARC Cluster Daemon Services on Linux (uninstall_daemon)

If you have installed the ARC Master service or ARC Node service as a daemon, and need to uninstall
it, use the uninstall_daemon command with the appropriate option.
To uninstall the Master daemon service on the head node, run the following command on that node:
$AWP_ROOT221/RSM/ARC/tools/linx64/uninstall_daemon -arcmaster
To uninstall the Node daemon service on an execution node, run the following command on that
node:
$AWP_ROOT221/RSM/ARC/tools/linx64/uninstall_daemon -arcnode
4.6.5. Commands for ARC Job Management

The following topics describe commands that are used to manage job submission in Ansys RSM
Cluster (ARC) setups:
4.6.5.1. Submitting a Job (arcsubmit)
4.6.5.2. Getting the Status of a Job (arcstatus)
4.6.5.3. Cancelling a Job (arckill)
Note:
This is for reference or debugging purposes only. We do not recommend using these
commands directly for cluster job submission. RSM is designed to integrate with Ansys
RSM Cluster setups, eliminating the need to manually issue job submission commands.
4.6.5.1. Submitting a Job (arcsubmit)

The arcsubmit command in the ARC command directory (p. 88) is used to submit a job to an Ansys
RSM Cluster (ARC). It will return a job ID that will be used to determine when the job is completed,
or to cancel the job if needed.
Note:
The arcsubmit command cannot be issued independently. It only works when issued
via RSM.
Table 4.2: Options for 'arcsubmit'
Option Description Default

Setting
-n[umberExecUnits] [cores: ]2 The number of cores used for the job. [cores:]1
-q[ueue] <queueName> The name of the cluster queue to which 'default'
the job will be submitted.
-a[liasName] <testjob> User-specified name to be used for the blank
job, as needed for accounting or display
Option Description Default

Setting
-d[istributed] <fill | span> Defines the distributed mode. For None
distributed jobs, this flag must be set to
either “fill” or “span”. “Fill” means use all
the cores on machine1 before using
machine2. “Span” means use one core
from every machine first. If not set, then
the job will wait until it can run on a
single machine.
-r[esource] m[emory]:25[b|kb|mb|gb|tb] Suggests the maximum memory that m:0mb
the job will need to use. Default of 0
means “do not track”.
-r[esource] d[isk]:30[b|kb|mb|gb|tb] Suggests the maximum disk space that d:0mb
the job will need to allocate. Default of
0 means “do not track”.
-r[esource] Specifies the maximum resources
d[isk]:30[b|kb|mb|gb|tb],m[emory]:40[b|kb|mb|gb|tb]
(memory and disk space) that can be
allocated to a job. If the resource needed
to run a job is not available, the job will
remain queued until it is able to run.
-w[orkdir] /somewhere/else/ The staging directory for job files. (This current
directory should be shared by all the directory
execution nodes.)
-x[clusive] Runs jobs in "exclusive" mode. This not used
means that when a job is running, no
other jobs can be scheduled on the
same nodes that are assigned to this job.
-e[rrorFile] FileName Defines an alternate error file name. This <Job#>.Error
is where stderr will be redirected from
the cluster job.
-o[utputFile] FileName Defines an alternate output file name. <Job#>.Output
This is where stdout will be redirected
from the cluster job.
-v[ariables] <All | var1:var2:> Allows specification of environment None
variables that need to be passed to the
job. They should be already set in the
submission environment in order to be
passed. The keyword “All” will pass
almost all variables except some
system-specific variables.
4.6.5.2. Getting the Status of a Job (arcstatus)

The arcstatus command in the ARC command directory (p. 88) is used to retrieve and display the
status of a job.
If the job ID is provided, the status of that specific job is retrieved.
arcstatus [jobId]
If no job ID is provided, the status of all running jobs is retrieved.
The following example shows the types of information that the arcstatus command retrieves:
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>arcstatus
JobNumber Status UserName Cores Submit Time Queue Assigned Machines Info
==========================================================================================================
1 Finished ANSYS\atester 2 11/12/2018 17:21:09 test atester1234:2 No Errors
4.6.5.3. Cancelling a Job (arckill)

The arckill command in the ARC command directory (p. 88) is used to cancel a running job. The
job ID is provided as an argument:
arckill [jobId]
4.6.6. Configuring ARC Cluster Nodes (arcconfig node modify)

The arcconfig node modify command in the ARC command directory (p. 88) is used to specify settings
that are specific to the setup of cluster nodes. Options for this command are described below.
Table 4.3: Options for 'arcconfig node modify'
Option Description Value

-mn <HostName> Points an execution node to the Master
master node. To see how this machine
option is used, refer to Associating name
ARC Execution Nodes with the
Master Node (p. 95).
-c <Cores> Restricts the number of cores used Max cores
by the ARC on an execution node. assignable -
Refer to Setting the Maximum default 'all'
Number of Cores to be Used on an
Execution Node (p. 95).
-r[esource] m[emory]:30[b|kb|mb|gb|tb] Restricts the amount of memory Max
allocated to ARC jobs on an memory
execution node. Refer to Setting assignable -
the Maximum Resource Allocation default mb
on an Execution Node (p. 96).
-r[esource] d[isk]:30[b|kb|mb|gb|tb] Restricts the amount of disk space Max disk
allocated to ARC jobs on an assignable -
execution node. Refer to Setting default mb
the Maximum Resource Allocation
on an Execution Node (p. 96).
Refer to Setting the Maximum
Resource Allocation on an
Execution Node (p. 96).
Option Description Value

-r[esource] Restricts the resources (disk space Multiple
d[isk]:30[b|kb|mb|gb|tb],m[emory]:40[b|kb|mb|gb|tb] and memory) allocated to ARC jobs resource
on an execution node. If the assignments
resource needed to run a job is not
available, the job will remain
queued until it is able to run. Refer
to Setting the Maximum Resource
Allocation on an Execution
Node (p. 96).
The following are the key uses for this command when configuring ARC execution nodes:
4.6.6.1. Associating ARC Execution Nodes with the Master Node
4.6.6.2. Setting the Maximum Number of Cores to be Used on an Execution Node
4.6.6.3. Setting the Maximum Resource Allocation on an Execution Node
Important:
Once ARC cluster services have been started on cluster nodes, you do not have to go to
each execution node to configure it. You can configure any execution node from the
master node or any other node in the cluster as long as the firewall exemption has been
set up correctly.
4.6.6.1. Associating ARC Execution Nodes with the Master Node

In a multi-node Ansys RSM Cluster (ARC), the ARC Master service will be dispatching jobs to one
or more execution nodes. For successful job submission and monitoring, you must configure the
execution nodes to report to the master node.
For each execution node, run the following command in the ARC command directory (p. 88), replacing
<execHostName> and <masterHostName> with the machine name of the execution node and
master node:
arcconfig node modify <execHostName> -mn <masterHostName>
4.6.6.2. Setting the Maximum Number of Cores to be Used on an Execution Node

By default, there are no restrictions on the number of cores used by an Ansys RSM Cluster (ARC)
when cluster jobs are run. Use the following command in the ARC command directory (p. 88) to
restrict the number of cores used by the ARC on an execution node:
arcconfig node modify <execHostName> -c <Cores>
Note:
This command can also be issued for a single-node ARC to limit the number of cores to
be used on the single cluster node. Individual users who use the localhost configur-
ation can run the command on their own machines if they do not want to use all of the
cores on their machines to run jobs.
For example, to set the maximum number of cores to 2 on MACHINE2, specify arcconfig node
modify machine2 -c 2.
The change will be reported in the command window:

Execution node configuration before update:
Exec Node Name Associated Master Port Max Cores Max Memory Max Disk
===============================================================================
MACHINE2 MACHINE1 13221 8Cores * *
* Indicates that resources have not been set up. Any resource request will be accepted.
Execution node config updated: MACHINE2
Current execution node setup after modification:
===============================================================================
MACHINE2 MACHINE1 13221 2Cores * *
To use all cores that you have, specify arcconfig node modify <execHostName> -c
all.
4.6.6.3. Setting the Maximum Resource Allocation on an Execution Node

By default, there are no restrictions on the amount of disk space or memory that can be used by
ARC cluster jobs on an execution node. Use the commands below in the ARC command direct-
ory (p. 88) to set the maximum amount of disk space and/or memory that can be allocated to a
cluster job.
To restrict disk space usage:
arcconfig node modify <execHostName> -r d:<value>[b|kb|mb|gb|tb]
To restrict memory usage:
arcconfig node modify <execHostName> -r m:<value>[b|kb|mb|gb|tb]
To restrict both disk space and memory usage:
arcconfig node modify <execHostName> -r

d:<value>[b|kb|mb|gb|tb],m:<value>[b|kb|mb|gb|tb]
Note the change in the Max Memory and Max Disk values in the example below:
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>arcconfig node modify machine2 -r d:30tb,m:40mb
Execution node configuration before update:
===================================================================================
machine2 machine1 13221 2Cores * *
Execution node config updated: machine2
Current execution node setup after modification:
===================================================================================
machine2 machine1 13221 2Cores 40Mb 30Tb
4.6.7. Displaying Resource Availability on ARC Nodes (arcnodes)

Use the arcnodes command in the ARC command directory (p. 88) to view the cores, memory and
disk space available for job execution on ARC execution nodes at any given time.
To view resource information for a specific node, append the node's machine name to the command:
arcnodes <nodeName>
If a node name is not provided, the command will list information for all execution nodes, as shown
below:
Cores Memory DiskSpace

Exec Node Name Associated Master State Avail Max Avail Max Avail Max
===================================================================================================
EXECHOST1 ARCMASTER Running 2 4 20Mb 40Mb 6Gb 10Gb

EXECHOST2 ARCMASTER Running 4 6 60Mb 80Mb 20Tb 30Tb
EXECHOST3 ARCMASTER Running * * * * * *
The available cores, memory and disk space will vary depending on how much is currently being
consumed by jobs.
4.6.8. Configuring ARC Queues (arcconfig queue)

Cluster queues determine the machine(s) on which jobs will run.
Every multi-node ARC setup has a default cluster queue that can submit jobs to any machine(s)
in the cluster, and a local cluster queue for submitting jobs to the local machine. If you would like
certain types of jobs to be targeted to specific machines, you can create additional cluster queues to
address this desired behavior.
You can use the arcconfig queue command in the ARC command directory (p. 88) to add, remove
or modify ARC cluster queues.
In this section:
4.6.8.1. Adding a Cluster Queue

4.6.8.2. Removing a Cluster Queue
4.6.8.3. Modifying a Cluster Queue
4.6.8.1. Adding a Cluster Queue

To add a cluster queue to an Ansys RSM Cluster (ARC), run the following command in the ARC
command directory (p. 88), replacing <queueName> with the desired queue name:
arcconfig queue add <queueName>
Once you have added a queue you can assign machines to it, enable it, and specify other custom
settings. For options see Modifying a Cluster Queue (p. 98).
Note:
Newly added queues are not enabled upon creation.
4.6.8.2. Removing a Cluster Queue

To remove a cluster queue from an Ansys RSM Cluster (ARC), run the following command in the
ARC command directory (p. 88), replacing <queueName> with the name of the queue to be re-
moved.
arcconfig queue remove <queueName>
4.6.8.3. Modifying a Cluster Queue

To modify the settings of an existing cluster queue, such as the list of machines on which it will
run jobs, use the following command in the ARC command directory (p. 88), appending the desired
options and/arguments to the command:
arcconfig queue modify <queueName>
For example, to enable a queue that you have created, run the following command: arcconfig
queue modify <queueName> -e true.
Note:
Modifying the built-in default and local cluster queues is not recommended. Even
if you were to modify the default queue, it would continue to automatically add new
machines.
Table 4.4: Options for 'arcconfig queue modify'
Option Usage Format/Sample Value

-m Enter the names of the machines to which the queue machine1:machine2:machine3
<machines> will submit jobs.
Option Usage Format/Sample Value

-p <priority> Specify the priority that this queue's jobs will be given -255 to 255, where -255 is
in relation to other queues. Jobs will be run from the highest priority, and 255 is
highest priority queue first. It is common to create a lowest priority
higher priority queue for smaller jobs so that they
are processed before running large jobs that tie up
computing resources for a long period of time.
-e <enabled> Specify whether or not the queue is active (available True or False
for job submission).
-s You may want to suspend a queue temporarily in True or False
<suspended> order to perform maintenance. When a queue is
suspended, jobs can be submitted to the queue, but
will not be processed until the suspension is lifted.
-n Specify the maximum number of jobs that can be 0-255 or * for no limit
<numJobs> run from this queue.
-b Use this in conjunction with <endTime> to specify 00:00:01
<startTime> the time range in which jobs can be submitted using
this queue. Defining an availability range can be
useful when execution nodes or application licenses
are only available at certain times of the day.
-q <endTime> Use this in conjunction with <startTime> to specify 23:59:59
the time range in which jobs can be submitted using
this queue (see above).
-u <userList> Specify which users you are allowing to use the all | user1:user2:userN
queue.
4.6.9. Displaying the Status and Details of ARC Queues (arcqueues)

Use the arcqueues command in the ARC command directory (p. 88) to display the status and details
of all defined ARC cluster queues:
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>arcqueues
Name Status Priority Start Time End Time Max Jobs....Allowed Machines Allowed Users
=========================================================================================================
night_only Closed 0 21:00:00 06:00:00 * machine2 all

local Active 0 00:00:00 23:59:59 * machine1 all
default Active 0 00:00:00 23:59:59 * machine1 all
test Disabled 0 00:00:00 23:59:59 100 None tester1:tester2
highmem Active 0 00:00:00 23:59:59 * machine3:machine4 all
If a queue has been enabled, its Status will be either Active or Closed depending on whether or not
the current time falls within the queue's Start Time/End Time range.
If you did not enable a queue after creating it, or have disabled a queue, its Status will be Disabled
in the queue list. For information enabling queues, see Modifying a Cluster Queue (p. 98).
4.6.10. Caching Credentials for Cluster Job Submission (arccredentials)

In a multi-node Ansys RSM Cluster (ARC), you can use the arccredentials command in the ARC
command directory (p. 88) to cache the password that you want RSM to use when accessing machines
in the cluster. When no arguments are used, the arccredentials command will prompt you to enter
the password for the currently logged-in user:
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>arccredentials
Caching credentials for: ANSYS\atester
Password:
To change the account used to log in to execution nodes, run the following command:
arccredentials -a Username
4.6.11. Migrating an ARC Setup from a Previous Version (arcconfig migration)

Use the arcconfig migration command to automatically transfer ARC cluster configurations, ARC
queue definitions, ARC-related application settings and ARC node configurations from one version
of RSM to another, eliminating the need to redefine your ARC setup or manually move files every
time you upgrade to a new version.
This command works the same way as the general RSM migration utility (see Migrating RSM from a
Previous Version (p. 150)), but includes functionality to maintain your configuration of ARC cluster
nodes. This is done by migrating each node's settings, such as the cores and memory allocated for
job execution.
Follow the steps below to migrate an ARC setup to a new version.
1. On the master node, log into an account with administrative privileges (in other words, as a
member of the rsmadmins group, or as root).
2. If you have not already done so, install the new product version.
3. If you have not already done so, start the ARC services of the new version.
You will need to install the Master service on the master node, and the Node service on each
node that will be used for job execution.
Refer to the following:
• Installing ARC Cluster Services on Windows (installservice) (p. 88)
• Installing ARC Cluster Services on Linux (p. 89)
Note that ARC services of the previous version do not need to be running.
4. For a multi-node ARC, associate each execution node with the master node, as described in As-
sociating ARC Execution Nodes with the Master Node (p. 95).
5. Perform the following step on each ARC node.
Start a command prompt in the directory that applies to your setup:
Windows: %AWP_ROOT221%\RSM\ARC\tools\winx64
Linux: $AWP_ROOT221%/RSM/ARC/tools/linx64
6. Run the following command, appending the desired operator and options from the accompanying
tables:
arcconfig migration {operator} -v123 [-preview] [-verbose] [-silent]
Table 4.5: Operators for Migration
Operator Usage
config Migrate ARC cluster databases, such as ARC
configurations and queues.
settings Migrate ARC-specific settings in the RSM\Con-
fig\Ans.Rsm.AppSettings.config file.
(To see which settings will be migrated, refer to
the new version's RSM\Config\migra-
tion\Arc.AppSettings.Migrate.con-
fig file.)
all Migrate everything (cluster configurations,
queues, and settings).
Table 4.6: Options for Migration
Option Usage
-v123 (Required) Specify the version that you are
migrating, so that the migration command
knows which files to look for. Replace the 123
with the version that you are migrating (for
example, enter -v212 for version 2021 R2).
Note:
The oldest version that you can

migrate is version 18.0.
-preview Display a list of the items that will be migrated,

without actually performing the migration.
-verbose Display more detailed information about the
migration and its progress.
-silent Perform the migration without confirmation
prompts. Useful for scripting.
Example
In the following example we are using the arcconfig migration command on the master node to
migrate ARC queues and master node settings previously defined in version 2021 R2 to a new, version
2022 R1 installation.
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>arcconfig migration all -v212 -preview -verbose
v221 settings located at C:\Program Files\ANSYS Inc\v221\RSM\Config\Ans.Rsm.AppSettings.config

Settings to migrate located at C:\Program Files\ANSYS Inc\v221\RSM\Config\migration\Arc.AppSettings.Migrate.config
Skipping AlternateAllowedPrompt = empty

Skipping PythonSpawnForLinuxLogin = true
Skipping AdvancedModeOn = true
Migrating AutoStartServicesAsUser from true to false
Skipping UseIPv6 = false
Skipping CommunicationTimeoutMs = 30000
Skipping MaxQueueDepth = 100
Skipping NodeCommunicationIntervalSeconds = 30
Skipping LinuxShellToUse = /bin/csh
Skipping UseSSL = false
Skipping PfxCertificateFileForSsl = empty
Skipping JobDatabaseDirectory = empty
Skipping JobDatabaseName = JobDb.xml
Skipping LoadDatabaseName = LoadDb.xml
Skipping ConfigDatabaseName = QueueDb.xml
Skipping UserDatabaseName = UserDb.xml
Skipping NodeJobDatabaseName = NodeJobDb.xml
Skipping NodeLoadDatabaseName = NodeLoadDb.xml
Skipping NodeConfigDatabaseName = NodeCommunicationConfig.xml
Skipping DatabaseUpdateIntervalSeconds = 15
Skipping DatabaseCleanupIntervalMinutes = 1
Skipping DatabaseMinNumberOfJobsToKeepOnCleanup = 10
Skipping CleanupTimeMinutes = 5
Skipping ServiceLogEnabled = true
Skipping ServiceLogDirectory = empty
1 settings to migrate.

Current Database Directory: C:\ProgramData\Ansys\v221\ARC
Migrating
C:\ProgramData\Ansys\v221\ARC\..\..\v212\ARC\NodeCommunicationConfig.xml
to
C:\ProgramData\Ansys\v221\ARC\ARCMASTER_NodeCommunicationConfig.xml
Skip migrating queue: default - the built-in queue cannot be migrated.
Skip migrating queue: local - the built-in queue cannot be migrated.
Queue successfully merged: highmem
Queue successfully merged: night_only
Queue successfully merged: test
C:\Program Files\ANSYS Inc\v221\RSM\ARC\tools\winx64>
Note:
If a queue with the same name already exists in the new setup, it will not be migrated.
Dealing with a Firewall in a Multi-Node Ansys RSM Cluster (ARC)
4.7. Setting the ARC_ROOT Environment Variable for Ansys RSM Cluster
(ARC) Job Submission
Important:
Although different versions of RSM can be installed side by side, RSM allows only one version
of ARC to be used on each node at one time. You cannot have two versions of an ARC (for
example, 2021 R2 and 2022 R1) running at the same time. This ensures that resources such
as cores, memory and disk space can be properly allocated on each node.
When multiple versions of RSM are running, it is recommended that you set the ARC_ROOT environment
variable on the ARC master node to ensure that the correct version of ARC is used when jobs are sub-
mitted to that machine.
The variable should point to the following directory, where xxx is the version that you want to use (for
example, 221):
Windows: %AWP_ROOTxxx%\RSM\ARC
Linux: $AWP_ROOTxxx/RSM/ARC
If you do not specify the ARC_ROOT variable, RSM will attempt to use the ARC from the current install-
ation.
4.8. Dealing with a Firewall in a Multi-Node Ansys RSM Cluster (ARC)

If you have set up a firewall to protect computer ports that are connected to the Internet, traffic from
the master node to the execution nodes (and vice versa) may be blocked. To resolve this issue, you
must enable ports on cluster nodes to allow incoming traffic, and then tell each node what port to use
when communicating with other nodes.
There are three port values that you can set:
CommandCommunicationPort: The port on the master and execution nodes that allows incoming
commands such as arcsubmit and arcstatus to be read. By default, port 11221 is used.
MasterCommunicationPort: The port on the master node that allows incoming traffic from
execution nodes. By default, port 12221 is used.
NodeCommunicationPort: The port on the execution node that allows incoming traffic from
the master node. By default, port 13221 is used.
To specify port numbers for ARC cluster nodes to use:
rsm.exe appsettings AnsysRSMCluster <PortName> <PortValue>
rsmutils appsettings AnsysRSMCluster <PortName> <PortValue>
For example, to set the value of the node communication port to 14221 on Windows, you would enter
the following:
rsm.exe appsettings set AnsysRSMCluster NodeCommunicationPort 14221
Important:
• Port settings must be specified on the master node and each execution node. If you are
not using a network installation of RSM, this means that you will need to run the RSM
Utilities application (in other words modify the Ans.Rsm.AppSettings.config file)
on each node in the cluster.
• When specifying the three ports, make sure that each port is different, and is not being
used by any other service (such as the RSM launcher service).
4.9. Example: Setting Up a Multi-Node Ansys RSM Cluster (ARC)

The example provided in this section contains detailed, step-by-step instructions for setting up a multi-
node Ansys RSM Cluster (ARC), and creating a configuration in RSM that enables users to submit jobs
to this cluster.
Note:
Multi-node ARC configuration requires system administrator or root permission and should
only be performed by an IT administrator.
Scenario
Cluster Nodes
There are 4 machines available for scheduling and running jobs. Their names and roles are described
below.
• ARCMASTER: This is the machine to which jobs will be submitted from users' client machines for
scheduling. In other words, it is the cluster submit host, or master node.
At a minimum this machine has Workbench and RSM installed, as well as the RSM launcher service
(see Installing and Configuring the RSM Launcher Service for Windows (p. 21)).
We will install the Master service on this machine.
• EXECHOST1, EXECHOST2 and EXECHOST3: These are high-capacity machines on which jobs will
run. In other words, they are execution nodes. They have Workbench, RSM, and Ansys solvers installed.
On EXECHOST1 and EXECHOST2 we will restrict the number of cores that can be used by ARC jobs
on those machines, and place no restrictions on EXECHOST3 so that it can handle larger jobs.
We will install the Node service on each of these machines, and associate them with the ARCMASTER
machine to essentially create a cluster.
Example: Setting Up a Multi-Node Ansys RSM Cluster (ARC)
Note that if we wanted to use ARCMASTER to run jobs as well, we would simply need to install the
Node service on that machine. For this example, we will assume that only EXECHOST1, EXECHOST2
and EXECHOST3 will be used for running jobs.
Note:
All nodes in an Ansys RSM Cluster must run on the same platform (Windows or Linux). In-
structions for both platforms are provided in this example.
Cluster Queues
The ARC will already have a local cluster queue for submitting jobs to the local machine, and a de-
fault cluster queue that can submit jobs to any of the execution nodes.
We are going to create a custom cluster queue named high_mem that will be dedicated to running
jobs on EXECHOST3 only, which is the execution node with unrestricted resource allocation. We will
also set the maximum number of jobs that can be run on this queue to 100.
RSM Configuration
Once we have set up the ARC cluster, we will use the RSM Configuration application to create a config-
uration named ARC. We will import the ARC cluster queues (local, local and high_mem) into the
configuration and create RSM queues that map to these cluster queues.
Finally, we will make the ARC configuration available to users so that the RSM queues defined in the
configuration appear in client applications on their machines, enabling them to submit jobs to the RSM
queues (which map to the ARC cluster queues). Jobs will be sent to ARCMASTER, where the Master
service will dispatch jobs to the execution nodes.
Below is an overview of the ARC setup that we will be creating:
Step 1: Configure Cluster Nodes and Queues

We will use the ARC Configuration application to connect our 4 machines together, install ARC services
on cluster nodes, create a custom cluster queue, and cache credentials.
1. Sign in to ARCMASTER (the master node) as an Administrator.
2. On the master node, launch the ARC Configuration application as follows:
• On Windows, select Start > Ansys 2022 R1 > ARC Configuration 2022 R1.You can also
launch the application manually by double-clicking the following executable:
[RSMInstall]\ARC\bin\arcConfigConsole.exe
• On Linux, run the following script:
<RSMInstall>/ARC/Config/tools/linux/arcconfigui
3. On the Local Service Management page, set the Cluster Usage and Service Management options
as follows:
Remember that we are not using the master node for job execution (but could if we wanted to).
4. Click Start to start the Master Node Service on the current machine.
5. Once the Master Node Service is started, right-click Execution Nodes in the tree and select Add
an execution node.
6. In the ARC Configuration Manager dialog box, type exechost1, then click Add:
A connection is made to the EXECHOST1 machine, and it is added to the node list.
7. In the Execution Nodes list, select exechost1.
8. Click Start to start the Execution Node Service on EXECHOST1.
9. In the properties panel, set Max Cores to 4 to limit the number of cores that can be used by cluster
jobs on EXECHOST1.
10. Click Apply.
11. In the tree, right-click Execution Nodes and select Add an execution node.
15. In the properties panel, set Max Cores to 4.
16. Click Apply.
17. In the tree, right-click Execution Nodes and select Add an execution node.
21. In the properties panel, delete the value in the Max Cores so that there are no restrictions on the
number of cores that cluster jobs can use on EXECHOST3.
22. Click Apply.
Now that the cluster nodes have been established, we can create cluster queues. We will create a
queue named high-mem. This queue will run jobs on EXECHOST3 only. This is the only machine
with unrestricted resource allocation, making it ideal for larger jobs. We will also set the maximum
number of jobs that can run on the high_mem queue to 100.
23. In the tree, right-click Queues and select Add a queue.
24. In the ARC Configuration Manager dialog box, type high-mem, then click Add:
25. In the Queues list, select the new high-mem queue.
26. In the properties panel, enable the queue and set the Max Concurrent Jobs to 100:
27. Click Apply.
28. In the tree, select the high-mem queue’s Access Control setting. Then, in the Node Assignments
area, enable the exechost3 check box, and ensure that the other nodes are not checked:
This specifies that jobs submitted to this queue will only run on EXECHOST3.
29. Click Apply.
30. In the tree, right-click Administrative Access and select Cache Password.
31. Enter the password that you want RSM to use when the cluster is accessed with the current user
account, then click Confirm:
Note:
If we wanted RSM to use a different account to log in to the cluster, we would run the
arccredentials command to cache the credentials for that account. For more information,
see Caching Credentials for Cluster Job Submission (arccredentials) (p. 100).
32. Close the ARC Configuration application.
At this point the Ansys RSM Cluster is set up and ready to receive job submissions from client machines.
Step 2: Create an ARC Configuration in RSM

In order for RSM client machines to be able to submit jobs to the ARC submit host (ARCMASTER), we
must create a configuration in RSM that establishes communication between the client and submit
host, specifies the file transfer method, and specifies RSM queues that map to the ARC cluster queues.
1. Launch the RSM Configuration application by selecting Start > Ansys 2022 R1 > RSM Configuration
2022 R1.
2. Click , or right-click in the HPC Resources list and select Add HPC Resource.
3. On the HPC Resource tab, specify a name for the configuration, select ARC for the HPC type, and
specify the machine name of the cluster submit host.
4. Click Apply, then select the File Management tab. Referring to Specifying File Management
Properties (p. 41), select the desired file transfer method, then specify the job execution working
directory.
5. Click Apply, then select the Queues tab.
6. Click to import the cluster queues that are defined on the ARCMASTER machine (default,
local and high_mem).
7. Since we are accessing ARCMASTER for the first time, we may be asked to enter the credentials
that RSM will use to access that machine:
8. Enter a User Name and Password that can be used to access ARCMASTER, then click OK. The
specified credentials will be cached, enabling any user using this configuration to submit jobs to
ARCMASTER.
9. For each ARC Queue in the list, you can specify a unique RSM Queue name if you want (by default,
the RSM queue name matches the cluster queue name). RSM queues are what users see in client
applications when they choose to submit jobs to RSM. You can also choose which queues you
want to enable for users, and submit a test job to each RSM queue by clicking Submit in the Test
column.
10. Click Apply to complete the configuration.
Step 3: Make the Configuration Available to Users

Since we named our configuration ARC, a file named ARC.rsmcc has been created in the RSM config-
uration directory. This directory also contains an RSM queue definition file named queues.rsmq. You
will need to make these files available to users who will be submitting jobs to the cluster via RSM. You
can do this by making the RSM configuration directory a shared directory, and instructing users to point
their own RSM configuration directory setting to this shared directory. Alternatively, users can copy the
RSM configuration files that you have created to the appropriate directory on their local machines.
With either of these options, if users were to launch the RSM Configuration application on their ma-
chines, they would see the ARC configuration automatically added to their HPC Resources list. They
could then start submitting jobs to the RSM queues that were defined in this configuration. RSM queues
are linked to the ARC configuration defined in RSM, which enables jobs to be submitted to ARCMASTER
for scheduling.
There are two options for making the ARC.rsmcc and queues.rsmq files available to users:
Option 1: Share the RSM configuration directory
This method ensures that all users have the most accurate and up-to-date configuration information,
as files are centrally stored and managed.
• If you changed the RSM configuration directory to a share-friendly folder before creating configurations
(as described in Creating a Shareable RSM Configuration Directory (p. 33)), you can go ahead and
share that folder. Make sure that the folder has read-only permission to prevent others from modifying
your configurations.
• If you did not change the RSM configuration directory before creating cluster configurations, your
configurations are located in the default configuration directory (p. 32), which is a user-specific dir-
ectory that is not suitable for sharing.
In this case, follow these steps:
Windows
C:\some\folder).
In this example, the resulting path will be C:\some\folder\ANSYS\v221\RSM. This location

will serve as the new configuration directory.
3. If the RSM service is currently running, stop it. As an administrator, run net stop

C:\some\folder\ANSYS\v221\RSM
You can specify a local path if the directory is on the local machine, or a UNC path if the directory
is a network share.
6. Go to the default configuration directory:
%APPDATA%\ANSYS\v221\RSM

sys\V221\RSM, where %username% is the name of the RSM or system administrator.
7. Copy the ARC.rsmcc and queues.rsmq files to the new RSM configuration directory (for ex-
ample, C:\some\folder\ANSYS\v221\RSM).
Linux
/some/folder).
2. Add the following required sub-folders to the folder: ANSYS/v221/RSM.
In this example, the resulting path will be /some/folder/ANSYS/v221/RSM. This location

will serve as the new configuration directory.
3. If the RSM service is currently running, stop it using rsmlauncher stop.
If the RSM service is running as a daemon, stop it using ./etc/init.d/rsmlauncher221

stop.
4. Run the rsmutils shell script located in the [RSMInstall]\Config\tools\linux direct-

ory. Issue the following command, replacing the path with the desired value:

/some/folder/ANSYS/v221/RSM
You can specify a local path or a mounted file system depending on where the directory resides.
5. Go to the default configuration directory:
~/.ansys/v221/RSM
6. Copy the ARC.rsmcc and queues.rsmq files to new configuration directory (for example,
/some/folder/ANSYS/v221/RSM).
Once the configuration directory has been shared, users should set the configuration directory on their
local machines to the path of the shared configuration directory. For example, the share path might be
something like \\machineName\Share\RSM for Windows users, or /clusternode-
mount/share/RSM for Linux users. They will follow the steps in Specifying the Location of the RSM
Configuration Directory (p. 147).
Note:
One potential drawback of this method is that users may not be able to access to the shared
configurations if the host goes offline or cannot be accessed for some reason (for example,
if a user is working off-site and does not have access to the network). In this case RSM will
automatically switch the configuration directory back to the default configuration directory
on their local machines. This means that users will, at a minimum, be able to submit jobs to
ARC clusters already installed on their local machines using the localhost configuration
that is generated in the default configuration directory when RSM is installed.
Option 2: Have users copy configuration files to their local machines
If you are a user looking to access configurations that have been defined by your RSM or system admin-
istrator, you can do so by setting your configuration directory to the shared configuration directory
that was set by the administrator (see Option 1 above). Alternatively you can copy the configuration
database to the appropriate directory on your machine.
As a user, you will need to:
1. Obtain the ARC.rsmcc and queues.rsmq files from the RSM or system administrator. If the ad-
ministrator has put the files in a shared directory that you can access, you can retrieve them directly
from there.
2. On your local machine, copy the files into your default configuration directory.
By default, the directory in which the configurations are stored resolves to the following location:
Windows: %APPDATA%\ANSYS\v221\RSM

sys\v221\RSM, where %username% is the name of the RSM or system administrator.
Linux: ~/.ansys/v221/RSM
Note:
If any of the shared files that you are copying have the same name as files in your local
configuration directory, you will need to rename your local files if you do not want them to
be overwritten. For example, you may want to rename your localhost.rsmcc file to
mylocalhost.rsmcc to distinguish it from the remote resource's localhost.rsmcc
file, as its settings may be different.
Alternatively, to avoid this issue altogether:
1. Create a new folder on your local machine (for example, C:\SharedRSMConfig).
In this example, the resulting configuration directory will be C:\SharedRSMConfig\AN-

SYS\v221\RSM.
3. Use the RSM Utilities application to set the JobManagement ConfigurationDir-

ectory setting to the new folder. See Specifying the Location of the RSM Configuration
Directory (p. 147).
4. Copy the configurations from the network share to your new configuration directory (for
example, C:\SharedRSMConfig\ANSYS\v221\RSM).
Chapter 5: RSM Integration with a Cluster or Cloud
Portal
When you want RSM to submit jobs to an HPC resource, whether it be an Ansys RSM Cluster (ARC), a
third-party cluster such as Microsoft Windows HPC or LSF, or a Cloud portal, you need to create a con-
figuration in RSM, as described in Defining RSM Configurations (p. 33). Additional steps may be required
to ensure successful cluster job submission.
Assumptions
• The cluster with which you want to integrate RSM has already been established and properly con-
figured. For information on setting up an Ansys RSM Cluster (ARC), refer to Ansys RSM Cluster (ARC)
Configuration (p. 63). The establishment of commercial clusters is beyond the scope of this user's
guide. For those steps, consult the documentation for the third-party scheduler you are using.
• You know the machine name of the cluster submit host (the node that performs job scheduling).
• 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 the cluster nodes. For
information on product and licensing installations, see the Installation and Licensing Documentation
on the Ansys Help site.
• RSM has been installed on the cluster submit host. See RSM Software Installation (p. 19).
• The RSM launcher service is installed and running on the cluster submit host if it will be accepting
submissions from remote RSM clients. See Installing and Configuring the RSM Launcher Service (p. 20).
This chapter describes the additional steps you may need to take when integrating RSM with an estab-
lished cluster.
5.1. Configuring RSM to Use SSH for Job Submission and/or File Transfers to a Remote Linux Cluster
5.2. Integrating RSM with a Microsoft HPC or Windows-Based Cluster
5.3. Integrating RSM with a Cloud Portal
5.1. Configuring RSM to Use SSH for Job Submission and/or File Transfers
to a Remote Linux Cluster
SSH/SCP (Secure Shell/Secure Copy) can be used to establish communication between a Windows RSM
client machine and a Linux-based ARC, LSF, PBS Pro, SLURM, or UGE (SGE) cluster. The SSH application
is used instead of RSM to execute cluster commands, monitor jobs, and copy data to/from the Linux
cluster node.
RSM Integration with a Cluster or Cloud Portal
RSM supports using SSH/SCP 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).
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 ANSYS221 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, see the Installation and Licensing
documentation on the Ansys Help site.
Steps for Establishing SSH Communication

To enable SSH communication with a Linux cluster, you need to:
1. Define a configuration in RSM which indicates that SSH will be used. See Defining a Configuration
for a Remote Linux Cluster (SSH) (p. 122).
2. Install and configure an SSH client (PuTTY SSH) on RSM client machines. See Configuring PuTTY
SSH (p. 123).
3. Review the configuration requirements described in Linux Path Configuration Require-

ments (p. 127).
Note:
• Ansys recommends that you use SSH only if your IT policy requires it. The communication
overhead that SSH imposes results in slower processing times when launching solutions
and retrieving results.
• RSM handles job submission and file transfers independently. This means that you have
the flexibility to choose whether you want to use SSH for either or both of these functions.
See Defining a Configuration for a Remote Linux Cluster (SSH) (p. 122).
5.1.1. Defining a Configuration for a Remote Linux Cluster (SSH)

If your organization's IT policy requires that the SSH protocol be used to submit jobs from a Windows
RSM client to a remote Linux submit host, or to transfer job files to a staging directory on a Linux
cluster, follow the steps in Defining RSM Configurations (p. 33), paying particular attention to the
following settings:
• To use SSH for job submission (communication with the submit host):
Configuring RSM to Use SSH for Job Submission and/or File Transfers to a Remote
Linux Cluster
On the HPC Resource tab, select Use SSH or custom communication to the submit host. Then,
in the Account name field, specify the account name that the Windows client will use to submit
jobs to the Linux submit host. For example:
Note:
The Account name specified is the SSH account and not the account that will be cached
by RSM. You will need to set up passwordless SSH access to the submit host. See Con-
figuring PuTTY SSH (p. 123).
• To use SSH to transfer job files to the cluster staging directory:
On the File Management tab, select External mechanism for file transfer (SCP, Custom), and
select SCP via SSH as the Transfer mechanism. For information about this and all available file
transfer methods, see Specifying File Management Properties (p. 41).
5.1.2. Configuring PuTTY SSH

In order to send RSM jobs or transfer job files 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 client and placing public portions of the key on the Linux machine.
Note:
SSH configuration must be completed by your IT administrator. This section provides in-
structions 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/~sgtath-
am/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.
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 your My Docu-
ments 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:
a. Open an SSH session to one of your cluster nodes, cd into ~/.ssh, and open the author-
ized_keys file in your favorite editor (for example, vi or Emacs).
b. Copy all the text from the box under Public key for pasting and paste it into ~/.ssh/au-
thorized_keys. All of this text should be one line.
c. If the authorized_keys file does not exist, create one. Alternatively, 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. In the Environment Variables dialog box, locate the Path variable in the System variables pane.
Configuring RSM to Use SSH for Job Submission and/or File Transfers to a Remote
Linux Cluster
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).
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.
Integrating RSM with a Microsoft HPC or Windows-Based Cluster
5.1.3. Linux Path Configuration Requirements

The RSM job scripts that integrate with the Linux cluster using PuTTY SSH require you to set
AWP_ROOT221 in your environment variables. If a job is not running properly, check the RSM job
log in the client application 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_ROOT221 /ansys_inc/v221
Note:
• ~ (tilde) representation of the home directory is not supported when specifying paths
in RSM (for example, the path of the HPC staging directory when defining a configuration).
• 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.
5.2. Integrating RSM with a Microsoft HPC or Windows-Based Cluster

You can configure RSM to submit jobs to a Microsoft HPC or Windows-based cluster by creating a
configuration in RSM, as described in Defining RSM Configurations (p. 33).
Following are additional considerations you may need to make when integrating with a Microsoft HPC
or Windows-based cluster.
Prerequisites Installation
The Ansys product installation requires the installation of several prerequisites. The installer will check
for these prerequisites on the machine where the installer is launched (for example, the head node). If
you plan to have a network installation of Ansys products in your Microsoft HPC or Windows-based
cluster, you must also install the prerequisites on each execution node. If you do not install the pre-
requisites on each cluster node, job execution may fail.
You can install the prerequisites separately by running ProductConfig.exe from the top-level directory
as an administrator. You can also install the prerequisites silently using the following command:
ProductConfig.exe -silent -prereqs
For more information, refer to the Ansys Installation and Licensing Documentation.
For a Microsoft HPC cluster, you may also be able to install the prerequisites on all nodes using the
clusrun utility that is part of the Microsoft HPC Pack installation. For more information, refer to the
Microsoft HPC documentation.
Passwords
RSM does not require 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.
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 con-
figured when the cluster domain was created.
Multiple Network Interface Cards

Cluster nodes, especially the head node, generally have multiple network interface cards (NIC) to facil-
itate 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 a Computer with
Multiple Network Interface Cards (NICs) (p. 60) 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 in-
stallation must be have "Full Trust" set on all compute nodes.
Setting the AWP_ROOT221 Environment Variable on Execution Nodes

To avoid job script errors, it is recommended that you set the AWP_ROOT221 environment variable on
all execution nodes.
Run the following command from the head node:

REM Share the installation directory so that compute nodes can use it, replacing the share name
REM "AnsysInc221" with the share you want to use and the v221 installation path shown with
REM that of your actual R19 installation directory
net share "AnsysInc221"="C:\AnsysInstalls_R221" /grant:everyone,full
REM Set AWP_ROOT221 on all nodes so that they can use the shared installation, replacing the share name
REM "AnsysInc221" and install root directory "v221" with your actual share and installation root directory
clusrun setx AWP_ROOT221 "\\%COMPUTERNAME%\AnsysInc221\v221" /M
Integrating RSM with a Cloud Portal
5.3. Integrating RSM with a Cloud Portal

You can configure RSM to submit jobs to a third-party Cloud. However, this type of configuration is
currently outside the scope of this guide, and should be completed with the assistance of Ansys Cus-
tomer Support.
You will need to create a configuration for Cloud portal job submission using the RSM Configuration
application. For more information, refer to Defining RSM Configurations (p. 33).
To enable portal job submission on a client machine, the configuration must reside in the default RSM
configuration directory on the client machine. Or, the RSM configuration directory on the client machine
must be set to a shared directory that contains the necessary configuration. See Sharing and Accessing
RSM Configurations (p. 54).
Chapter 6: RSM User Accounts and Passwords
RSM needs to acquire and cache your credentials to be able to submit jobs to an HPC resource on your
behalf. RSM's direct integration with Ansys applications and built-in caching capability automates this
process to a great extent, and eliminates the need to manually define user accounts in RSM.
Each user account is associated with a specific configuration defined in RSM, and therefore tied to the
RSM queues defined in the configuration. In addition to auto-account creation, you can create a user
account directly in RSM, and apply the account to an RSM configuration.
When you submit a job to RSM from Workbench for the first time, RSM will prompt you to specify cre-
dentials for accessing the HPC resource associated with the chosen RSM queue. RSM will validate and
cache the credentials, and there will be no need to specify credentials again unless your password
changes. See Credential Caching from Workbench (p. 132).
Important:
For improved account security, passwords are always cached on the client machine, even if
jobs will be submitted to a remote resource.
The following topics are discussed in this section:

6.1. Automatic Account Creation
6.2. Adding a User Account
6.3. Changing an Account Password
6.4. Deleting a User Account
6.5. Manually Running the Password Application
6.1. Automatic Account Creation

When you submit a job to RSM from a client application such as Workbench, you select an RSM queue
for the job. Each RSM queue is associated with a configuration defined in RSM, and each configuration
has user accounts associated with it. When an RSM queue is selected in the client application, RSM pre-
validates the account credentials associated with that queue. If credentials have not yet been cached
in RSM, RSM will prompt you to specify them, and cache them for future job submission.
The way in which credentials are specified in client applications differs depending on the application.
Refer to the following:
6.1.1. Credential Caching from Workbench
RSM User Accounts and Passwords
6.1.1. Credential Caching from Workbench

If you submit a job to RSM from Workbench, and credentials have not yet been cached for the RSM
queue in RSM, or the cached password does not validate because your OS password has changed or
expired, you will be prompted to specify credentials for that queue:
If your credentials validate, the job will be submitted to the cluster or Cloud portal. If the credentials
do not validate, the job will be aborted.
6.2. Adding a User Account

Since RSM requests, validates and caches your credentials when you first submit a job to RSM, it is
generally unnecessary to manually create user accounts in RSM. If you would prefer to cache your
password in advance of submitting jobs to RSM (for example, if you want to run a Workbench job in
batch mode), you can add an account in RSM that contains the credentials necessary to access the HPC
resource, and apply the account to the RSM configuration that is associated with that HPC resource.
To add a user account:
1. In the left pane, select Credentials.
2. In the right pane, click on the toolbar, or right-click and select Add Account.
3. In the Adding Account dialog box, specify the user name and password that will be used to submit
jobs the HPC resource, then verify the password. If jobs will be submitted to a Windows machine,
ensure that you include the Windows domain when specifying the user name.
Adding a User Account
Note:
• The password cannot contain special characters, or characters with special marks such
as accents.
• If a domain is specified, it will be automatically dropped if jobs are submitted to a

Linux cluster.
4. Click OK to add the account to the Accounts list.
5. In the Apply to panel, select the cluster configuration that will use this account:
RSM User Accounts and Passwords
6.3. Changing an Account Password

If your account password has changed outside of RSM, your cached credentials will fail to validate when
you submit a job to RSM. The password cached in RSM must be updated.
If you are working in Workbench, RSM will automatically prompt you to specify updated credentials, as
shown in Credential Caching from Workbench (p. 132). Once you specify your new password, the creden-
tials cached in RSM will be updated.
You can also update your account password directly in RSM if needed.
To change an account password:
2. In the right pane, select the account in the Accounts list.
3. Click , or right-click and select Change Password.
4. In the Changing Password dialog box, the User Name field will be auto-populated with the DO-
MAIN\username of the selected account. Enter and verify the new password.
5. Click OK.
Note:
It is also possible to run the RSM password application manually. For details, see Manually
Running the Password Application (p. 135).
6.4. Deleting a User Account

To delete a user account in RSM:
Manually Running the Password Application
2. In the right pane, select the account in the Accounts list.
3. Click , or right-click and select Delete Account.
6.5. 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 applic-
ation on a Linux machine if the terminal used to start the RSM user interface is not available. Or, you
may want to cache credentials for a job account to be used for running jobs in batch mode, without
having to launch RSM.
You can use the RSM Utilities application to run the password application. For more information see
Managing Credentials for RSM Queues (rsm.exe creds) (p. 148).
Chapter 7: RSM Settings and Utilities
The following sections describe actions or settings that control RSM behavior, and provide an overview
of the commands available in the RSM utilities application:
7.1. Specifying the Job Cleanup Period
7.2. Performing Administrative Tasks with the RSM Utilities Application
7.3. Refreshing the View
7.1. Specifying the Job Cleanup Period

Once a job has been released by the client, it will be left in RSM's job history for a certain amount of
time before it is garbage collected and cleaned up. During this interval you can still view the job's status
and details, and save a job report for debugging purposes. However, since the job is done and has
been released, you should not try to perform any more job-related actions prior to cleanup (such as
requesting output files or aborting the job).
Clearing out jobs in a timely manner improves the performance of RSM and optimizes memory usage.
Default job cleanup 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)
To edit the job cleanup period:
1. Select Settings in the left pane.
2. In the Job Cleanup Period pane, specify the desired time period for each job status. The following
values are acceptable:
• D (days) = integer indicating the number of days
• H (hours) = 0–23
• MM (minutes) = 0–59
• SS (seconds) = 0–59
You can enter only the number of days (without the zeros), only the hours/minutes/seconds, or
both.
Examples:
RSM Settings and Utilities
• 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
7.2. Performing Administrative Tasks with the RSM Utilities Application

Sometimes it is more convenient to work with RSM manually, rather than via the user interface. The
RSM Utilities application enables you to conveniently perform a number of administration and config-
uration tasks via the command line.
For Windows, you can start the RSM Utilities application by opening a command prompt in the
[RSMInstall]\bin directory and running rsm.exe.
For Linux, you can start the RSM Utilities application by running the rsmutils shell script, located in
the [RSMInstall]/Config/tools/linux directory.
Note:
The Linux shell scripts are dependent on their relative location in the Ansys Workbench in-
stallation, so cannot be moved.
The commands shown below can be used on both Windows and Linux:
Usage: rsm.exe xmlrpc|config|appsettings|creds|migration [operator] [options] [arguments]
Where:
xmlrpc {operator} [options]: XmlRpc configuration commands.
config {operator} [options]: Configuration related commands.
appsettings {operator} [options] [arguments]: Appsetting related commands.
creds {operator} [arguments]: Credentials related commands.
migration {operator} [arguments]: Migrate from previous version (e.g. v180).
In this section:
7.2.1. Managing RSM Configurations and Queues (rsm.exe | rsmutils config)
7.2.2. Editing RSM Application Settings (rsm.exe | rsmutils appsettings)
7.2.3. Managing Credentials for RSM Queues (rsm.exe creds)
7.2.4. Migrating RSM from a Previous Version
7.2.1. Managing RSM Configurations and Queues (rsm.exe | rsmutils config)

Using the RSM Utilities application you can manually create, delete and list configurations and queues.
A configuration contains information about the HPC resource to which jobs will be submitted, and
how RSM will work with the resource.
RSM queues are the queues that users will see in client applications when submitting jobs to RSM.
Each RSM queue maps to an HPC queue and configuration.
Performing Administrative Tasks with the RSM Utilities Application
7.2.1.1. Creating an RSM Configuration

The RSM Utilities application provides a way of manually creating an RSM configuration. For inform-
ation on creating a configuration using the RSM Configuration application, and the settings specified
in a configuration, see Specifying RSM Configuration Settings (p. 35).
Configurations are saved to .rsmcc files in the RSM configuration directory. To determine the
location of this directory, refer to Specifying a Directory for RSM Configuration Files (p. 147).
To manually create a configuration, run the appropriate command below, appending options from
the accompanying table to specify configuration settings:
rsm.exe config create cluster -type [hpc type]
rsmutils config create cluster -type [hpc type]
For the [hpc type], specify one of the following to create a configuration for that HPC type: default
(see Example 7.1: Default Ansys RSM Cluster (ARC) Configuration (p. 140)), ARC | LSF | PBS | SLURM
| SGE | UGE | MSHPC.
Table 7.1: Options for Creating an RSM Configuration
Option (Windows | Usage

Linux)
-name | -n name The name of the configuration as it appears in the list of configurations.
Defaults to the specified HPC type.
-rsmQueue | -rq name The name of the RSM queue with which this configuration and the HPC
queue will be associated. Defaults to the name of the HPC queue.
-clusterQueue | -cq The name of the HPC queue to which the RSM queue and configuration
name will map. Required except for Ansys RSM Cluster (ARC) and Microsoft HPC
(MSHPC) configurations.
-submitHost | -sh The machine name of the cluster submit host. Defaults to 'localhost'.
machine
-sshAccount|-ssh If SSH will be used for communication between a Windows RSM client
account and a Linux cluster submit host, this specifies the account to use on the
remote SSH submit host. Password-less SSH is required.
-platform | -p win | lin The platform of the cluster submit host (Windows or Linux). This is always
required.
-transferType | -tt NO | Specify how files will get to the HPC staging directory.
RSM | OS | SCP
NO = No file transfer needed. Client files will already be in an HPC
staging directory.
RSM = RSM uses TCP sockets to stream files from the client machine
to the submit host. Use when the HPC staging directory is in a remote
location that is not visible to client machines.
Option (Windows | Usage

Linux)
OS = RSM finds the HPC staging directory via a Windows network
share or Linux mount point, and copies files to it using the built-in
operating system copy commands. Use when the HPC staging
directory is a shared location that client machines can access.
SCP = SSH/SCP will be used to transfer files from the client machine
to the submit host.
-stagingDir | -sd path The HPC staging directory as the RSM client sees it. A Windows client will
see the shared file system as a UNC path (for example, \\machine\shar-
eName). A Linux client may mount the HPC staging directory such that
the path appears different than it does on the cluster (for example,
/mounts/cluster1/staging). Leave empty if using the
no-file-transfer method.
-stagingMapDirs | The path to the shared file system as the cluster sees it (for example,
-sdmap path;path;... /staging on a Linux machine). This maps the client-visible path
to the cluster-visible path. For example, the Windows client sees
\\machine\STAGING which is a Linux Samba share of /staging.
Multiple paths are only supported when all of the following are true:
• The submit host is not 'localhost'
• The submit host platform is Linux
• SSH is not being used
• You have specified that no file transfer is needed
-localScratch | -ls path Local scratch path if jobs will run in a scratch directory local to the
execution node. Leave empty to run jobs in the HPC staging directory.
-scratchUnc | -su path (Windows clusters only): UNC share path of -localScratch path not
including the '\\machine\' portion.
-peSmp | -ps name (UGE/SGE only): Parallel Environment (PE) names for Shared Memory
Parallel. If not specified, default will be 'pe_smp'.
-peMpi | -pm name (UGE/SGE only): Parallel Environment (PE) names for Distributed Parallel.
If not specified, default will be 'pe_mpi'.
-noCleanup | -nc Keep job files in the HPC staging directory after the job has run.
Use the examples below as a guide when generating configuration files.
Example 7.1: Default Ansys RSM Cluster (ARC) Configuration
The default Ansys RSM Cluster (ARC) configuration is used to submit jobs to the local machine (on
which the RSM configuration resides). Every RSM installation has a basic ARC cluster already con-
figured.
Running the command rsm.exe | rsmutils config create cluster -type default
is the equivalent of running rsm.exe | rsmutils config create cluster -type
ARC -name localhost -rq Local, where the name of the RSM configuration is localhost,
and the RSM queue that is associated with this configuration is named Local.
A file named LOCALHOST.rsmcc is generated that contains the following settings:

<?xml version="1.0" encoding="utf-8"?>
<ClusterConfiguration version="2">
<name>localhost</name>
<type>ARC</type>
<machine>localhost</machine>
<submitHostPlatform>AllWindows</submitHostPlatform>
<stagingDirectory />
<networkStagingDirectory />
<localScratchDirectory />
<fileCopyOption>None</fileCopyOption>
<nativeSubmitOptions />
<useSsh>False</useSsh>
<sshAccount />
<useSshForLinuxMpi>True</useSshForLinuxMpi>
<deleteStagingDirectory>True</deleteStagingDirectory>
<readonly>False</readonly>
</ClusterConfiguration>
Example 7.2: LSF on Linux (Jobs Use Local Scratch Directory)
To configure RSM to use an LSF queue, and run jobs in the local scratch directory, you would run
the following command:
rsmutils config create cluster -type LSF -name LSFSCRATCH -submitHost

lsfheadnode -platform lin -localScratch /rsmtmp -rsmQueue LSF-SCRATCH
-clusterQueue normal
The following arguments are used in this example:
• LSF = cluster type is LSF
• -name LSFSCRATCH = configuration name will be LSFSCRATCH
• -submitHost lsfheadnode = machine name of LSF cluster head node is lsfheadnode
• -platform lin = platform of cluster submit host is Linux
• -localScratch /rsmtmp = jobs will run in a local scratch directory /rsmtmp
• -rsmQueue LSF-SCRATCH = RSM queue name will be LSF-SCRATCH
• -clusterQueue normal = LSF cluster queue name is normal
An LSFSCRATCH.rsmcc file is created which contains the following settings:

<name>LSFSCRATCH</name>
<type>LSF</type>
<machine>lsfheadnode</machine>
<submitHostPlatform>AllLinux</submitHostPlatform>
<localScratchDirectory>/rsmtemp</localScratchDirectory>
<sshAccount />
In this example, an RSM queue name (LSF-SCRATCH) is specified. This will be the queue name
displayed in client applications. If an RSM queue name is not included in the command line (for
example, -rsmQueue LSF-SCRATCH), the actual cluster queue name will be displayed instead.
If you were to open the queues.rsmq file, you would see the LSF-SCRATCH queue added there:
<Queues>
<Queue version="1">
<name>LSF-SCRATCH</name>
<clusterConfigurationName>LSFSCRATCH</clusterConfigurationName>
<clusterQueueName>normal</clusterQueueName>
<enabled>True</enabled>
</Queue>
</Queues>
The clusterConfigurationName value, LSFSCRATCH in this example, is what links the queue
to the actual RSM configuration.
Example 7.3: SGE on Linux (Jobs Use Cluster Staging Directory)
2 cluster queues: all.q and sgeshare1
In the RSM client, the SGE queue sgeshare1 is referred to as SGE_SHARE. all.q is not aliased
and is referred to as all.q.
Local scratch setup: Jobs submitted to RSM all.q queue will run in a local scratch folder /rsmtmp.
rsmutils config create cluster -type UGE -name SGELOCAL -localScratch

/rsmtmp -peMpi myPE -clusterQueue all.q
No local scratch. Jobs submitted to RSM’s SGE_SHARE queue will run in shared cluster staging
directory.
rsmutils config create cluster -type SGE -name SGESHARE -peSmp myPE
-clusterQueue sgeshare1 -rsmQueue SGE_SHARE
Note that you can specify UGE or SGE for config create. They are the same.
Example 7.4: Microsoft Windows HPC on Windows Server 2012
HPC does not define named queues.
We define 2 queues in RSM: HPC-LOCAL and HPC-SHARE.
Local scratch setup. Jobs submitted to RSM’s HPC-SCRATCH queue will run in a local scratch folder
C:\RSMTemp. Note that the cluster nodes will all share this folder as \\[Execution-
Node]\RSMTemp.
rsm.exe config create cluster -type MSHPC -name HPCSCRATCH -loc-

alscratch C:\RSMTemp -scratchUnc RSMTemp -rsmQueue HPC-SCRATCH
No local scratch. Jobs submitted to RSM’s HPC-SHARE queue will run in shared cluster staging
directory.
rsm.exe config create cluster -type MSHPC -name HPCSHARE -rsmQueue

HPC-SHARE
7.2.1.2. Deleting a Configuration

To delete a configuration from the RSM configuration directory:
rsm.exe config delete -clusterconfig |- cc clusterConfigurationName
rsmutils config delete -clusterconfig |- cc clusterConfigurationName
7.2.1.3. Creating an RSM Queue

When creating an RSM queue you must associate the queue with an HPC queue. The RSM queue
is what users see in client applications such as Workbench. The HPC queue is defined on the HPC
side (for example, on the cluster submit host).
To create an RSM queue:
rsm.exe config create queue -name queueName -clusterconfig clusterCon-

figurationName -clusterQueue clusterQueueName
rsmutils config create queue -n queueName -cc clusterConfigurationName

-cq clusterQueueName
7.2.1.4. Deleting an RSM Queue

To delete an RSM queue:
rsm.exe config delete -rsmqueue | -rq rsmQueueName
rsmutils config delete -rsmqueue | -rq rsmQueueName
7.2.1.5. Listing RSM Configurations and Queues

The RSM configuration directory contains RSM configurations and queue definitions.
To list RSM configurations and queues:
Windows: Run the following commands in the [RSMInstall]\bin directory:
All configurations: rsm.exe config list
The following is a sample listing:

C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe config list
Configuration location: C:\Users\atester\AppData\Roaming\Ansys\v221\RSM
Queues:
Default [WinHPC Cluster, Default]
High_mem [ARC, high_mem]
LM-WinHPC [WinHPC, LM]
LSF-SCRATCH [LSFSCRATCH, normal]
Local [localhost, local]
XLM-WinHPC [WinHPC, XLM]
Configurations:
ARC
localhost
LSFSCRATCH
WinHPC
Specific configuration: rsm.exe config list -cc ConfigurationName
The following is a sample listing:

C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe config list -cc LSFSCRATCH
Configuration location: C:\Users\atester\AppData\Roaming\Ansys\v221\RSM
Showing single configuration LSFSCRATCH
Queues:
LSF-SCRATCH [LSFSCRATCH, normal]
<name>LSFSCRATCH</name>
<type>LSF</type>
<machine>lsfheadnode</machine>
<submitHostPlatform>allLinux</submitHostPlatform>
<localScratchDirectory>/rsmtmp</localScratchDirectory>
<sshAccount />
Linux: Run the following commands in the [RSMInstall]/Config/tools/linux directory:
All configurations: rsmutils config list
Specific configuration: rsmutils config list -cc clusterConfigurationName
7.2.2. Editing RSM Application Settings (rsm.exe | rsmutils appsettings)

You can use the RSM Utilities application to query or edit any setting in the RSM\Con-
The appsettings command has two possible operators: get (for querying) and set (for editing).
To query or edit a setting in the Ans.Rsm.AppSettings.config file, you must know the name
of the section in which the setting is located (SectionName), and the name of the setting (SettingName).
In the following excerpt from the Ans.Rsm.AppSettings.config file, the SectionName is
Global, and the first SettingName is DiskSpaceLowWarningLimitGb:
<appSettings name="Global">
<add key="DiskSpaceLowWarningLimitGb" value="2.0" />
<add key="IdleTimeoutMinutes" value="10" />
<add key="PingServerTimeout" value="3000" />
<add key="PingServerMaxRetries" value="4" />
<add key="PortInUseTimeout" value="5000" />
<add key="RemotingSecureAttribute" value="false" />
<add key="EnablePerformanceLogging" value="false" />
Important:
If you edit settings in the Ans.Rsm.AppSettings.config file, you may need to restart
RSM services in order for the changes to take effect.
Windows:
To query a setting, run the following command in the [RSMInstall]\bin directory:
rsm.exe appsettings get SectionName SettingName
To edit a setting, run the following command in the [RSMInstall]\bin directory:
rsm.exe appsettings set SectionName SettingName Value
Linux:
To query a setting, run the following command in the [RSMInstall]/Config/tools/linux
directory:
rsmutils appsettings get SectionName SettingName
To edit a setting, run the following command in the [RSMInstall]/Config/tools/linux dir-

ectory:
rsmutils appsettings set SectionName SettingName Value
Examples
The appsettings command is used in the following sections in this user's guide:
• Configuring a Computer with Multiple Network Interface Cards (NICs) (p. 60)
• Dealing with a Firewall in a Multi-Node Ansys RSM Cluster (ARC) (p. 103)
Additional examples include:

7.2.2.1. Specifying a Port Range for User Proxy Processes
7.2.2.2. Specifying a Port Range for User Proxy Socket File Transfers
7.2.2.3. Specifying a Directory for RSM Configuration Files
7.2.2.1. Specifying a Port Range for User Proxy Processes

When the cluster submit host is a remote machine, the RSM launcher service launches a user proxy
process on the submit host which performs operations such as job submission, monitoring, and
file transfer on the user's behalf. This means that there is a separate proxy process created for every
user who submits a job to RSM. Each user proxy process will use a separate port chosen by RSM.
By default, RSM will randomly select a port that is free from the 1000-2000 range. If you want to
control which ports RSM can choose, you can specify a port range using the RSM Utilities application,
which modifies the user proxy PortRange value in the RSM\Config\Ans.Rsm.AppSet-
tings.config file.
To specify a port range for user proxy processes:
rsm.exe appsettings set UserProxy PortRange <PortRange>
rsmutils appsettings set UserProxy PortRange <PortRange>
For example, to set a port range of 2000-9000, you would enter the following:
appsettings set UserProxy PortRange 2000-9000
7.2.2.2. Specifying a Port Range for User Proxy Socket File Transfers
When the cluster submit host is a remote machine, the RSM launcher service launches a user proxy
process on the submit host which transfers files to the cluster on the user's behalf. When this occurs,
a port is opened for each file being transferred. By default, RSM will randomly select a port that is
free. If you want to control which ports RSM can choose, you can specify a port range using the
RSM Utilities application, which modifies the user proxy SocketTransfererPortRange value
in the RSM\Config\Ans.Rsm.AppSettings.config file.
To specify a port range for socket file transfers:
rsm.exe appsettings set UserProxy SocketTransfererPortRange <PortRange>
rsmutils appsettings set UserProxy SocketTransfererPortRange <PortRange>
7.2.2.3. Specifying a Directory for RSM Configuration Files

By default, the directory in which RSM configurations are stored resolves to %APPDATA%\AN-
SYS\v221\RSM on Windows or ~/.ansys/v221/RSM on Linux, where ~ is the home directory
of the account under which RSM is being run. When you submit a job in a client application, RSM
reads the configuration files in this directory to acquire information about the HPC resource and
determine how the job will be submitted to that resource.
Since the default directory is associated with a specific user account, it may not be an appropriate
directory for storing configuration files if you plan to share the directory with other users. For more
information, see Sharing and Accessing RSM Configurations (p. 54).
You can change this to a different directory using the RSM Utilities application (p. 138), or by editing
the RSM\Config\Ans.Rsm.AppSettings.config file.
In this section:
7.2.2.3.1. Querying the Location of the RSM Configuration Directory
7.2.2.3.2. Specifying the Location of the RSM Configuration Directory
7.2.2.3.1. Querying the Location of the RSM Configuration Directory

You can use the RSM Utilities application to determine which directory is currently set as the RSM
configuration directory. The directory is also listed in the ConfigurationDirectory setting
in the RSM\Config\Ans.Rsm.AppSettings.config file.
To query the location of the RSM configuration directory:
rsm.exe appsettings get JobManagement ConfigurationDirectory
rsmutils appsettings get JobManagement ConfigurationDirectory
7.2.2.3.2. Specifying the Location of the RSM Configuration Directory

You can use the RSM Utilities application to change the directory in which RSM configurations
will be saved when you generate them. The directory that you specify will populate the Config-
urationDirectory setting in the RSM\Config\Ans.Rsm.AppSettings.config file.
If you want to share RSM configurations with other users you can make the chosen configuration
directory a shared directory so that users can retrieve configurations from it. Users can then map
or mount the shared directory on their local machines and point their ConfigurationDirect-
ory setting to it using the same steps presented in this section.
Follow the appropriate set of instructions below to change the RSM configuration directory.
Windows
1. If the RSM launcher service is currently running, stop it. As an administrator, run net stop

c:\some\folder
You can specify a local path if the directory is on the local machine, or a UNC path if the
directory is a network share.
Note that RSM will add the required sub-folders ANSYS\v221\RSM to the specified folder
if they do not already exist (for example, if you specified the path c:\some\folder). Any
new configurations that you create will be saved to this sub-location (for example,
C:\some\folder\ANSYS\v221\RSM). This should also be your target location if you are
copying existing configuration files from another source.
Linux
1. If the RSM launcher service is currently running, run [RSMInstall]/RSM/Con-

fig/tools/linux/rsmlauncher stop.
2. Run the rsmutils shell script located in the [RSMInstall]/Config/tools/linux

directory. Issue the following command, replacing the path with the desired value:

/some/folder
You can specify a local path, UNC path on Windows, or mounted file system on Linux de-
pending on where the directory resides.
Note that RSM will add the sub-folders ANSYS/v221/RSM to the specified folder if they do
not already exist (for example, if you specified the path /some/folder). Any new config-
urations that you create will be saved to this sub-location (for example,
/some/folder/ANSYS/v221/RSM). This should also be your target location if you are
copying existing configuration files from another source.
7.2.3. Managing Credentials for RSM Queues (rsm.exe creds)

You can use the RSM Utilities application to manually cache credentials that you want to use when
submitting jobs to RSM queues, as well as validate and list accounts. For general information about
credential caching and setting up accounts using the RSM Configuration application, see RSM-Sup-
ported Applications and Solvers (p. 16).
The following arguments are used with operators of the creds command:
Table 7.2: Arguments Used for Managing Credentials
Argument Usage
-a Account name to be used for job submission to RSM queue. The default is the current
account account.
-rq The RSM queue to which the credentials will be applied. For caching, the default is all
queue queues.
Argument Usage
-l Launch UserProxy after validation. (Validation only)
Refer to the table above when performing the following tasks:

7.2.3.1. Caching Credentials for an RSM Queue
7.2.3.2. Validating Credentials for an RSM Queue
7.2.3.3. Listing the RSM Configurations Associated with an Account
7.2.3.4. Listing the Accounts Associated with an RSM Queue
7.2.3.1. Caching Credentials for an RSM Queue

Any user can cache their credentials for an RSM queue. Password caching must be done from the
client machine.
Refer to Table 7.2: Arguments Used for Managing Credentials (p. 148) when running the caching
command.
To cache credentials:
rsm.exe creds c[ache] -a account -rq queue
rsmutils creds c[ache] -a account -rq queue
When you run the caching command, you will be prompted for the password. For example:
C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe creds cache -a ANSYS\atester -rq LSF-SCRATCH
Caching password for: ANSYS\atester
Enter password:
7.2.3.2. Validating Credentials for an RSM Queue

You can run a validation command to test whether or not the credentials cached for an RSM queue
are valid. Refer to Table 7.2: Arguments Used for Managing Credentials (p. 148) when running the
validation command.
To validate RSM queue credentials:
rsm.exe creds v[alidate] -rq queue [-l]
rsmutils creds v[alidate] -rq queue [-l]
Below is a sample validation:

C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe creds v -rq LSF-SCRATCH
Credentials are valid for target Queue (or not needed).
7.2.3.3. Listing the RSM Configurations Associated with an Account

To list the RSM configurations to which an account's cached credentials resolve:
rsm.exe creds l[ist] -a account
Windows: Run the following command in the [RSMInstall]/Config/tools/linux directory:
rsmutils creds l[ist] -a account
Below is a sample listing for an account:

C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe creds l -a ANSYS\atester
Credentials cached for Account ANSYS\atester resolve to these destinations:
LSF Cluster
7.2.3.4. Listing the Accounts Associated with an RSM Queue

To list the accounts that have been applied to an RSM queue:
rsm.exe creds l[ist] -rq queue
rsmutils creds l[ist] -rq queue
Below is a sample listing for an RSM queue:

C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe creds l -rq HPC-SCRATCH
Credentials cached for Cluster Configuration MSHPC as:
ANSYS\user1
7.2.4. Migrating RSM from a Previous Version

RSM's built-in migration utility enables you to automatically transfer RSM configurations, queue
definitions and application settings from one version of RSM to another, eliminating the need to re-
configure RSM or manually move files every time you upgrade to a new version. You can choose to
migrate all items, or specific items.
Important:
• The migration utility supports migration from version 18.0 or later.
• If you have previously set up a custom Ansys RSM Cluster (ARC), and would like to migrate
ARC-related settings and ARC node configurations, you will need to run the ARC migration
command in addition to running the RSM migration utility described here. For more in-
formation see Migrating an ARC Setup from a Previous Version (arcconfig migra-
tion) (p. 100).
To perform a migration:
1. On the cluster submit host, log into an account with administrative privileges.
2. If you have not already done so, install the new product version.
3. Run the appropriate command below, appending the desired operator and options from the
accompanying tables.
rsm.exe migration {operator} -v123 [-preview] [-verbose] [-silent]
rsmutils migration {operator} -v123 [-preview] [-verbose] [-silent]
Table 7.3: Operators for Migration
Operator Usage
config Migrate RSM configurations and queues.
settings Migrate RSM settings in the RSM\Con-
(To see which settings will be migrated, refer to
the new version's RSM\Config\migra-
tion\Rsm.AppSettings.Migrate.con-
fig file.)
all Migrate everything (configurations, queues, and
settings).
Table 7.4: Options for Migration
Option Usage
-v123 (Required) Specify the version that you are
migrating, so that the migration command
knows which files to look for. Replace the 123
with the version that you are migrating (for
example, enter -v212 for version 2021 R2).
Note:
The oldest version that you can

migrate is version 18.0.
-preview Display a list of the items that will be migrated,

without actually performing the migration.
-verbose Display more detailed information about the
migration and its progress.
-silent Perform the migration without confirmation
prompts. Useful for scripting.
Example
In the following example we are migrating cluster configurations, queues and settings from version
18.0 to version 2022 R1.
By using the -preview option we can see that 4 configurations, 8 queues and 1 setting will be migrated:
C:\Program Files\ANSYS Inc\v221\RSM\bin>rsm.exe migration all -v212 -preview -verbose
v221 configuration directory: C:\Users\atester\AppData\Roaming\Ansys\v221\RSM

v212 configuration directory: C:\Users\atester\AppData\Roaming\Ansys\v212\RSM
v221 existing configuration:

1 Cluster Configurations
localhost
1 Queues
Local
NOTE: Existing Cluster Configurations and Queues may be overwritten.
v212 configuration to migrate:

4 Cluster Configurations
localhost
Custom
WinHPC
LSF
8 Queues
Normal
HighMem
Local
Reserved
Mech-HPC
Fluent-HPC
CFX-HPC
Test-LSF

Settings to migrate located at C:\Program Files\ANSYS Inc\v221\RSM\Config\migration\Rsm.AppSettings.Migrate.config
Skipping DiskSpaceLowWarningLimitGb = 2.0

Skipping ServiceLogCleanupAgeDays = 5
Skipping AlternateAllowedPrompt = empty
Skipping LauncherXmlRpcEnabled = true
Skipping XmlRpcMaxConcurrentRequests = 10
Skipping ProxyXmlRpcPortRange = 50000-50100
Skipping ProxyXmlRpcLogMessagePrefix = [P]
Skipping CompressionThresholdMb = 0
Skipping CleanupTimeSpan = 00:10:00
Skipping FinishedJobHistoryCleanupTimeSpan = 02:00:00
Skipping FailedJobHistoryCleanupTimeSpan = 1.00:00:00
Skipping CancelJobHistoryCleanupTimeSpan = 00:10:00
Skipping JobHistoryCleanupIntervalTimeSpan = 00:10:00
Skipping ConfigurationDirectory = empty
Skipping JobHistoryDirectory = empty
Skipping IdleTimeoutMinutes = 10
Migrating PortRange from empty to 2000-9000
Skipping NumberPortsPerUser = 10
Skipping SocketTransfererPortRange = empty
Skipping SocketTransfererListenerIpAddress = empty
Skipping DirectoryPermissionMask = empty
Skipping FilePermissionMask = empty
Skipping UserProxyShareName = RSM
Skipping FileTransferBufferSize = 100000
Skipping FileTransferMaxRetries = 1
Skipping ServiceLogEnabled = true
Refreshing the View

Skipping ServiceLogEnabled = false
Skipping Configuration.EnableClusterQueueEdit = true
Skipping EnableRsmLocale = false
Skipping EnableUTF8Encoding = false
Skipping EnableRsmLocale = false
Skipping EnableUTF8Encoding = false
1 settings to migrate.
C:\Program Files\ANSYS Inc\v221\RSM\bin>
Note:
If a configuration, queue or setting already exists in the new version, and the content or
value is different in the new version, that item will be overwritten. Otherwise, if the content
or value is the same, migration of that item will be skipped.
To verify that configurations and queues have been successfully migrated, you can issue the config
list (p. 144) command, as described in Listing RSM Configurations and Queues (p. 144), or simply open
the RSM Configuration application and review the configurations in the HPC Resources list. To verify
that settings have been migrated, refer to Editing RSM Application Settings (rsm.exe | rsmutils
appsettings) (p. 145).
7.3. Refreshing the View

If RSM configuration files have been modified outside of the RSM Configuration application, you can
load the updated content into the application by refreshing the view.
To refresh the view, select View > Refresh.
When the view is refreshed, the following items are updated in the application window:
• List of configurations in the left pane
• List of queues on the Queues tab
• The Status of queue tests on the Queues tab
Chapter 8: RSM Custom Integration
This section discusses various methods of customizing Ansys Remote Solve Manager.
The following topics are addressed:

8.1. Understanding RSM Custom Architecture
8.2. Custom Cluster Integration Setup
8.3. Writing Custom Code for RSM Integration
8.1. Understanding RSM Custom Architecture

The [RSMInstall]\Config directory contains job templates, job scripts, and other files that are
used to define and control RSM jobs. The RSM architecture allows you to customize how jobs are executed
on a cluster by providing a custom version of some of the files.
This section briefly describes the types of files used in the customization:
8.1.1. Job Templates
8.1.2. Job Scripts
8.1.3. HPC Commands File
8.1.4. Job Configuration File
8.1.1. Job Templates

Job Templates define additional inputs and outputs that were not specified by the client at the time
of job submission. This enables you to execute customized workflows. For example, you may want
to include a custom user-generated results file for retrieval at the end 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 Work-
bench_CFXJob.xml.
An example of a job template for a server test job is shown below:

<?xml version="1.0"?>
<jobTemplate>
<script>GenericJobCode.xml</script>
<debug>FALSE</debug>
<cleanup>TRUE</cleanup>
<inputs>
<file>commands.xml</file>
<file>*.in</file>
</inputs>
<outputs>
<file>*</file> 
<file special="inquire">*.out</file>
</outputs>
</jobTemplate>
RSM Custom Integration
8.1.2. Job Scripts

Job Scripts are simply shell scripts that define commands and variables for different types of HPC
jobs. They enable you to customize HPC job behavior.
RSM job script files are located in the [RSMInstall]\Config\scripts directory. There is a set
of script files for each cluster type.
Specialized job scripts for integrating RSM with third-party job schedulers or Cloud portals are invoked
based upon the HPC type property in the RSM configuration:
• For example, if you set the HPC type to LSF, then LSF will be your “keyword”, and RSM will look
in the jobConfiguration.xml file for the corresponding hpc_commands file. It will find
hpc_commands_LSF.xml, which invokes the scripts necessary to run a test job on an LSF cluster.
<keyword name="LSF">
<hpcCommands name="hpc_commands_LSF.xml"/>
</keyword>
• If you set the HPC type to Custom, then “Custom” is not used as the keyword. Rather, the value
that you specify in the Custom HPC type field in the RSM configuration will become your “keyword”,
and you can customize job execution on the cluster by adding a section for your new keyword in
the jobConfiguration.xml file. The section will list the files that you want to apply to the
custom job type.
Understanding RSM Custom Architecture
8.1.3. HPC Commands File

The HPC type-specific HPC commands file is the configuration file used to specify the commands or
queries that will be used in the HPC integration. The file is in xml format and is located in
the [RSMInstall]\Config\xml directory. The default naming scheme is hpc_com-
mands_<hpcType>.xml. When using a custom HPC 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 HPC
type name in the format hpc_commands_<keyword>.xml. This is also discussed in the setup sections
of Custom Cluster Integration Setup (p. 159).
The commands inside the HPC command file can point directly to cluster-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 cluster node. The HPC command file is described in greater detail in Custom
Cluster Integration Setup (p. 159).
8.1.4. 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 HPC 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
• SLURM, SLURMSSH, SLURMSMB
• MSCC
• RSM, RSMSSH, RSMSMB
• ARC, ARCSSH, ARCSMB
• STORAGE_SSH (for file transfers to/from the HPC staging directory using SSH)
The file also contains entries for a Custom Integration Sample (CIS), and various example clusters.
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_exten-
sions_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">
<hpcCommands name="hpc_commands_LSF.xml">
<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 an HPC resource, you will need to modify the
jobConfiguration.xml file, either by editing existing keyword entries or adding new ones for
each custom HPC job type.
Customizing HPC Job Type Entries

If you only want to make small changes to HPC job execution, 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_com-
mands_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 that file is at the top of the list. 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">
<hpcCommands name="MyCustomChanges.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 HPC job execution, or there are different customization re-
quirements 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_CUS-
TOM.xml, as well as the standard hpc_commands_PBS.xml file.
<keyword name="CUSTOM">
<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. 161).
Custom Cluster Integration Setup
8.2. Custom Cluster Integration Setup

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 currently supported
commercial clusters are Linux LSF, Linux PBS Pro, SLURM, Linux UGE (SGE), and Microsoft HPC
(MSCC).
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 you need some additional operation to be performed
as part of the RSM job execution. This is a type of cluster-side integration.
• “Unsupported” clusters, not included in the list above, that you want to use for executing a job via
RSM. This is also a type of cluster-side integration.
• You have 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 cluster-side and client-side integration refer to the location (in the RSM architecture) where
the custom script files are going to be located.
If the RSM client will be submitting jobs to a remote cluster, RSM files will be customized on the cluster
submit host. This is referred to as cluster-side integration. For cluster-side integration, RSM must be
installed on the cluster head node and file transfers should be handled by RSM, using either the internal
RSM transfer mechanism or operating system file transfer to an existing network share. The methods
of file transfer discussed in Setting Up Job Directories and File Transfers (p. 57) are available, except
for Using SSH for File Transfers (p. 61) and Custom Client Integration (p. 61).
If the RSM client is the cluster submit host, RSM files will be customized on the RSM client. This is referred
to as client-side integration. In this scenario, the RSM functionality is completely replaced by the 3rd-
party scripts. 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.
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.
The following sections describe the general steps for customization with cluster-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. 172).
The following topics are addressed:

8.2.1. Customizing Cluster-Side Integration
8.2.2. Customizing Client-Side Integration
8.2.3. Configuring SSH/Custom File Transfers
8.2.1. Customizing Cluster-Side Integration

Cluster-side integration means that you are running in non-SSH mode.
RSM allows you to customize your integration with supported cluster types (LSF, PBS Pro, SLURM,
Windows 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.
When customizing files, you must choose a "keyword" that represents your custom cluster type. This
is a short word or phrase that you will append to the file names of your custom files, and use when
defining an RSM configuration to map the configuration to your custom files. The name is arbitrary,
but you should make it simple enough to append to file names. For example, if you are creating a
customized version of an LSF cluster, your keyword might be "CUS-LSF". The only requirement is that
you consistently use the same capitalization in all places where the keyword is referenced.
For a cluster-side RSM installation, you will need to log into the remote cluster submit host to perform
the following steps:
1. Create a copy of the HPC commands file that most closely matches your custom cluster
type, and replace the keyword with your custom cluster type “keyword” (for example,
hpc_commands_<keyword>.xml).
2. Add an entry to the job configuration file that associates your custom “keyword” with the
cluster-specific hpc_commands_<keyword> file.
3. Edit the cluster-specific hpc_commands_<keyword> file to reference the code that you
want to execute.
4. Create a configuration in RSM which will use your customized files.
The following sections discuss the steps needed for custom cluster-side integration:
8.2.1.1. Creating Copies of Standard Cluster Code Using a Custom Cluster Keyword
8.2.1.2. Modifying the Job Configuration File for a New Cluster Type
8.2.1.3. Modifying the Cluster-Specific HPC Commands File
8.2.1.4. Creating a Configuration for the Custom Cluster
You may also want to refer to the Configuring Custom Cluster-Side Integration tutorial on the Ansys
Help site.
8.2.1.1. Creating Copies of Standard Cluster Code Using a Custom Cluster

Keyword
As part of the setup, you must create an hpc_commands file that includes your custom cluster
“keyword” in its file name. This is an .xml file that contains the definition of the HPC commands
to be used for the job execution. As a starting point, you can create a copy of one of the sample
hpc_commands files that are included in the RSM installation.
Note that all the actions listed below should be performed on the cluster installation.
• Locate the directory [Ansys 2022 R1 Install]/RSM/Config/xml.
• Locate the HPC 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_<hpcType>.xml file into a new file, and name the
new file hpc_commands_<YOURKEYWORD>.xml (where <YOURKEYWORD> is a short word or
phrase that you have chosen to represent the custom cluster type). For example, if your keyword
for the custom cluster is “CUS_PBS”, the new file should be called hpc_com-
mands_CUS_PBS.xml.
Note:
Do not rename or make changes to the standard templates that ship with RSM (LSF, PBS
Pro, and so on). 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 from which to start. This is
the recommended method.
As part of the setup, you must add an entry for your custom cluster keyword in the jobConfig-
uration.xml file, and reference the files that are needed for that cluster job type.
Note that all the actions listed below should be performed on the cluster installation.
• Locate the directory [Ansys 2022 R1 Install]/RSM/Config/xml.
• 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 as-
sumes your cluster is most like a PBS cluster.
<keyword name="YOURKEYWORD">
<hpcCommands name="hpc_commands_YOURKEYWORD.xml">
</hpcCommands>
</keyword>

An excerpt of 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.
<submit>
<precommands>
<command name="memory">
<properties>
<property name="MustRemainLocal">true</property>
</properties>
<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>
</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>
</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>
<postcommands>
<command name="parseSubmit">
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/pbsParsing.py</pythonapp>
</application>
<arguments>
<arg>-submit</arg>
<arg>
<value>%RSM_HPC_PARSE_MARKER%</value>
<condition>
<env name="RSM_HPC_PARSE_MARKER">ANY_VALUE</env>
</condition>
</arg>
</arguments>
<outputs>
<variableName>RSM_HPC_OUTPUT_JOBID</variableName>
</outputs>
</command>
</postcommands>
</submit>
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 argu-
ments 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. 176).
The example below shows the same section after it is customized to execute the Python file sub-
mit_PBS_EXAMPLE.py. In this example, we defined the type of application to execute (runpy-
thon, accessed from the Ansys installation) and the name of the Python file to be executed (sub-
mit_PBS_EXAMPLE.py).
<submit>
<properties>
</properties>
<application>
<app>%AWP_ROOT221%/commonfiles/CPython/2_7_13/linx64/Release/runpython</app>
</application>
<arguments>
<arg>
<value>%RSM_HPC_SCRIPTS_DIRECTORY%/submit_PBS_EXAMPLE.py</value>
</arg>
</arguments>
</primaryCommand>
<postcommands>
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/pbsParsing.py</pythonapp>
</application>
<arguments>
<arg>-submit</arg>
<arg>
<condition>
</condition>
</arg>
</arguments>
<outputs>
</outputs>
</command>
</postcommands>
</submit>
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/Con-

fig/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/Con-
fig/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 ex-
ecuted 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. 172).

When creating a configuration for a custom cluster in RSM, you must set the HPC type to Custom
and specify your custom cluster keyword in the Custom HPC type field.
A “custom HPC integration” means that you are running in non-SSH mode (RSM is able to commu-
nicate directly with the cluster). Therefore, when specifying how the client communicates with the
cluster, you need to select Able to directly submit and monitor HPC jobs.
For the File Management tab, see Specifying File Management Properties (p. 41) for details on
the different file transfer scenarios.
8.2.2. Customizing Client-Side Integration

Client-side integration means that the client is able to communicate directly with the HPC resource
using SSH or a custom communication method.
The mechanism and operations for custom client-side integration are very similar to the ones for
custom cluster-side integration. However, the underlying architecture is different. In the cluster-side
integration, the customization affects the scripts used for RSM execution on the cluster side. In the
client-side integration, only a thin layer of 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. It is the respons-
ibility of the custom scripts to handle all aspects of the job execution, including transfer of files to
and from the HPC staging directory (if needed).
The RSM installation provides some prototype code for client integration that can be tailored and
modified to meet specific customization needs.
When customizing files, you must choose a "keyword" that represents your custom HPC type. This is
a short word or phrase that you will append to the file names of your custom files, and use when
defining a configuration in RSM to map the configuration to your custom files. The name is arbitrary,
but you should make it simple enough to append to file names. For example, if you are creating a
customized version of an LSF cluster, your keyword might be "CUS-LSF". The only requirement is that
you consistently use the same capitalization in all places where the keyword is referenced.
For client-side integration, you will be using the local client machine to perform the following steps:
1. Create a copy of the HPC commands file that most closely matches your custom cluster type,
and replace the keyword with your custom cluster type “keyword” (for example, hpc_com-
mands_<keyword>.xml).
2. Add an entry to the job configuration file that associates your custom cluster “keyword” with
the cluster-specific hpc_commands_<keyword> file.
3. Edit the cluster-specific hpc commands_<keyword> file to reference the custom commands.
4. Provide cluster-specific script\code\commands that perform the custom actions and return the
required RSM output.
Once you have completed the steps above, you can create a configuration in RSM that will use your
customized files.
The following sections discuss the steps to customize your integration:

8.2.2.1. Creating Copies of Sample Code Using a Custom Client Keyword
You may also want to refer to the Configuring Custom Client-Side Integration tutorial on the Ansys
Help site.
8.2.2.1. Creating Copies of Sample Code Using a Custom Client Keyword

As part of the setup, you must create an hpc_commands file that includes your custom cluster
“keyword” in its file name. This is an .xml file that contains the definition of the HPC commands
to be used for the job execution. As a starting point, you can create a copy of one of the sample
hpc_commands files that are included in the RSM installation. You may also want to create copies
of sample command scripts to be used for job execution.
For this example we will use the sample file marked with the suffix CIS (Client Integration Sample),
which is based on integration with an LSF cluster.
Note that all the actions listed below should be performed on the client machine.
1. Using the RSM installation on your client machine, locate the directory [RSMInstall]\Con-
fig\xml.
2. Locate the sample file for command execution hpc_commands_CIS.xml.
3. Copy the content of the hpc_commands_CIS.xml file into a new file, hpc_commands_<YOUR-
KEYWORD>.xml. If, for example, your keyword is “CUS_LSF”, the new file should be called
hpc_commands_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, scp.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, can-
cel_CUS_LSF.py, status_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. 167).
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 jobConfig-
uration.xml file, and reference the files that are needed for that cluster job type.
Note that all the actions listed below should be performed on your client machine.
1. Locate the directory [Ansys 2022 R1 Install]/RSM/Config/xml.
2. 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 as-
sumes 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.
<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 [RSMIn-
stall]\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.
This example script is set up to be run on a modified LSF cluster. If you are running on a different
cluster type, you will need to choose a different parsing script (or write a new one) depending on
the cluster type that you have chosen. Parsing scripts are available for supported cluster types: LSF,
PBS Pro, SLURM, UGE, and MSCC. They are named lsfParsing.py, pbsParsing.py, ugePars-
ing.py, and msccParsing.py respectively. If you are using an unsupported cluster type, you
will need to write your own parsing script. For details refer to Parsing of the Commands Out-
put (p. 173).
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. 172).
<jobCommands version="3" name="Custom Cluster Commands">
<environment>
<env name="RSM_HPC_PARSE">LSF</env>
<env name="RSM_HPC_PARSE_MARKER">START</env> 
</environment>
<submit>
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/submit_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
<postcommands>
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/lsfParsing.py</pythonapp>
</application>
<arguments>
<arg>-submit</arg>
<arg>
<condition>
</condition>
</arg>
</arguments>
<outputs>
</outputs>
</command>
</postcommands>
</submit>
<queryStatus>
<primaryCommand name="queryStatus">
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/status_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
<postcommands>
<command name="parseStatus">
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/lsfParsing.py</pythonapp>
</application>
<arguments>
<arg>-status</arg>
<arg>
<condition>
</condition>
</arg>
</arguments>
<outputs>
<variableName>RSM_HPC_OUTPUT_STATUS</variableName>
</outputs>
</command>
</postcommands>
</queryStatus>
<cancel>
<primaryCommand name="cancel">
<properties>
</properties>
<application>
<pythonapp>%RSM_HPC_SCRIPTS_DIRECTORY_LOCAL%/cancel_CUS_LSF.py</pythonapp>
</application>
<arguments>
</arguments>
</primaryCommand>
</cancel>
</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.

When creating a configuration for a custom cluster in RSM, you must set the HPC type to Custom,
and specify your custom cluster keyword in the Custom HPC type field. (For our example, we would
enter CUS_LSF in the Custom HPC type field.)
A “custom client integration” means that you are running in SSH mode (or non-RSM communication).
Thus, when specifying how the client communicates with the cluster, you need to select Use SSH
or custom communication to the submit host, and specify the account name that the Windows
RSM client will use to access the remote Linux submit host.
For the File Management tab, see Specifying File Management Properties (p. 41) for details on
the different file transfer scenarios.
8.2.3. Configuring SSH/Custom File Transfers

If you are using SSH to transfer files to the HPC staging directory, you can customize commands to
be used for client-to-HPC file management.
If you are using a custom mechanism for file transfers, you will need to create a custom HPC storage
commands file. You will then need to add an entry to the jobConfiguration.xml file which
references these files.
Follow the steps below to configure a customized file transfer mechanism.
1. When creating a configuration, on the File Management tab, select External mechanism for
file transfer (SCP, Custom), then select either SCP via SSH or Custom from the Transfer
mechanism dropdown. Fill out the fields as described in File Management Properties for a
Cluster (p. 41).
If you are using a Custom mechanism, make note of the keyword specified in the Custom
transfer type field, as it will be used in upcoming steps.
2. To define custom commands for transferring files to/from the HPC staging directory, edit or
create a custom HPC storage commands file in the [RSMInstall]\Config\xml directory.
• If you are using SSH-SCP, edit the hpc_storage_SSH.xml file. You may want to create a
backup of the original file before editing it.
• If you are using a custom mechanism, use hpc_storage_SSH.xml as a base to create a

new HPC storage command file (for example, hpc_storage_AnsSecureTransfer.xml).
Commands defined in this file include createStorage, deleteStorage, uploadToStorage,

downloadFromStorage, and listStorageContents.
Some commands use specific scripts for execution. For example, if you are using SSH, the up-
loadToStorage and downloadFromStorage commands use the scp.py script. If you are
using a custom mechanism, you will need to create custom command scripts and reference them
in the command definitions in the HPC storage commands file. For example, if your custom
keyword is AnsSecureTransfer, you might create a script called AnsSecureTransfer.py,
and reference that script in the uploadToStorage and downloadFromStorage commands.
To customize command scripts, go to the [RSMInstall]\Config\scripts directory.
RSM will set the following variables when file transfer commands are executed:
• RSM_HPC_FILEDIRECTION
• RSM_HPC_FILECONTEXT
• RSM_HPC_FILELIST
• RSM_HPC_FILEUPLOADTRACKING
• RSM_HPC_FILE_LOCAL_DIR
• RSM_HPC_FILE_REMOTE_DIR
• RSM_HPC_FILEEXCLUDE (if exclusions exist)
For more information about these variables, see Environment Variables Set by RSM (p. 179).
3. If you are using a custom mechanism, edit the jobConfiguration.xml file in the [RSMIn-
stall]\Config\xml directory.
Create an entry for your custom transfer type which references the custom HPC storage commands
file (and optionally the custom protocol definition file) that you created in the previous steps.
Be sure to append your keyword (that you specified in step 1) to the keyword name. For example:
<keyword name="STORAGE_AnsSecureTransfer">
<hpcCommands name="hpc_storage_AnsSecureTransfer.xml"/>
</keyword>
Note that there is already an entry for the SSH-SCP protocol in the jobConfiguration.xml
file named STORAGE_SSH-SCP.
8.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 standard login environment variables as well as environment variables that
are dynamically set by RSM to provide information about job- and storage-related actions. A detailed
description of the environment variables that the scripts can access is given in Custom Integration En-
vironment Variables (p. 178).
Each command has some environment variables provided that RSM expects the command will need in
order to function as expected. Some commands have required outputs as well. If a command is being
written as an entirely new script or executable to be used solely for RSM integration, then the desired
inputs and outputs can be directly read and written from that script or executable. However, in most
cases, the command is often something that is already written, and that has only predetermined com-
mand line options such as mkdir, bsub, qstat, and cp. In this case, RSM allows the use of pre and
post commands in order to set up or parse some information from a basic command in order to provide
the RSM output required.
This section discusses the following topics:

8.3.1. Parsing of the Commands Output
8.3.2. Customizable Commands
8.3.3. Custom Integration Environment Variables
8.3.4. Providing Custom Client Information for Job Submission
Writing Custom Code for RSM Integration
8.3.1. Parsing of the Commands Output

Commands such as submit and queryStatus require some parsing of cluster-specific output. RSM
has externalized this parsing so that any custom cluster output can be interpreted by a custom
parsing script that can be written and implemented as a post command. For a list of commands that
require output, see Required Output from Commands (p. 173).
Parsing scripts are already implemented for supported cluster types (LSF, PBS, and so on). They are
named lsfParsing.py, pbsParsing.py, and so on.
If you are not using the default implementation of a supported cluster, or you are trying to integrate
with an unsupported cluster, then you will need to write your own parsing script(s), or write a wrapper
script that includes the parsing internally.
8.3.1.1. Getting Output from Primary Commands in the Parsing Scripts

If maintaining an entire wrapper script suite for the custom cluster is not possible, or those wrappers
exist but cannot be changed in order to output the required RSM output, then using a post command
to parse the output of the command is needed.
In order to parse the output of the primary command and return an answer to the RSM code, you
need to use a few standardized variables. Every post command has access to these variables.
• RSM_HPC_PRIMARY_STDOUT
• RSM_HPC_PRIMARY_STDERR
These environment variables are set by RSM when running the post commands (parsing) code.
They contain all of the standard output and standard error, respectively, from the associated primary
command. The post command (parsing) script simply needs to make a call to the environment
variables above to get the necessary output from the associated command. Then, after obtaining
the standard output of the primary command, it can be parsed using any method desired in order
to create the required RSM output.
8.3.1.2. Outputting Variables from the Parsing Scripts

The parsing code also needs to be able to define variables. Putting them in the environment is not
enough for RSM. You must define them explicitly by writing a specific phrase to the standard output:
!RSM_DEFINE <VARIABLE_NAME> = <VARIABLE_VALUE>
As an example in Python, if you wanted to define a variable "RSM_HPC_OUTPUT_STATUS" as "FIN-

ISHED" you could simply code:
print("!RSM_DEFINE RSM_HPC_OUTPUT_STATUS = FINISHED")
8.3.1.3. Required Output from Commands

Each parsing command needs to output a specific variable after performing the parsing and determ-
ining what needs to be determined.
Base Parsing Required Output Description

Command Command Definition
submit parseSub- RSM_HPC_OUT- The job’s unique ID. A string that can be
mit PUT_JOBID used as an input to the queryStatus
command.
queryS- pars- RSM_HPC_OUT- The job’s status. An enumeration that must
tatus eStatus PUT_STATUS be exactly one of these values:
• Unknown
• Queued
• Running
• Finished
• Failed
• Cancelled
getAll- parseAll- RSM_HPC_OUT- The job statuses that are on the cluster in
Status Status PUT_GENERIC a Python dictionary format like
{JobId1:Status1, JobId2:Status2, ….. }, where
the jobID is the string from the cluster and
the Status is one of the statuses from the
list provided for parseStatus.
queryQueues check- RSM_HPC_OUT- Must be set to TRUE or FALSE based on
QueueEx- PUT_QUEUE_DEFINED whether or not the queue was found.
ists
get- parseQueueL-RSM_HPC_OUT- The queues that are available to the user
AllQueues ist PUT_GENERIC for job submission, in a Python list format
such as [queue1, queue2, queue3, …..].
listStor- parseList- RSM_HPC_OUT- The files that are contained in
ageCon- ing PUT_GENERIC RSM_HPC_FILE_REMOTE_DIR in a
tents Python dictionary format such as
{FileName:[Size, ModifiedDate],
FileName2:[Size2, ModifiedDate2],
…….}, where:
The filename is relative to the provided

directory.
The size is in bytes.
The modified Date can be in many

formats, but the common format of
“MMM d HH:mm” or less accurately
“MMM d yyyy” are allowed.
8.3.1.4. Commands Output in the RSM Job Log

The output for all cluster primary command scripts (submit, queryStatus, queryQueues and
so on) should be sent directly to stdout or stderr, so that the output can be properly interpreted
by the parsing code. The contents of stdout may be added to the RSM job log as standard mes-
sages. This content is also searched by the parsing commands in order to parse the information
necessary as a result of the command execution.
The handling of the command output depends on the post commands parseSubmit, pars-
eStatus and checkQueueExists discussed previously.
Error Handling
Error messages and warnings information are written to stdout as necessary. If they are properly
labeled as indicated below, they will 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’)
Debugging
Debugging information, typically used for troubleshooting purposes, is shown in the RSM job log
only if the Debug Messages option is selected from the job log context menu. (To access this option,
right-click anywhere inside the job log pane of the RSM application main window.)
Output format:
RSM_HPC_DEBUG=<debugmessage>
8.3.2. Customizable Commands

RSM will invoke a custom implementation for the following commands:
Job-Specific Commands
• Submit Command (p. 176)
• queryStatus Command (p. 176)
• getAllStatus Command (p. 177) (optional)
• queryQueues Command (p. 177) (optional)
• getAllQueues Command (p. 177) (optional)
• Cancel Command (p. 177)
File Storage Commands
• createStorage Command (p. 178)
• deleteStorage Command (p. 178)
• uploadToStorage Command (p. 178)
• downloadFromStorage Command (p. 178)
• listStorageContents Command (p. 178)
8.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.
The parsing of the output of the submit command is handled by the post command parseSub-
mit, which will look through all of the output from the submit script, find the Job ID, and return
it in a formal manner. For details see Parsing of the Commands Output (p. 173).
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 user-selected 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 ap-
propriate 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 [RSMIn-
stall]\Config\scripts\EXAMPLES directory.
• A generalized custom client example (for all cluster types) is provided in the file sub-
mitGeneric.py, located in the [RSMInstall]\Config\scripts directory.
8.3.2.2. queryStatus Command

The queryStatus 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.
The output of the queryStatus command should be direct output from the cluster. Any parsing
of this output can be done by the post command parseStatus, which will look through all of
the output from the queryStatus command, find the job status, and return it in a formal manner.
For details see Parsing of the Commands Output (p. 173).
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.
8.3.2.3. getAllStatus Command

The getAllStatus command is an optional command to implement that may improve perform-
ance in heavily loaded RSM installations.
The command should query the cluster for the status of all the jobs available and return the job
status for each in a Python dictionary format, or add a post (parsing) command to convert the
output into the format described in Required Output from Commands (p. 173). If no jobs are running,
a dictionary result should still be returned, but it should be “{-1:UNKNOWN}”.
8.3.2.4. queryQueues Command

The queryQueues command is an optional command to implement that enables RSM to check
if a queue specified by the user is a valid queue that can be used. This can prevent the submission
of many invalid jobs.
Given a queue name, RSM_HPC_QUEUE, the command should check if that queue is valid for this
user and return TRUE or FALSE as described in Outputting Variables from the Parsing Scripts (p. 173)
and Required Output from Commands (p. 173) (checkQueueExists).
8.3.2.5. getAllQueues Command

The getAllQueues command is an optional command to implement that allows RSM to let users
use the Import/Refresh HPC Queues button when defining RSM queues in the RSM Configuration
application, which will return a list of available cluster queues. If no command is defined for the
cluster type, then the import function will simply not work, and users will need to input the cluster
queue name(s) manually in order to run jobs on the cluster.
8.3.2.6. 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 can-
celGeneric.py, located in the[RSMInstall]\Config\scripts directory.
8.3.2.7. createStorage Command

The createStorage command is expected to create a storage location using the environment
variable identifier RSM_HPC_FILE_REMOTE_DIR.
No output is required from the createStorage command. However, an output statement should
be given for verification in the RSM log.
8.3.2.8. deleteStorage Command

The deleteStorage command is expected to delete a storage location and all of its sub contents
using the environment variable identifier (directoryName) RSM_HPC_FILE_REMOTE_DIR.
No output is required from the deleteStorage command. However, an output statement should
be given for verification in the RSM log.
8.3.2.9. uploadToStorage Command

The uploadToStorage command is expected to upload a list of files provided in the environment
variable RSM_HPC_FILELIST from a local directory RSM_HPC_FILE_LOCAL_DIR to a storage
location with the identifier (directoryName) RSM_HPC_FILE_REMOTE_DIR.
No output is required from the uploadToStorage command. However, an output statement

should be given for verification in the RSM log when files are uploaded.
8.3.2.10. downloadFromStorage Command

The downloadFromStorage command is expected to download a list of files provided in the
environment variable RSM_HPC_FILELIST from a storage location with the identifier (directory-
Name) RSM_HPC_FILE_REMOTE_DIR to the local directory RSM_HPC_FILE_LOCAL_DIR.
No output is required from the downloadFromStorage command. However, an output statement

should be given for verification in the RSM log when files are downloaded.
8.3.2.11. listStorageContents Command

The listStorageContents command is expected to return the files found in the
RSM_HPC_FILE_REMOTE_DIR that match the specifications listed in RSM_HPC_FILELIST while
excluding any files that match the specifications listed in RSM_HPC_FILEEXCLUDE.
The format of the output should be a that of a stringified Python dictionary of the filenames along
with other required information as shown in Required Output from Commands (p. 173).
8.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.
8.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_TAR- Set as "Windows" or "Linux". Defines the platform on
GET_PLATFORM which the final scripts are meant to run.
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.
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_FILE_LOCAL_DIR Used only by storage commands/scripts. Specifies the
directory on the client machine from/to which files are
transferred.
RSM_HPC_FILE_REMOTE_DIR Used only by storage commands/scripts. Specifies the
directory on the remote machine from/to which files are
transferred.
RSM_HPC_FILECONTEXT Used only by storage commands/scripts. 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 storage commands/scripts. 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_FILEEXCLUDE Used only by storage commands/scripts, and only if
exclusions exist. Semi-colon delimited list of files to
exclude from transfer.
RSM_HPC_FILELIST Used only by storage commands/scripts. 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_FILEUPLOADTRACK- Used only by storage commands/scripts. When a file is
ING uploaded, this determines whether or not it will be
downloaded again. Set to TRUEor FALSE.
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, Work-
bench_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 cluster submit host is running.
RSM_HPC_NATIVEOPTIONS Value(s) of the Job submission arguments property
on the HPC Resource tab when defining a
configuration in RSM.
Workbench/RSM does not define or manipulate these

administrator-specified options.
RSM_HPC_PROTOCOL_OPTION1 Used only when Use SSH or custom communication
to the submit host is selected on the HPC Resource
tab.
Contains the value of the remote account name.

to the submit host is checked on the HPC Resource
tab.
Contains the value of the Remote Computer Name

(or Cluster Node).
to the submit host is selected on the HPC Resource
tab.
Contains the value of the local environment variable

%KEYPATH% to be used for remote machine
authentication.
RSM_HPC_QUEUE The queue requested by the user for the job.
The list of available queues is defined by the

Workbench/RSM administrator.
RSM_HPC_STAGING Path for the cluster’s central staging area for job files.
Typically needed when client and cluster platforms
are different.
Defined by the Staging directory path on cluster

property on the File Management tab.
RSM_HPC_STDERRFILE A request that HPC 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 HPC job stdout be redirected into
the named file. The contents of this file will be added
to the RSM job log.
8.3.3.2. Optional Environment Variables Set by Customer

The following optional environment variable can be set by your RSM administrator on the cluster
side. It will be passed to the cluster submit host as an environment variable to be used in scripting:
Environment Variable Description

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.
Additionally, the user can set any number of variables that follow in Providing Custom Client Inform-
ation for Job Submission (p. 181).
8.3.4. Providing Custom Client 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 to the submission of a job to the cluster. Custom information that you
define on the RSM client machine can be picked up by RSM and then passed to the cluster submit
host or cluster node where the job is being executed.
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)
• 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 admin-
istrator or Ansys customer support.
As an example, we’ll pass the submitter’s username from the client to a PBS Pro cluster.
The following sections detail the steps for providing custom information for job submissions to
clusters.
8.3.4.1. Defining the Environment Variable on the Client
8.3.4.2. Passing the Environment Variable to the Cluster
8.3.4.3. Verify the Custom Information on the Cluster
8.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 cluster submit host.
In the example below, we’ve defined the environment variable RSM_CLIENT_USERNAME. The
name is arbitrary as long as it begins with the RSM_CLIENT_ prefix.
8.3.4.2. Passing the Environment Variable to the Cluster

Once you’ve defined the environment variable on the RSM client machine, it will be passed along
with other job files to the cluster. 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 com-
mand. 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>
To view a sample of this file before the addition of custom information, see Modifying the Cluster-
Specific HPC Commands File (p. 168).
8.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 you’ve 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 ...
Chapter 9: RSM Job Monitoring
The RSM Job Monitoring application enables you to monitor jobs that you have submitted to a cluster
from Workbench. Although jobs can be monitored directly in Workbench, the RSM Job Monitoring
application enables you to monitor jobs if the client application is closed or inaccessible. This standalone
application is included in every RSM installation for your convenience.
Note:
The RSM Job Monitoring application can be used to monitor the jobs of the current user
only.
In this chapter:
9.1. Launching the RSM Job Monitoring Application
9.2. Monitoring Jobs in the RSM Job Monitoring Application
9.3. Viewing a Job Log
9.4. Managing Jobs
9.1. Launching the RSM Job Monitoring Application

To launch the RSM Job Monitoring application:
• On Windows, select Start > Ansys 2022 R1 > RSM Job Monitoring 2022 R1.
You can also launch the application manually by double-clicking Ans.Rsm.JobMonitor.exe in

the [RSMInstall]\bin directory.
• On Linux, run the <RSMInstall>/Config/tools/linux/rsmjobmonitor script.
9.2. Monitoring Jobs in the RSM Job Monitoring Application

By default, when you launch the RSM Job Monitoring application, all of the jobs that you have submitted
to Remote Solve Manager are listed in the upper pane.
Here is an overview of the RSM Job Monitoring application:
RSM Job Monitoring
You can use context-sensitive menus in the upper and lower panes to perform a variety of actions. For
example, you can customize the job list display, and perform actions on a job such as Abort or Interrupt.
In this section:
9.2.1. Viewing the Status of Jobs
9.2.2. Enabling Live Job Monitoring
9.2.3. Controlling the Job List Display
9.2.4. Filtering the Job List
Monitoring Jobs in the RSM Job Monitoring Application
9.2.1. Viewing the Status of Jobs

The status of each job is indicated in the Status column, and by a unique icon at the beginning of
the job entry. The addition of an arrow symbol to the final status icon indicates that the job has been
released.
Status Description Icon Released Icon

Input Job is being uploaded to the cluster.
Pending
Queued The job has been placed in the cluster queue,
and is waiting to run.
Running Job is running.
Cancelled Job has been terminated via a cancel or Abort
action.
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
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.
9.2.2. Enabling Live Job Monitoring

When a job is submitted to an HPC resource from a client application (for example, Workbench or
Mechanical), the application requests that RSM query the resource for a live job status. This process
is referred to as a real-time status refresh.
By default, the RSM Job Monitoring application does not perform a real-time status refresh. This is
because the client application already performs a real-time status refresh, and it is assumed that you
will be monitoring your jobs in the client application. Rather, the RSM Job Monitoring application
refreshes job status based on the cached job status in RSM, which is the status that was obtained the
last time that a query was made, and saved in the job's history. This prevents unnecessary querying
of the HPC resource (since the client application is already doing that), and improves monitoring
performance.
If the client application is shut down, however, and you want to use the RSM Job Monitoring applic-
ation to monitor your jobs, it is recommended that you enable real-time refresh mode in the RSM
RSM Job Monitoring
Job Monitoring application to get real-time job status updates from the HPC resource. If you do not
enable real-time refresh mode, the reported status of running jobs may not be an up-to-the-minute
reflection of the true job status.
To enable real-time refresh mode, click on the toolbar.
If you subsequently return to monitoring jobs from the client application, you can disable real-time
refresh mode in the RSM Job Monitoring application by clicking on the toolbar.
9.2.3. Controlling the Job List Display

You can sort the job list by job name, status, owner, and so on by clicking on the appropriate column
header in the upper pane. Clicking on the same column header again reverses the sort order.
If you right-click any column header, a context menu is displayed which contains the following options:
Select All Selects all jobs in the list.

(Ctrl+A)
Scroll to Returns you to the beginning of the job list.
Top
Scroll to Takes you to the end of the job list.
Bottom
View Line Toggles the display of numbers at the beginning
Numbers of each entry in the job list.
9.2.4. Filtering the Job List

By default, all jobs are shown in the job list. To filter the job list so that it only shows jobs with a
particular status, make a selection from the filter drop box:
9.3. Viewing a Job Log

A job log displays details about what has occurred during a particular job. It is particularly helpful when
you need to troubleshoot a failed job.
To display a log for a particular job, simply click the job in the upper pane. Details about the job are
displayed in the lower pane:
Viewing a Job Log
The log automatically scrolls to the bottom to keep the most recent messages in view. If necessary you
can copy and paste the log's content into a text editor, or save the log to a file.
In this section:
9.3.1. Controlling the Job Log Display
9.3.2. Copying Text in the Job Log Display
9.3.3. Saving a Job Report
9.3.4. Hiding/Showing the Job Log Pane
9.3.1. Controlling the Job Log Display

If you right-click in the job log view, a context-sensitive menu provides the following options for
controlling the display of content in the job log pane:
View Line Numbers Toggle the display of line numbers at the beginning of each line in the job
log.
View Time Stamps Toggle the display of time stamps at the beginning of each line in the job
log.
RSM Job Monitoring
View Exclusively Only display file-related messages in the job log, such as those relating to
File Messages file transfers.
View Debug Toggle the display of debugging information in the job log.
Messages
SubTask Filters Filters the content of the job log by design point sub-task. This option is only
displayed when the job contains design points.
Scroll to Top Go to the top of the job log.
Scroll to Bottom Go to the bottom of the job log.
9.3.2. Copying Text in the Job Log Display

You can copy selected or all text in the job log to the Clipboard and then paste it into a text editor
or other application that accepts text.
To copy text:
1. Select the text that you want to copy:
• To select an individual line of text, click it.
• To select multiple, consecutive lines of text, use Shift+click.
• To select multiple, non-consecutive lines of text, use Ctrl+click.
• To select all text, right-click in the job log pane and choose Select All.
2. Right-click in the job log pane and select Copy.
As an alternative you can use the Save Job Report action to instantly save the entire job log to a
file. See Saving a Job Report (p. 190).
9.3.3. Saving a Job Report

You can save the currently displayed job log to an HTML or TXT file that can be shared with others.
To save a job log:
1. In the upper pane, select the job whose log you want to save.
2. In the lower pane, right-click in the job log view and select Save Job Report.
3. In the Save Job Report dialog box, specify the desired save location and file name:
Managing Jobs
You can also specify whether or not you want to display the following in the report:
• Debug Messages
• Log Time Stamp
• Line Numbering
4. Click Save.
9.3.4. Hiding/Showing the Job Log Pane
To hide or show the job log pane, click the toggle on the toolbar.
When the job log pane is hidden, the job list pane is maximized.
9.4. Managing Jobs

You can use the RSM Job Monitoring application to terminate a running job, or remove completed
jobs from the job list.
If you right-click a job in the upper pane, a context-sensitive menu is displayed that contains Abort,
Interrupt and Remove actions.
These actions are described in the following topics:

9.4.1.Terminating a Job
9.4.2. Removing a Job
9.4.1. Terminating a Job

You can use the RSM Job Monitoring application to abort or interrupt a running job.
The Abort action stops the calculation immediately without any regard for available generated data.
Jobs terminated via this option will have a status of Cancelled.
The Interrupt action stops the calculation at the next point where data can be safely stored for later
use. When a job is interrupted, any available generated data will be retained. Jobs terminated via this
option will have a status of Finished.
To abort a job, right-click the job in the list view and select Abort.
RSM Job Monitoring
To interrupt a job, right-click the job in the list view and select Interrupt.
Note:
The Abort and Interrupt actions are enabled for running jobs only.
9.4.2. Removing a Job

You can remove completed jobs from the job list display. A completed job is one whose status is
either Completed, Failed, or Cancelled.
To delete a job:
1. Select the job in the job list display.
2. Do one of the following:
• Right-click and select Remove. Or,
• Click on the toolbar. Or,
• Press Delete on your keyboard.
Chapter 10: RSM Cluster Load Monitoring
When RSM is integrated with a cluster using configurations defined in RSM, you can use the RSM Cluster
Load Monitoring application to retrieve and display the following information from the cluster:
• Available cores
• Available nodes
• Used/total cores per node
• Details and status of recently submitted jobs
This information can help you monitor cluster usage, determine available resources, and troubleshoot
issues.
A refresh feature enables you to get up-to-the-minute status information when needed.
In this chapter:
10.1. Launching the RSM Cluster Load Monitoring Application
10.2. Monitoring a Cluster in the RSM Cluster Load Monitoring Application
10.3. Viewing Cluster Job Information
10.4. Controlling the Display of Cluster Monitors
10.1. Launching the RSM Cluster Load Monitoring Application

Currently, the RSM Cluster Load Monitoring application is supported on Windows only.
To launch it, select Start > Ansys 2022 R1 > RSM Cluster Monitoring 2022 R1.
You can also launch the application manually by double-clicking Ans.Rsm.ClusterMonitor.exe

in the [RSMInstall]\bin directory.
10.2. Monitoring a Cluster in the RSM Cluster Load Monitoring Application

The RSM Cluster Load Monitoring application retrieves current status information from a cluster and
displays the information in easy-to-read diagrams and tables. Use it to view a basic set of data and
metrics, and monitor cluster usage and availability.
To monitor the status of a cluster:
1. In the RSM Cluster Load Monitoring application, select the HPC configuration with which the
cluster is associated. For more information about HPC configurations, see RSM Configuration (p. 31).
RSM Cluster Load Monitoring
When you select a configuration, information about the associated cluster's Submit host and HPC
type are displayed below the HPC configuration drop-down list.
2. To retrieve current information from the selected cluster, click on the toolbar, or click
next to the HPC configuration drop-down list
Here is an overview of the RSM Cluster Load Monitoring application window:
The Overall Status section lets you know at a glance how many cores and nodes are currently available
for use in the cluster. Use the color legend to understand the meaning of colored sections in the dia-
grams.
Viewing Cluster Job Information
The Nodal Heat Map helps you visualize the activity and availability on each node, by displaying the
number of cores being used by jobs versus the total number of cores available.
The Recent Jobs section displays a list of jobs that users have recently submitted to the cluster, and
details about each job. See Viewing Cluster Job Information (p. 195).
Note that for an Ansys RSM Cluster (ARC), all jobs are displayed in the Recent Jobs list. For other cluster
types, however, you may only see a partial listing of jobs if the cluster administrator has placed restrictions
on the types of jobs that you can view (for example, you may only be able to view your own jobs). If
only a partial job list is displayed, the information reported in the Overall Status and Nodal Heat Map
sections represents the resources being consumed by all jobs, not just the ones you see in the job list.
Note:
To minimize the querying of the HPC resource, the RSM Cluster Load Monitoring application
does not perform a continuous, real-time status refresh. To get up-to-the-minute status in-
formation, you must use the application's Refresh function.
10.3. Viewing Cluster Job Information

The RSM Cluster Load Monitoring application displays a list of jobs that have been recently submitted
to the cluster from RSM. For each job you can see the job ID, number of requested cores, cluster queue,
owner, and job status.
Below is a description of each job status:
Status Description
The job has been placed in the cluster queue,
Queued and is waiting to run.
The job is running.
Running
The job has been terminated via a cancel or
Abort action.
Cancelled
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
The job has completed successfully.
Finished Also applies to jobs that have been terminated

via the Interrupt option or for which you have
saved results prior to exiting the project.
The job has failed.

Failed
Also may be applied to jobs that cannot be
cancelled due to fatal errors.
The job status being reported by the cluster is
one that is not recognized by RSM. For example,
Unknown a cluster may have unique job states such as
'Held' or 'Suspended', which RSM cannot parse.
10.3.1. Sorting and Filtering the Cluster Job List

By default, the Recent Jobs list in the RSM Cluster Load Monitoring application is sorted by Job Id
in alphanumerically ascending order.
You can sort the job list by any other criterion (Cores, Queue, Owner, Status) by clicking on the
appropriate column header in the Recent Jobs table. Clicking on the same column header a second
time reverses the sort order of that column (from ascending to descending).
Note:
Performing a refresh of the RSM Cluster Load Monitoring window returns the table to
the default sort order (ascending Job Id), and removes any filters that you have applied.
Changing the Sort Order in a Column

Each column in the table has its own sort and filter options. To access these options, click the drop-
down arrow in the column header:
Viewing Cluster Job Information
To sort the column in either ascending or descending order, select either Sort Ascending or Sort
Descending in the drop-down menu. Selecting either of these options makes the current column
the one by which the table is sorted.
To return the table to the sort order that was in place prior to selecting a sort option, select Remove
Sort.
Filtering Jobs in the Job List

You can tailor the Recent Jobs list to display jobs with specific criteria only. For example, you may
only want to see jobs associated with a specific queue, or owner.
To filter content in a column:
1. Click the drop-down arrow in the column that contains the desired filter criteria. For example, if
you only wanted to see jobs that used 3 or more cores, you would display the drop-down in the
Cores column.
2. In the drop-down, disable the criteria that you do not want to include in the job list display:
3. Click Filter to update the table.
When filters have been applied to a column, a filter icon is displayed next to the column's drop-down
arrow to indicate that a filtered view is currently displayed:
Note that the filters will remain active even if you choose to sort the table by a different column.
However, filters will be cleared if you perform a Refresh.
To clear filters that you have applied to the job list, display the appropriate column drop-down and
click Clear.
10.4. Controlling the Display of Cluster Monitors

To hide or restore any of the three monitors displayed in the RSM Cluster Load Monitoring application,
click the list icon in the top left corner of the monitoring window:
In the list, click a section to toggle it on or off:
Chapter 11: RSM Troubleshooting
In this chapter:
11.1. Accessing RSM Log Files
11.2.Troubleshooting RSM-Related Issues
11.3.Troubleshooting Product-Related Issues
11.4. Known Issues and Limitations
11.1. Accessing RSM Log Files

You can use the following log files to troubleshoot issues relating to RSM or Ansys RSM Cluster (ARC)
configuration:
Table 11.1: Key RSM Log Files
Log File Location Purpose

rsmlauncher221- Windows Provides service information and
<timestamp>.log errors from the RSM Launcher Service
C:\Windows\Temp (Ans.Rsm.Launcher.exe process).
Linux
/tmp
rsm_user- Windows Provides service information and
name_<timestamp>_pid.log errors from the RSM UserProxy
User %TEMP% process (Ans.Rsm.UPHost.exe). There
will be a UserProxy process for each
Linux user.
/tmp
ArcMaster221-<date>.log Windows When configuring an Ansys RSM
Cluster (ARC), this provides a
If running as a Windows transcript of what has occurred while
service: C:\Win- starting the ARC Master Service on
dows\Temp the submit host.
If not running as a
Windows service: %USER-
PROFILE%\App-
Data\Local\Temp
Linux
/tmp
RSM Troubleshooting
Log File Location Purpose

ArcNode221-<date>.log Windows When configuring an Ansys RSM
Cluster (ARC), this provides a
If running as a Windows transcript of what has occurred while
service: C:\Win- starting the ARC Node Service on an
dows\Temp execution node.
If not running as a
Windows service: %USER-
PROFILE%\App-
Data\Local\Temp
Linux
/tmp
11.2. Troubleshooting RSM-Related Issues

This section addresses issues that may occur in the RSM application.
Generating the RSM Service Startup Script for Linux

The script for manually starting the RSM launcher service is usually generated during installation. In the
event that the script is not generated as part of the install, or if you have removed the generated script,
you can generate the script manually by running the rsmconfig script with no command line options.
Alternatively you can run generate_service_script with the -launcher command line option:
tools/linux> ./generate_service_script
Usage: generate_service_script -launcher
Options:
-launcher: Generate RSM Launcher 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"
Troubleshooting RSM-Related Issues
For more information on configuring RSM clients and cluster nodes using a network installation, refer
to Network Installation and Product Configuration.
Firewall Issues
Error: 'LauncherService at machine:9221 not reached'
1. Ensure that the launcher service is running. For instructions refer to Installing and Configuring the
RSM Launcher Service (p. 20).
2. If you have a local firewall turned on, you need to add port 9221 to the Exceptions List for the
launcher service (Ans.Rsm.Launcher.exe).
3. Allow a ping through the firewall (Echo Request - ICMPv4-In). Enable "File and Printer Sharing" in
firewall rules.
User proxy ports:
A user proxy process is created for every user who submits a job to RSM. Each user proxy process will
use a separate port chosen by RSM. By default, RSM will randomly select any port that is free. If you
want to control which ports RSM can choose, ensure that a range of ports are available for this purpose,
and specify the port range in the RSM application settings. See Specifying a Port Range for User Proxy
Processes (p. 146).
When the user proxy process is transferring files, a port is opened up for each file being transferred. If
you want to control which ports RSM can choose, ensure that a range of ports are available for this
purpose, and specify the port range in the RSM application settings. See Specifying a Port Range for
User Proxy Socket File Transfers (p. 146).
If submitting jobs to a multi-node Ansys RSM Cluster (ARC):
When a firewall is in place, traffic from the master node to the execution nodes (and vice versa) may
be blocked. To resolve this issue, you must enable ports on cluster nodes to allow incoming traffic, and
then tell each node what port to use when communicating with other nodes. For details see Dealing
with a Firewall in a Multi-Node Ansys RSM Cluster (ARC) (p. 103).
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.
RSM Troubleshooting
Internet Protocol version 6 (IPv6) Issues

When localhost is specified as the Submit Host in an RSM configuration, you may receive an error
if the machine on which the configuration is being used has not been configured correctly as local-
host.
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 on a remote cluster submit host, additional configuration may be
necessary to establish communication between the RSM client and the submit host. For instructions,
refer to Configuring a Computer with Multiple Network Interface Cards (NICs) (p. 60).
RSH Protocol Not Supported

The RSH protocol is not officially supported and will be completely removed from future releases.
Job Submission Failing: Network Shares Not Supported

Users may encounter errors when submitting jobs to RSM using a network share from Windows. This
applies to any cluster setup, including the Ansys RSM Cluster (ARC) setup, when a network share (UNC
path or mapped drive) is used as a job's working directory.
Initially, the following error may be displayed in the RSM job report:
Job was not run on the cluster. Check the cluster logs and check if the
cluster is configured properly.
If you see this error, you will need to enable debug messages in the RSM job report in Workbench to
get more details about the failed job. Look for an error similar to the following:
259 5/18/2017 3:10:52 PM '\\jsmithPC\John-Share\WB\InitVal_pending\UDP-2'
260 5/18/2017 3:10:52 PM CMD.EXE was started with the above path as the current directory.
261 5/18/2017 3:10:52 PM UNC paths are not supported. Defaulting to Windows directory.
262 5/18/2017 3:10:52 PM 'clusterjob.bat' is not recognized as an internal or external command,
263 5/18/2017 3:10:52 PM operable program or batch file.
Alternatively, for a Microsoft HPC cluster, you can gather diagnostic information by running the HPC
Job Manager (supplied as part of the Microsoft HPC Pack), selecting the failed job, and examining the
output section of the job’s tasks.
Solution: Modify the registry on Windows compute nodes to enable the execution of commands via
UNC paths.
1. Create a text file of the following contents and save to a file (for example, commandpromp-
tUNC.reg).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor]
"CompletionChar"=dword:00000009
"DefaultColor"=dword:00000000
"EnableExtensions"=dword:00000001
"DisableUNCCheck"=dword:00000001
2. Run the following command on all Windows compute nodes:

regedit -s commandpromptUNC.reg
For a Microsoft HPC cluster, 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.
Error: 'Submit Failed' (Commands.xml not found)

If job submission fails and you see something similar to the following in the job log, this indicates that
the commands.xml file was not transferred from the client to the cluster staging directory:
32 11/10/2017 9:07:46 AM Submit Failed
33 11/10/2017 9:07:46 AM C:\Users\atester\AppData\Local\Temp\RsmConfigTest\ibnjrsue.24u\commands.xml
This can occur if the file transfer method in the RSM configuration is set to No file transfer needed,
which requires that client files be located in a shared file system that is visible to all cluster nodes.
To resolve this issue, choose one of the following options:
• Change the file transfer method to RSM internal file transfer mechanism, and enter the path of
the cluster staging directory.
OR
• Ensure that the cluster staging directory is visible to client machines, and that client working direct-
ories are created within the shared file system.
For information on file management options, see Specifying File Management Properties (p. 41).
Job Stuck on an Ansys RSM Cluster (ARC)

A job may get stuck in the Running or Submitted state if ARC services have crashed or have been re-
started while the job was still running.
To resolve this issue:
RSM Troubleshooting
1. First, try to cancel the job using the arckill <jobId> command. See Cancelling a Job (arck-
ill) (p. 94).
2. If cancelling the job does not work, stop the ARC services, and then clear out the job database and
load database files on the Master node and the node(s) assigned to the stuck job. Delete the backups
of these databases as well.
On Windows, the database files are located in the %PROGRAMDATA%\Ansys\v221\ARC folder.
On Linux, the database files are located in the service user's home directory. For example,
/home/rsmadmin/.ansys/v221/ARC.
Once the database files are deleted, restart the ARC services. The databases will be recreated auto-
matically.
Tip:
Clearing out the databases will fix almost any issue that you encounter with an Ansys
RSM Cluster. It is the equivalent of a reinstall.
Error Starting Job on Windows-Based Multi-Node Ansys RSM Cluster (ARC)

When starting a job on a multi-node Ansys RSM Cluster (ARC) that is running on Windows, you may
see the following error in the RSM job report:
Job was not run on the cluster. Check the cluster logs and check if the cluster is configured properly.
Use the arcstatus (p. 93) command to view any errors related to the job (or check the ArcNode log).
You may see an error similar to the following:
2017-12-02 12:04:29 [WARN] System.ComponentModel.Win32Exception: The directory name is invalid
["\\MachineName\RSM_temp\tkdqfuro.4ef\clusterjob.bat"] (CreateProcessAsUser)
This is likely due to a permissions restriction on the share that is displayed.
To resolve this issue you may need to open the network share of the cluster staging directory (\\Ma-
chineName\RSM_temp in the example) and grant Read/Write permissions on one of the following
accounts:
Error Starting RSM Job: Mutex /tmp/UserProxyLauncherLock.lock Issues

When submitting a job to RSM, you may get an error similar to the following:
2017-10-05 20:10:13 [WARN] Mutex /tmp/UserProxyLauncherLock.lock is taking a long time to obtain, but the
process that is using the mutex is still running ansarclnx1:::94255:::Ans.Rsm.Launcher. PID 94255
To resolve this issue:
1. Stop the RSM launcher service.
2. Remove /tmp/UserProxyLauncherLock.lock.
3. Restart RSM.
RSM Error: User Proxy Timeout

If an administrator has configured a feature like "hidepid" on Linux, so that users cannot see each other
processes, the user proxy could time out.
If you run into this issue, consult your system administrator.
At a minimum, an administrator should check to make sure that the RSM service user (for example,
rsmadmin) can see user proxy processes spawned for other users.
Error: Exception downloading file: No connection could be made because the

target machine actively refused it
In some cases, when result files are being downloaded from a cluster, some files do not get downloaded.
If this occurs, we recommend increasing the value of the User Proxy timeout setting to more than 10
minutes.
You will need to edit the following setting in the Ans.Rsm.AppSettings.config file:
<add key="IdleTimeoutMinutes" value="10" />
This setting appears twice in the configuration file. We recommend changing it in both places.
For more information see Editing RSM Application Settings (rsm.exe | rsmutils appsettings) (p. 145).
Linux Threading Limit

By default, many Linux systems limit the total number of threads each user can run at once, to avoid
multiple processes overloading the system. If you are running many Ansys jobs concurrently as the
same user (for example, submitting them through RSM), you may hit this limit, producing errors such
as Thread creation failed.
To view the current thread limit, run the following command:
• ulimit -u (bash)
• limit maxproc (csh)
To increase the thread limit, run the following command:
• ulimit -u [limit] (bash)
• limit maxproc [limit] (csh)
Where [limit] is a numerical value (for example, 4096).
RSM Troubleshooting
To view the administrator-imposed hard limit, run the following command:
• ulimit -H -u (bash)
• limit -H maxproc (csh)
You cannot increase the limit amount beyond this hard limit value. Contact your system administrator
to increase the hard limit.
Design Point Update Subtask Error When Using UGE Scheduler

When submitting design point updates to Remote Solve Manager, the design points are allocated to
one or more tasks and these tasks are allocated to one or more RSM jobs. This method of job submission
can create an error similar to the following when using an UGE scheduler queue:
executing task of job 3119 failed: execution daemon on host

"testhost.domain.com" didn't accept task
To solve this issue, open the sge_pe file on the cluster and change the daemon_forks_slaves
parameter to FALSE.
HDF5 File Locking

The HDF5 version used in 2022 R1 will result in failure when the underlying file system does not support
file locking, or where locks have been disabled. To disable all file locking operations, create an environ-
ment variable named HDF5_USE_FILE_LOCKING and set the value to the five-character string FALSE.
11.3. Troubleshooting Product-Related Issues

This section addresses issues that may occur in products that integrate with RSM.
CFD-Post Errors
If a project schematic contains CFD-Post, submitting a project or design point update to a Linux cluster
via RSM may result in errors, and the update of the CFD-Post results cell may fail completely.
When launching CFD-Post on a remote Linux machine, the DISPLAY variable must be either unset or
set to a valid X display before running in batch mode. For more information, see Running in Batch Mode
in the CFD-Post User's Guide.
Explicit Dynamics Systems: No Linux Support

RSM does not support Linux connections for Explicit Dynamics systems. Only Windows-to-Windows
connections are currently supported.
Known Issues and Limitations
Workbench/Mechanical: Unexpected Behavior with Rigid Dynamics or Explicit

Dynamics
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 Mechanical User's
Guide) will likely not function as expected with Rigid Dynamics or Explicit Dynamics due to write per-
missions for RSM working directories. As a workaround for this issue, do not use the built-in ‘My Com-
puter’ or ‘My Computer Background’ solve process settings.
System Coupling/CFX: CFX Solution Must be Set to Run in the Foreground

Coupled analyses (i.e., that have a System Coupling system on the project schematic) can be updated
only in the foreground. All coupling participant setups must be consistent with that of System Coupling.
Ensure that for each participant's Solution cell, the Solution Process | Update Option property is set
to Run in Foreground.
To avoid this issue, ensure that any CFX coupling participant has its Solution | Update Option property
set to Run in Foreground before submitting a coupling job to RSM.
Once an update has been attempted with a CFX participant’s Solution | Update Option property set
to Run in Background, you may find that it is not possible to change the value of this setting for CFX.
To address this issue, first reset System Coupling’s Solution cell and then set CFX to perform updates
using Run in Foreground.
11.4. Known Issues and Limitations

The following are known issues at the time of release, as well as system and software limitations:
• When using an application's My Computer, Background setting to solve a SMART Crack Growth
problem on the local machine, the solution may fail as a result of a failed remeshing attempt. Installing
ARC services as daemons resolves this issue.
• Currently the RSM Job Monitoring application shows the jobs of the current user only. It does not
show the jobs of all users.
• For System Coupling jobs:
– Coupling jobs must be submitted as design point updates.
– Coupling jobs must be run in the foreground, so all coupling participants must be configured for
foreground solution updates.
– Coupling jobs that are submitted to Microsoft HPC 2012 or 2016 may fail if the cluster staging
directory is not shared from the head node.
– The coupling process may fail to start for coupling jobs that are submitted to Microsoft HPC Pack
2019.
• A solution submitted to RSM may fail to start if the name of a folder in the project path contains
special characters, or characters with special marks such as accents. Removing these characters from
the folder name resolves this issue.
RSM Troubleshooting
• Currently, the RSM Cluster Load Monitoring application is supported on Windows only.
• When running remote design point updates through RSM to a Linux cluster, some jobs may be shown
as failed in the RSM Job Monitoring application, even though the design point calculation completed
and all results were retrieved. This will be accompanied with an error such as "[ERROR] FATAL UN-
HANDLED EXCEPTION: System.ExecutionEngineException: ExecutionContext_ExceptionInAsyncLocal-
Notification ---> System.Threading.ThreadAbortException" in the RSM job log. In this situation, the
results that have been retrieved are correct, and the failure status can be ignored.
• Job submission from Windows RSM clients to a Linux cluster may fail at the user authentication stage
if user accounts do not follow the account@machine format.
• Passwords that are cached by RSM and used to submit jobs to HPC resources cannot contain special
characters, or characters with special marks such as accents.
Glossary
Ansys RSM Cluster (ARC) The built-in cluster type provided by RSM. An ARC cluster operates
in the same way that a commercial cluster does, running Ansys ap-
plications in local or distributed mode, but uses its own scheduling
capability rather than a third-party job scheduler.
client application A client application is the Ansys application run on the local RSM
client machine and is used to submit jobs to 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.
cluster A cluster is a group of computers connected through a network to

work as a centralized data processing resource. Jobs submitted to
a cluster are managed by a queueing system to make optimal use
of all available resources.
HPC queue An HPC queue determines the machine(s) on which jobs will run
when jobs are submitted to that queue. HPC queues are defined on
the HPC side (for example, on a cluster submit host), and can be
imported into the RSM Configuration application so that you can
map them to RSM queues when defining configurations.
HPC staging directory The HPC staging directory is the directory in which job input files
are placed by the client application when a job is submitted to RSM.
When defining a configuration in RSM, you specify whether the job
will execute in the HPC staging directory, or in a local scratch direct-
ory on the execution node(s). If you choose the former option, the
HPC staging directory will also serve as the job execution directory.
cluster-side integration Cluster-side integration is a custom integration scenario in which

RSM is used to submit solve jobs to a remote cluster (either suppor-
ted or unsupported). In this scenario you are running in non-SSH
mode (RSM is able to directly submit jobs to the cluster).
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.
custom cluster integra- A custom cluster integration refers to the mechanism provided by
tion 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 cluster-side 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. It is recommended that you install the RSM launcher service
as a daemon service. This allows the launcher service to be started
Glossary
automatically without rebooting. The next time the machine is re-

booted, 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/submit 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 RSM and the cluster.
Typically it serves as the submit host and distributes jobs across the
cluster for execution.
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 execution directory The job execution directory is the solver working directory. If you
specify that jobs will run in the HPC staging directory, the HPC sta-
ging directory will serve as the job execution directory. If you specify
that jobs will run in a local scratch directory on the execution node(s),
job input files will be transferred from the HPC staging directory to
the local scratch directory, and files generated by the job will be
transferred to the HPC staging directory so that client applications
can access them.
job script A job script is a component of an RSM job. It runs an instance of

the client application on the execution node used to run the pro-
cessing 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® Spectrum LSF is a batch queuing system supported by RSM.
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 the RSM launcher service.
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.
queue A queue is a list of execution hosts that are suited to run a particular
class of jobs. When you submit a job to RSM, you submit it to an
RSM queue, which maps to an HPC queue. The HPC queue determ-
ines when and where the job will run based on resource requests
and current available resources. Queue definitions are part of the
configurations that are defined in RSM.
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 the RSM launcher service.
RSM Admins group The RSM Admins group is a Windows user group that confers ad-
ministrative 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 sub-
mitted to an HPC resource. It runs both RSM and a client application
such as Ansys Workbench.
RSM configuration A set of properties defined in RSM which specify information about
an HPC resource, and how RSM will communicate with that resource.
For example, it specifies the network name of a cluster submit host,
file transfer method to be used, and RSM queues. Configurations
are saved in .rsmcc files. If you store configurations in a shared
location, RSM users can retrieve them and use them on their own
machines.
RSM queue You define RSM queues when you define configurations in the RSM
Configuration application. When users submit jobs to RSM in client
applications, they submit them to RSM queues. Each RSM queue
maps to a specific RSM configuration and HPC queue. RSM queue
definitions are saved as .rsmq files.
rsmadmin user account An rsmadmin user account is a Linux account with membership in
the rsmadmins user group; as such, the account has RSM adminis-
trative privileges.
rsmadmins user group The rsmadmins user group is a Linux user group that confers ad-
ministrative privileges for RSM.
scratch directory Using a scratch directory is the practice of storing solver files in a
local directory on the execution node(s). Recommended to optimize
performance when there is a slow network connection between
execution nodes and the HPC staging 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.
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.
Glossary
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-platform communications, but native mode is the recom-
mended method.
submit host The submit host is the machine or cluster node that performs job
scheduling. In most cases, the cluster submit host is a remote ma-
chine, but it can also be your local machine ("localhost").
UGE Univa Grid Engine is a batch queuing system supported by RSM.

Ansys Remote Solve Manager User's Guide

Uploaded by

Copyright:

Available Formats

Ansys Remote Solve Manager User's 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 User's Guide

Uploaded by

Copyright:

Available Formats

What are the different roles defined in RSM?

What are the different roles defined in RSM?

What are the different components of an RSM configuration?

What are the different components of an RSM configuration?

Ansys Remote Solve Manager User's Guide

ANSYS, Inc. Release 2022 R1

© 2022 ANSYS, Inc. Unauthorized use, distribution or duplication is prohibited.

U.S. Government Rights

Published in the U.S.A.

3.5.5. Custom Client Integration ...................................................................................................... 61

6.4. Deleting a User Account ................................................................................................................ 134

8.3.2.3. getAllStatus Command ................................................................................................ 177

RSM provides the following key capabilities:

The following topics are discussed in this overview:

1.1. RSM Roles and Terminology

1.1. RSM Roles and Terminology

• The head node can serve as an execution node as well.

• For a cluster, the machine name of submit host

• For a Cloud portal, the URL of the web portal

• Client-to-HPC communication protocols

• File transfer mechanisms, HPC staging directory, HPC job directory

1.2. How RSM Works

Figure 1.1: General RSM Workflow

1.3. File Handling

Client Working Directory

HPC Staging Directory

HPC Job Directory

File Transfer Methods

• RSM internal socket file transfer

• Operating System file transfer (network share)

• External mechanism (such as SSH)

• No file transfer (client directory is under the HPC staging directory)

1.4. RSM Integration with Ansys Applications

1.4.1. RSM-Supported Applications and Solvers

• Workbench (p. 17)

• Mechanical (excluding the Samcef and ABAQUS solvers)

• System Coupling of Mechanical and Fluid solvers

• Rigid Body Dynamics

1.4.2. RSM Integration with Workbench

• Working with Ansys Remote Solve Manager

• Submitting System Coupling Jobs to Remote Solve Manager

• Submitting Solutions to Remote Solve Manager

• Updating Design Points in Remote Solve Manager

• Some applications may not be able to run on remote machines.

1.5. RSM Supported Third-Party Job Schedulers/Commercial Batch-

• Slurm Workload Manager

• Univa Grid Engine (UGE/SGE)

2.1. RSM Software Installation

Administrator privileges are not required to install or uninstall RSM.

2.1.1. Installing a Standalone RSM Package

1. Run the wizard as described in Installing Ansys, Inc. Products.

2. On the Select the products to install page:

b. Deselect all the other check boxes.

3. Continue the installation process as directed.

2.2. Installing and Configuring the RSM Launcher Service

2.2.1. Supported Platform Combinations

2.2.1.1. Configuring Windows-to-Linux Communication

Method 1: Use RSM's built-in communication capability (recommended)

• OPTION A: Run the [RSMInstall]/RSM/Config/tools/linux/rsmlauncher script to