ANSYS Remote Solve Manager User's Guide

(1)

ANSYS Remote Solve Manager User's Guide

ANSYS Release 15.0 ANSYS, Inc. November 2013 Southpointe 275 Technology Drive

Canonsburg, PA 15317 ANSYS, Inc. is

certified to ISO 9001:2008. [email protected] http://www.ansys.com (T) 724-746-3304 (F) 724-514-9494

(2)

ANSYS, ANSYS Workbench, Ansoft, AUTODYN, EKM, Engineering Knowledge Manager, CFX, FLUENT, HFSS and any and all ANSYS, Inc. brand, product, service and feature names, logos and slogans are registered trademarks or trademarks of ANSYS, Inc. or its subsidiaries in the United States or other countries. ICEM CFD is a trademark used by ANSYS, Inc. under license. CFX is a trademark of Sony Corporation in Japan. All other brand, product, service and feature names or trademarks are the property of their respective owners.

Disclaimer Notice

THIS ANSYS SOFTWARE PRODUCT AND PROGRAM DOCUMENTATION INCLUDE TRADE SECRETS AND ARE 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. is certified to ISO 9001:2008.

U.S. Government Rights

For U.S. Government users, except as specifically granted by the ANSYS, Inc. software license agreement, the use, duplication, or disclosure by the United States Government is subject to restrictions stated in the ANSYS, Inc. software license agreement and FAR 12.212 (for non-DOD licenses).

Third-Party Software

See the legal information in the product help files for the complete Legal Notice for ANSYS proprietary software and third-party software. If you are unable to access the Legal Notice, please contact ANSYS, Inc.

(3)

Chapter 1: RSM Overview

The Remote Solve Manager (RSM) is a job queuing system that distributes tasks that require computing resources. RSM enables tasks to be run in background mode on the local machine, sent to a remote machine for processing, or tasks can be broken into a series of jobs for parallel processing across a variety of computers.

Computers with RSM installed are configured to manage jobs using three primary services: The RSM Client service, the Solve Manager service (typically shortened to “Manager”), and the Compute Server service. You use the RSM Client interface to manage jobs.

RSM Clients submit jobs to a queue, and the Manager dispatches these jobs to idle Compute Servers that run submitted jobs. These services and their capabilities are explained in RSM Roles and Termino-logy (p. 1)

The following topics are discussed in this overview:

1.1. RSM Roles and Terminology 1.2. Typical RSM Workflows 1.3. File Handling

1.4. RSM Integration with ANSYS Client Applications

1.1. RSM Roles and Terminology

The following terms are essential to understanding RSM uses and capabilities:

Job

A job consists of a job template, a job script, and a processing task submitted from a client application such as ANSYS Workbench. The job template is an XML file that specifies input and output files of the client application. The job script runs an instance of the client application on the Compute Server(s) used to run the processing task.

Client Application

A client application is the ANSYS application used to submit jobs to RSM, and then solve those jobs as managed by RSM. Examples include ANSYS Workbench, ANSYS Fluent, ANSYS CFX, etc.

Queue

A queue is a list of Compute Servers available to run jobs. When a job is sent to a queue, the Manager selects an idle Compute Server in the list.

Compute Server

Compute Servers are the machines on which jobs are run. In most cases, the Compute Server refers to a remote machine, but it can also refer to your local machine ("localhost").

The Compute Server can be a Windows-based computer or a Linux system equipped with Mono, the open source development platform based on the .NET framework. The job script performs a processing task (such as running a finite element solver). If the job script requires a client application to complete that task, that client application must be installed on the Compute Server.

(8)

Once Compute Servers are configured, they are added to a queue (which can contain multiple Compute Servers). Jobs must specify a queue when they are submitted to a Manager.

RSM Manager

The RSM Manager (also called the “Solve Manager”) is the central RSM service that dispatches jobs to computing resources. It contains a configuration of queues (lists of Compute Servers available to run jobs).

RSM Clients submit jobs to one or more queues configured for the Manager, and their jobs are dispatched to Compute Servers as resources become available.

The RSM administrator decides if users should use the Manager on their local machine or a central Manager, depending on the number of users and compute resources.

RSM Client

The RSM Client is a computer that runs both RSM and a client application such as ANSYS Workbench. RSM enables this computer to off-load jobs to a selected queue.

Code Template

A code template is an XML file containing code files (for example, C#, VB, JScript), references, and support files required by a job. For more information on code templates, see Job Templates.

1.2. Typical RSM Workflows

Any computer with RSM installed can act as the RSM Client, Manager, Compute Server, or any simultan-eous combination of these three functions. This section provides an overview of several configurations of these functions as they are typically seen in RSM workflows . For specific instruction regarding RSM configurations, refer to RSM Service Installation and Configuration (p. 10).

The most effective use of RSM is to designate one computer as the Manager for central management of compute resources. All RSM Clients submit jobs to a queue(s) configured for that Manager, and the Manager dispatches jobs as compute resources become available on Compute Servers.

The following list shows several typical RSM usage workflows:

1. The RSM Client submits jobs using RSM (running locally) directly to itself so that the job runs locally in background mode. Here, the RSM Client, the Manager, and the Compute Server are all on the local ma-chine. This capability is available automatically when you install ANSYS Workbench.

2. The RSM Client submits jobs to the Manager running locally on the same machine. You can assign a remote Compute Server to run the job or split the job between multiple Compute Servers, optionally including your local machine (as depicted in the second workflow below). A remote Compute Server requires RSM

(9)

and the client application to be installed (the client application is typically installed with ANSYS Workbench, which also includes RSM).

3. An RSM Client machine submits jobs to a Manager running on a remote machine (refer to Adding a Remote Connection to a Manager (p. 20)). The remote machine also acts as the Compute Server. This configuration is available automatically when both machines have ANSYS Workbench installed.

4. An RSM Client machine submits jobs to a Manager running on a remote machine. The Manager then assigns the job to a remote Compute Server(s). The RSM Client and the Compute Servers must have ANSYS Workbench installed. You can install ANSYS Workbench on the Manager, or choose to install only standalone RSM software, as described in Software Installation (p. 7).

(10)

1.3. File Handling

Input files are generally transferred from the RSM Client working directory, to the Manager project dir-ectory, and then to the Compute Server working directory where the job is run. Output files generated by the job are immediately transferred back to the Manager’s project storage when the job finishes. The files are stored there until the client application downloads the output files. This section provides more details about how RSM handles files.

Client Application

The location of files on the RSM Client machine is controlled by the client application (for example, ANSYS Workbench). When the RSM Client submits a job to a Manager, it specifies a directory where inputs are found and where output files are placed. Refer to the client application documentation to determine where input files are placed when submitting jobs to RSM.

Input files are copied to the Manager immediately when the job is submitted.

RSM Manager

The RSM Manager creates a project directory as defined in the project directory input from the RSM UI. However, when the Manager is local to the client (i.e., when it is on the same machine as the RSM Client), it ignores the RSM UI setting and creates the directory where the job is saved. The base project directory location is controlled with the Solve Manager Properties dialog (see Modifying Manager Proper-ties (p. 54)). All job files are stored in this location until the RSM Client releases the job. Jobs can also be deleted manually in the RSM user interface.

Compute Server

If the Working Directory property on the General tab of the Compute Server Properties dialog is set to Automatically Determined, the Compute Server reuses the Manager’s project directory as an optim-ization. Otherwise, the Compute Server creates a temporary directory in the location defined in the

Working Directory property on the General tab of the Compute Server Properties dialog. If the Working Directory property is left blank, the system TMP variable is used. When the job is complete,

output files are immediately copied back to the Manager's Project Directory. If the Delete Job Files in

Working Directory check box of the Compute Server Properties dialog is selected (default), the temporary

directory is then deleted.

Linux SSH

When Windows to Linux SSH file transfer is required by security protocols, the Linux Working Directory property on the SSH tab of the Compute Server Properties dialog determines where files are located. If this field is empty, the account’s home directory is used as the default location. In either case, a unique temporary directory is created.

Third-Party Schedulers

When using the RSM job scripts that integrate with third-party schedulers such as LSF, PBS, Microsoft HPC (previously known as Microsoft Compute Cluster), SGE (UGE) , etc., the file handling rules listed in this section apply to the extent that RSM is involved. For more information on integrating RSM with various third-party schedulers, see:

• Compute Server Properties Dialog: Cluster Tab

• Appendix C

• Appendix D

(11)

File Transfer Methods

ANSYS Remote Solve Manager offers different methods of transferring files. The preferred method is OS File Transfer and involves using existing network shares to copy the files using the built-in operating system copy commands. Other methods include native RSM file transfer, SSH file transfer, and complete custom integration. You can also reduce or eliminate file transfers by sharing a network save/storage location.

For more information, see Setting Up RSM File Transfers (p. 21).

1.4. RSM Integration with ANSYS Client Applications

This section discusses RSM compatibility and integration topics related to ANSYS client applications.

For client application-specific RSM instruction, integration, or configuration details, refer to the following resources:

• Submitting Solutions for Local, Background, and Remote Solve Manager (RSM) Processes in the Workbench User's Guide

• For tutorials featuring step-by-step instructions for specific configuration scenarios, go to the Downloads page of the ANSYS Customer Portal. For further information about tutorials and documentation on the ANSYS Customer Portal, go to http://support.ansys.com/docinfo.

• The client application documentation

The following topics are discussed in this section.

1.4.1. RSM Supported Solvers

1.4.2. RSM Integration with Workbench

1.4.1. RSM Supported Solvers

RSM supports the following solvers:

• CFX

• Fluent

• Mechanical (excluding the Samcef solver)

• Mechanical APDL

• Polyflow

1.4.2. RSM Integration with Workbench

Many ANSYS Workbench applications enable you to use RSM; however, the following considerations may apply:

• Some applications may not always work with remote Compute Servers or Managers.

• When a client application is restricted to the RSM Client machine, RSM enables the client application to run in the background.

• When a client application can send jobs to remote Compute Servers, the job may be run completely on RSM Integration with ANSYS Client Applications

(12)

multiple Compute Servers (possibly including the RSM Client machine). In the case where a job is being run in parallel on multiple machines, you need to ensure that the software that controls the parallel pro-cessing is supported on all of the Compute Servers.

(13)

Chapter 2: ANSYS Remote Solve Manager Installation and

Configuration

A general overview of RSM installation and configuration is presented in this chapter.

This section discusses the following installation and configuration topics:

2.1. Software Installation

2.2. Using the ANSYS Remote Solve Manager Setup Wizard 2.3. RSM Service Installation and Configuration

2.4. Setting Up RSM File Transfers

2.5. Accessing the RSM Configuration File

For tutorials featuring step-by-step instructions for specific configuration scenarios, go to the Downloads page of the ANSYS Customer Portal. For further information about tutorials and documentation on the ANSYS Customer Portal, go to http://support.ansys.com/docinfo.

2.1. Software Installation

RSM is automatically installed with ANSYS Workbench products. You can also install RSM by itself if desired. For example, you may want to install RSM by itself on a computer that acts as a dedicated Manager; a Manager requires only an RSM installation for connectivity with remote RSM Clients and Compute Servers. RSM Clients and Compute Servers require ANSYS Workbench, the ANSYS applications you want to run, and RSM. Administrator privileges are not required to install or uninstall RSM on RSM Client machines.

The following RSM installation topics are discussed in this section:

2.1.1. Installing a Standalone RSM Package 2.1.2. Uninstalling 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 (i.e., to install everything necessary to run RSM services and the RSM interface, but without a full ANSYS Workbench installation that includes ANSYS Mechanical, ANSYS Fluent, ANSYS CFX, and ANSYS Polyflow solvers, etc.) 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:

• Under ANSYS Additional Tools, select the ANSYS Remote Solve Manager Standalone Services check box.

(14)

3. Continue the installation process as directed.

Note

When you install a standalone RSM package, this does not mean that RSM services are installed at the same time; you still need to install or start up necessary RSM services. For instructions, see Installing RSM Services for Windows or Installing RSM Services for Linux.

2.1.2. Uninstalling RSM

Uninstall RSM with Workbench

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

Uninstall a Standalone RSM Package

To uninstall a standalone RSM package, run the ANSYS Product Uninstall wizard and select only the

ANSYS RSM check box.

Uninstall a Standalone RSM Package Manually

To uninstall a standalone RSM package manually, first uninstall all RSM services.

• To uninstall RSM services for Windows, see Uninstalling RSM Services for Windows (p. 11).

• To uninstall RSM services started manually for Linux, see Manually Uninstalling RSM Services for Linux (p. 15).

• To uninstall RSM daemon services for Linux, see Uninstalling RSM Automatic Startup (Daemon) Services for Linux (p. 17).

After the services have been uninstalled, delete the RSM installation directory.

2.2. Using the ANSYS Remote Solve Manager Setup Wizard

The ANSYS Remote Solve Manager Setup Wizard is a new utility that guides you through the process of setting up and configuring Remote Solve Manager; instead of using manual setup processes, you can launch the wizard and follow its instructions for each part of the setup. Depending on the RSM Layout you intend to use, you may need to run the wizard on multiple machines. The wizard will walk you through the following setup tasks:

• Start RSM services

Note

– The creation of shared directories needed for use with a commercial cluster is performed as part of the Wizard configuration.

(15)

– To start RSM services when UAC is enabled on Windows 7, you must launch the wizard using the right-click Run as administrator menu option. For instructions on enabling or disabling UAC, see RSM Troubleshooting (p. 99).

• Configure the machines to be included in your RSM Layout

• Perform various cluster configuration tasks

• Integrate RSM with the following third-party job schedulers (without requiring job script customization):

– LSF (Windows and Linux)

– PBS (Linux only)

– Microsoft HPC

– SGE (UGE)

• Create and share RSM directories (Project Directory, Working Directory, and where applicable, Shared Cluster Directory)

• Define queues

• Create accounts

• Test the final RSM configuration

To launch the RSM Setup Wizard:

• For Windows: Select Start > All Programs > ANSYS 15.0 > Remote Solve Manager > RSM Setup

Wizard 15.0. Alternatively, you can navigate to the [RSMInstall]\bin directory and double-click Ans.Rsm.Wizard.exe.

• For Linux: Open a terminal window in the [RSMInstall]\Config\tools\linux directory and run rsmwizard.

1. Log into the machine that will serve as the Manager. If you are configuring a cluster, this is the head node of the cluster.

• For Windows, you must either have Windows administrative privileges on the Manager, have RSM administrative privileges (as a member of the RSM Admins user group), or launch the wizard via the right-click Run as administrator menu option.

• For Linux, you must log in with root privileges or have non-root administrative privileges. (“Non-root administrative privileges” means that you are a member of the rsmadmins user group. Before you run the wizard, your IT department must create the rsmadmins user group and manually add any users who will be starting/running non-daemon services.)

2. Launch the wizard:

Note that the wizard requires different privileges for different parts of the RSM setup process. For details on necessary permissions, see Prerequisites for the RSM Setup Wizard (p. 105).

(16)

For detailed information on the wizard’s requirements, prerequisites, and capabilities, see Ap-pendix A (p. 103).

For a quick-start guide on using the wizard, see the Readme file. To access this file:

• For Windows: Select Start > All Programs > ANSYS 15.0 > Remote Solve Manager > Readme

-RSM Setup Wizard 15.0.

• For Linux: Navigate to the [RSMInstall]\Config\tools\linux directory and open rsm_wiz.pdf.

For more detailed information on the wizard’s capabilities, prerequisites, and use, see Appendix A (p. 103).

2.3. RSM Service Installation and Configuration

This section includes instructions for installing and configuring RSM services for Windows or Linux ma-chines.

2.3.1. Installing and Configuring RSM Services for Windows 2.3.2. Installing and Configuring RSM Services for Linux 2.3.3. Configuring a Multi-User Manager or Compute Server 2.3.4. Configuring RSM for a Remote Computing Environment

2.3.1. Installing and Configuring RSM Services for Windows

The following RSM configuration topics for Windows are discussed in this section:

2.3.1.1. Installing RSM Services for Windows

On a Windows machine, you can configure RSM services to start automatically at boot time by running the RSM startup script for Windows. You can also uninstall and restart the services by running the script with adding command line options.

Note

• RSM services cannot be started from a network installation. It is recommended that you install RSM on a local machine.

• For GPU requirements when Windows is installed as a service, see GPU Requirements in the Installation and Licensing Documentation.

RSM Command Line Options for Windows

By adding the following command line options to the end of an RSM service script, you can specify what service or services you wish to configure.

-mgr

Command line option for applying the command to the Manager service.

-svr

(17)

If you use both options with the selected script, the script will be applied to be both services.

Configuring RSM Services to Start Automatically at Boot Time for Windows

To configure RSM services to start automatically at boot time, run the AnsConfigRSM.exe script.

1. Log into a Windows account with administrative privileges.

2. Ensure that Ans.Rsm.* processes are not running in the Windows Task Manager.

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

4. Enter the AnsConfigRSM.exe script into the command line, specifying the service by using the appro-priate command line options. The examples below show how to configure both services, the Manager service only, or the Compute Server service only.

AnsConfigRSM.exe -mgr -svr

AnsConfigRSM.exe -mgr

AnsConfigRSM.exe -svr

5. Run the command.

Note

Windows 7 users may need to select the Run as administrator option.

If the RSM services have been removed, you can also use the above sequence of steps to reconfigure the services.

Uninstalling RSM Services for Windows

To unconfigure (remove) all RSM services, run the AnsUnconfigRSM.exe script.

1. Log into a Windows account with administrative privileges.

2. Ensure that Ans.Rsm.* processes are not running in the Windows Task Manager.

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

4. Enter the AnsUnconfigRSM.exe script into the command line.

5. Run the command.

Note

• If you using a Windows 7 operating system, you may need to select the Run as

adminis-trator option from the right-click context menu.

• The uninstaller can only stop services which were started by and are owned by the user performing the uninstall.

(18)

2.3.2. Installing and Configuring RSM Services for Linux

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

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

2.3.2.3. Additional Linux Considerations

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

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

SSH communication Native communication

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

Uses RSM application to execute commands and copy data to/from Compute Servers

Protocol Type

Requires installation of SSH client (Putty SSH) on the RSM Client machines (see

Appendix B) Requires RSM to be installed and

running on the Compute Server (see

Starting RSM Services Manually for Linux (p. 13))

Installation Require-ments

Communication overhead slows solution process launch and retrieval of results Most efficient data transfer for

solu-tion process launch and retrieval of results

Data Transfer Effi-ciency

Supported on all platforms Supported on Windows & Linux only

Platform Support

ANSYS recommends that you use native communication where possible, and use SSH where platform support or IT policy requires it.

Configuring Native Cross-Platform Communications

In RSM, it is possible to configure a Linux machine for native mode communications. For performance reasons, native mode is the recommended method for cross-platform RSM communications; SSH should only be used if your IT department requires it.

With native mode, a Linux Compute Server has RSM installed and running locally, so the SSH protocol isn’t needed to provide communications between a Windows Compute Server and a Linux Compute Server. You can configure native mode communications by performing either of the following options on the Linux machine:

• OPTION A: Run the ./rsmmanager and ./rsmserver scripts to manually start the Manager and Compute Server services. Refer to Starting RSM Services Manually for Linux (p. 13) for more information.

• OPTION B: Configure RSM to start the Manager and Compute Server services at boot, as described in

Starting RSM Services Automatically at Boot Time for Linux (p. 15).

Adding Common Job Environment Variables for Native Jobs

Before installing and starting the RSM service on Linux, you can edit the rsm_env_profile file under the [RSMInstall]/Config/tools/linux directory. In this file, you can add any common job environment variables for native jobs to run. For example, you can use this file to source environment

(19)

RSM service and native jobs should inherit these environments when any job is run. It is useful to be able to set common environment variables in a single place instead of having to set them up on each job user's .cshrc or .profile file from the 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 (e.g. LSF, SGE/UGE). # If defined, RSM service and jobs should then inherit this environment when a job is run.

# . /home/batch/lsf7.0/conf/profile.lsf

# . /home/batch/SGE6.2u2/default/common/settings.sh

2.3.2.2. Installing RSM Services for Linux

The following related topics are discussed in this section:

2.3.2.2.1. Starting RSM Services Manually for Linux

2.3.2.2.2. Starting RSM Services Automatically at Boot Time for Linux

2.3.2.2.1. Starting RSM Services Manually for Linux

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

rsmmanager

Starts the Manager service.

rsmserver

Starts the Compute Server service.

rsmxmlrpc

Starts the XmlRpcServer service (required for EKM servers only).

These scripts are generated as part of the RSM installation process and are located in the

WBIn-stallDir/RSM/Config/tools/linux directory. If for some reason these scripts were not generated during installation or are for other reasons not available, you can generate them yourself. For instructions, see Generating RSM Service Startup Scripts for Linux (p. 99) in the RSM Troubleshooting (p. 99) section.

Important

When installing RSM services, you must determine whether you want to start the RSM services manually via the startup scripts or want to install the RSM services as daemons (i.e., start the service automatically when the machine is booted). Only one method of these methods should be used.

Important

For security reasons, it is recommended that you do not start and run RSM service processes manually as the "root" user. If you want to configure the process of installing RSM to a

(20)

user Linux machine, the recommended practice is to install it as a daemon. See Starting RSM Services Automatically at Boot Time for Linux (p. 15).

Note

Note that when RSM services are started manually, the RSM services run as a process for the user who initiated the services. RSM services that were started manually are stopped each time the machine is rebooted; after a reboot, before you submit any jobs to RSM you must first restart the RSM services by running the appropriate startup scripts. If you’d prefer to start the services automatically when the machine is booted, you can configure daemons as described in Starting RSM Services Automatically at Boot Time for Linux (p. 15).

2.3.2.2.1.1. Manually Running RSM Service Scripts for Linux

You can run the RSM service scripts to manually start, stop, check the status of, and restart RSM services.

Starting an RSM Service Manually

You can start any of the three RSM services manually by running the appropriate service script with the command line option start. The examples below illustrate how to start each of the RSM services manually:

./rsmmanager start

./rsmserver start

./rsmxmlrpc start

Stopping an RSM Service Manually

You can stop any of the three RSM services manually by running the appropriate service script with the command line option stop. The examples below illustrate how to start each of the RSM services manually:

./rsmmanager stop

./rsmserver stop

./rsmxmlrpc stop

Checking the Status of an RSM Service Manually

You can check the status of any of the three RSM services manually by running the appropriate service script with the command line option status. The examples below illustrate how to check the status of each of the RSM services manually:

./rsmmanager status

./rsmserver status

./rsmxmlrpc status

Restarting an RSM Service Manually

You can restart any of the three RSM services manually by running the appropriate service script with the command line option restart. The examples below illustrate how to restart each of the RSM services manually:

./rsmmanager restart

./rsmserver restart

(21)

2.3.2.2.1.2. Manually Uninstalling RSM Services for Linux

1. Log into a Linux account with administrative privileges.

2. Ensure that Ans.Rsm.* processes are not running.

3. Open a terminal window in the RSM/Config/tools/linux directory.

4. Enter the rsmunconfig script into the command line, as shown below:

tools/linux#> ./rsmunconfig

5. Run the script.

Note

The uninstaller can only stop services which were started by and are owned by the user performing the uninstall.

2.3.2.2.2. Starting RSM Services Automatically at Boot Time for Linux

You can configure RSM services to start automatically when the machine is booted by configuring them as “daemon” services (if the services are not configured to start automatically, they must be started manually, as described in Starting RSM Services Manually for Linux (p. 13)). 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.3.2.2.2.1. Installing RSM Automatic Startup (Daemon) Services for Linux 2.3.2.2.2.2. Working with RSM Automatic Startup (Daemon) Services for Linux 2.3.2.2.2.3. Uninstalling RSM Automatic Startup (Daemon) Services for Linux

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

Security Requirements for Daemon Service Configuration

To install RSM services as daemons, you must have system administrative permissions (i.e., you must be logged in and installing as a “root” user or “sudoer”).

For security reasons, it is recommended that you do not run RSM services as the root user. Many Linux OS only allow root users to listen to specific ports, so the ports that are required by the RSM Solve Manager and Compute Server services may be blocked by system administration. For these reasons, the RSM daemon service installation will create a non-root user account with no logon called rsmadmin; the account is a member of the rsmadmins user group, and has a home directory of /home/rsmadmin. The RSM daemon service will then be run by the rsmadmin user.

Note

The RSM daemon service installation will only create the rsmadmin user account if the account does not already exist. The same is true for the rsmadmins user group if the group name does not exist. The account/group will be created locally on the computer on which the RSM service(s) will be run. If you want the account/group to be managed in the master server by

(22)

Network Information Service (NIS), you need to ask your IT department to create an rsmadmin user account and rsmadmins group from NIS before running RSM daemon service scripts.

Note

When an RSM package is installed under a directory, please make sure that all its parent directories (not the files in the directory) have both read and execution permissions so that the RSM service executable can be started by a non-root user.

Daemon Service Installation Methods

There are two ways to install RSM services as daemons: by running the rsmconfig script, or by running the install_daemon script. The difference between the two methods is that whereas the

rsmconfig script always generates fresh service scripts before starting the service installation, the install_daemon script assumes that the service scripts are always available in the

WBIn-stallDir/RSM/Config/tools/linux directory and uses the existing scripts for service installation, allowing the system administrator to perform advanced script customizations before the services are installed.)

Both scripts are located in the RSM/Config/tools/linux directory and have the same command line options.

tools/linux#> ./rsmconfig -help Options:

-mgr: Install RSM Job Manager service. -svr: Install RSM Compute Server service. -xmlrpc: Install RSM XML-RPC Server.

tools/linux# ./install_daemon

Usage: ./install_daemon [-mgr] [-svr] [-xmlrpc] Options:

-mgr: Install RSM Job Manager service. -svr: Install RSM Compute Server service. -xmlrpc: Install RSM XML-RPC Server.

Installing RSM Services as Daemons

To install RSM services as daemon services, run either the rsmconfig script or the install_daemon script, as follows:

1. Log into a Linux account with administrative privileges.

2. Ensure that Ans.Rsm.* processes are not running.

3. Open a terminal window in the RSM/Config/tools/linux directory.

4. Enter the script into the terminal window.

5. Add the appropriate command line options (-mrg,-svr, or -xmlrpc).

6. Run the command.

The two examples below show the command line used to configure the Manager and Compute Server service daemons via either the rsmconfig or the install_daemon script.

(23)

Once the daemon service is installed, the RSM service will be started automatically without rebooting. The next time when the machine is rebooted, the installed RSM service will be started automatically.

Verifying the RSM Daemon Installation

To verify that the automatic boot procedure is working correctly, reboot the system and check to see that the services are running by typing the appropriate ps command and looking for Ans.Rsm in the resulting display:

ps aux | grep Ans.Rsm

2.3.2.2.2.2. Working with RSM Automatic Startup (Daemon) Services for Linux

Once an RSM daemon service is configured, any user can check the status of the service. System admin-istrators can also start or restart the service.

Stopping the Daemon Service

To stop the daemon service:

./etc/init.d/rsmmanager150 stop

Checking the Status of the Daemon Service

To check the status of the daemon service:

./etc/init.d/rsmmanager150 status

Restarting the Daemon Service

To restart the daemon service:

./etc/init.d/rsmmanager150 restart

2.3.2.2.2.3. Uninstalling RSM Automatic Startup (Daemon) Services for Linux

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

Uninstalling All RSM Daemon Services

To uninstall all RSM daemon services, run the rsmunconfig script (without command line options). The script is located in the WBInstallDir/RSM/Config/tools/linuxdirectory.

The example below shows the command line used to uninstall all RSM service daemons.

tools/linux#> ./rsmunconfig

Uninstalling Individual RSM Daemon Services

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

tools/linux# ./uninstall_daemon

Usage: ./uninstall_daemon [-mgr] [-svr] [-xmlrpc] [-rmadmin] Options:

-mgr: Uninstall RSM Job Manager service. -svr: Uninstall RSM Compute Server service. -xmlrpc: Uninstall RSM XML-RPC Server.

-rmadmin : Remove 'rsmadmin' user and 'rsmadmins' group service account.

(24)

The example below shows the command line used to uninstall Solve Manager and Compute Server service daemons via the uninstall_daemon script.

tools/linux#> ./uninstall_daemon -mgr -svr

Removing the Administrative User Account and Service Group Manually

By default, the rsmunconfig script does not remove the rsmadmin user account and rsmadmins user group that were created earlier when service was configured. This allows the same account and user group to be reused for the next service installation and configuration, and also prevents the acci-dental deletion of important files from the rsmadmin home directory (/home/rsmadmin).

However, if you decide that you do not want to keep the user account and user group, you can remove them manually by adding the -rmadmin command line option to the uninstall_daemon script.

tools/linux#> ./uninstall_daemon -rmadmin

Important

The service account and group cannot be deleted if one or more RSM services are still being run by that user account and service group name. You will be prompted to answer “Yes” or “No” from the above command when there is no service is being run by these accounts and RSM is trying to delete them.

2.3.2.3. Additional Linux Considerations

When running RSM on Linux, the following considerations apply:

Linux Path Configuration Requirements

The RSM job scripts that integrate with Linux using PuTTY SSH require you to set AWP_ROOT150 in the user's environment variables. If the job is not running properly, check the job log in the Job Log view for "Command not found". Remote command clients like PuTTY SSH use the remote account's default shell for running commands. For example, if the account's default shell is CSH, the following line needs to be added to the .cshrc file (path may be different for your environment):

setenv AWP_ROOT150 /ansys_inc/v150

Note

• ~ (tilde) representation of the home directory is not supported for use in RSM paths (for example, the Working Directory in the Compute Server Properties dialog).

• Different shells use different initialization files than the account's home directory and may have a different syntax than shown above. Refer to the Linux man page for the specific shell or consult the machine administrator.

RSH/SSH Settings for Inter/Intra-Node Communications

The Use SSH protocol for inter- and intra-node communication (Linux only) property, located on the General tab of the Compute Server Properties dialog, determines whether RSM and solvers use RSH or SSH for inter-node and intra-node communications on Linux machines. When Fluent, CFX,

(25)

Mechanical, and Mechanical APDL are configured to send solves to RSM, their solvers will use the same RSH/SSH settings asRSM.

Explicit Dynamics Systems

RSM does not support Linux connections for Explicit Dynamics systems. Only Windows-to-Windows connections are currently supported.

2.3.3. Configuring a Multi-User Manager or Compute Server

When configuring RSM on a single machine used by multiple users to submit RSM jobs, follow these guidelines:

• All RSM users should have write access to the RSM working directory. The default working directory may not function properly if write permissions are not enabled for all applicable users.

• All RSM users should cache their account password (refer to Working with Account Passwords (p. 48)). If all users do not cache their password, only the user that started RSM on the machine can submit jobs.

• When installing RSM to a multi-user Linux machine, ANSYS strongly recommends that you set up RSM as a daemon (see Starting RSM Services Automatically at Boot Time for Linux (p. 15)). Running RSM as a daemon allows you to maintain consistent settings. If RSM is not run as daemon, the settings vary depend-ing on which user first starts RSM processes.

• If you are running ANSYS Workbench on a multi-user RSM machine, the My Computer, Background option that is available for ANSYS Mechanical (see Using Solve Process Settings in the ANSYS Mechanical User's Guide) will likely not function as expected with Rigid Dynamics or Explicit Dynamics due to write permissions for RSM working directories. As a workaround for this issue, follow these guidelines:

– Ensure that Manager and Compute Server (ScriptHost) processes always run under the same user account. This will ensure consistent behavior.

– Do not use the built-in ‘My Computer’ or ‘My Computer Background’ solve process settings.

– Add a remote Solve Process Setting that specifies that the Manager name is the machine name, rather than localhost. For more information, see Using Solve Process Settings in the ANSYS Mechanical User's Guide.

– To run more than one job simultaneously, adjust the Max Running Jobs property in the Compute Server Properties dialog.

2.3.4. Configuring RSM for a Remote Computing Environment

You must configure RSM Clients to work with Managers and Compute Servers on remote computers. If RSM services are run across multiple computers, refer to the following RSM configuration procedures:

2.3.4.1. Adding a Remote Connection to a Manager 2.3.4.2. Adding a Remote Connection to a Compute Server

2.3.4.3. Configuring Computers with Multiple Network Interface Cards (NIC)

Note

When communicating with a remote computer, whether RSM Client to Manager or Manager to Compute Server, RSM services must be installed on those computers.

(26)

2.3.4.1. Adding a Remote Connection to a Manager

RSM Clients can monitor and configure multiple Managers. The following steps describe how to add a remote connection to a Manager on a remote computer:

1. Launch RSM.

2. In the RSM main window select Tools > Options. The Options dialog appears.

3. In the Name field, enter the name of a remote machine with the Manager service installed.

4. Select the Add button and then OK. The Manager and all of its queues and Compute Servers appear in the tree view.

5. Passwords are cached on the Manager machine, so you must set the password again. Refer to Working with Account Passwords (p. 48) for this procedure.

2.3.4.2. Adding a Remote Connection to a Compute Server

To use compute resources on a remote Compute Server, the Manager machine must add a new Compute Server as described in Adding a Compute Server (p. 55), and then configure remote Compute Server connections with the following considerations:

• If the Compute Server is running Windows, only the machine name is required in the Display Name property on the General tab of the Compute Server Properties dialog.

• If the Compute Server involves integration with a Linux machine or another job scheduler, refer to

Appendix B for integration details.

• Ensure that you have administrative privileges to the working directory of the new Compute Server.

• Always test the configuration of a connection to a new remote Compute Server after it has been created, as described in Testing a Compute Server (p. 70).

2.3.4.3. Configuring Computers with Multiple Network Interface Cards (NIC)

When multiple NIC cards are used, RSM may require additional configuration to establish desired com-munications between tiers (i.e., the RSM Client, Manager, and Compute Server machines).

The most likely scenario is that the issues originate with the Manager and/or Compute Server. First, try configuring the Manager and/or Compute Server machine(s):

1. In a text editor, open the Ans.Rsm.JMHost.exe.config file (Manager) and/or Ans.Rsm.SH-Host.exe.config file (Compute Server). These files are located in Program Files\ANSYS Inc\v150\RSM\bin.

2. To both files, add the machine’s IP address to the TCP channel configuration. Substitute the machine’s correct IP address for the value of machineName. The correct IP address is the address seen in the output of a “ping” from a remote machine to the Fully Qualified Domain Name (FQDN).

(27)

4. Restart the following services:ANSYS JobManager Service V15.0 and ANSYS ScriptHost Service V15.0.

• For Windows: On your Administrative Tools or Administrative Services page, open the Services dialog. Restart the services by right-clicking on the service and selecting Restart.

• For Linux: Log into a Linux account with administrative privileges and ensure that Ans.Rsm.* processes are not running. Open a terminal window in the [RSMInstall]/Config/tools/linux directory

and run the following command: ./rsmmanager restart

If the Manager and/or Compute Server does not resolve the problem, the RSM Client machine may have multiple NICs and require additional configuration. For example, a virtual NIC used for a VPN connection on an RSM Client machine can cause a conflict, even if not connected.

If configuring the Manager and/or Compute Server machines doesn’t work, configure the Multi-NIC RSM Client machine:

1. Using a text editor, create a file named Ans.Rsm.ClientApi.dll.config in Program Files\ANSYS Inc\v150\RSM\bin. If this file does not exist, RSM uses a default configuration.

2. From this file, copy and paste from the text below into Ans.Rsm.ClientApi.dll.config:

<?xml version="1.0" encoding="utf-8" ?> <configuration>

<system.runtime.remoting> <application>

3. Replace the contents of ip_address with a valid IP address.

4. Save and close the file.

2.4. Setting Up RSM File Transfers

ANSYS Remote Solve Manager offers different methods of transferring files. The preferred method is

OS File Transfer and involves using existing network shares to copy the files using the built-in operating

system copy commands. Other methods include native RSM file transfer, SSH file transfer, and complete custom integration. You can also reduce or eliminate file transfers by sharing a network save/storage location.

One of these methods will be used when you are submitting a job to a remote machine. For details on each method or how to eliminate file transfers, see:

2.4.1. Operating System File Transfer Utilizing Network Shares

2.4.2. Eliminating File Transfers by Utilizing a Common Network Share 2.4.3. Native RSM File Transfer

2.4.4. SSH File Transfer

2.4.5. Custom Client Integration

(28)

2.4.1. Operating System File Transfer Utilizing Network Shares

RSM file transfer provides the ability to use the Operating System (OS) Copy operation. The OS Copy operation can be significantly (up to 5 times) faster than the native file transfer used in the RSM code (as described in Native RSM File Transfer (p. 28)). OS Copy is a faster and more efficient method of file transfer because it utilizes standard OS commands and NFS shares. Typically, the client files are local to the Client machine and are only transferred to the remote machines to solve because of storage speed, capacity, and network congestion concerns.

No specific configuration is necessary within RSM itself. To enable the OS Copy operation, you must configure the directories that will be involved in the file transfer so that the target directory is both visible to and writable by the source machine. Generally, the target directories involved are:

• The Project Directory on the Manager machine (as specified in the Solve Manager Properties dialog)

• The Working Directory on the Compute Server machine (as specified in the Compute Server

Properties dialog)

Once the configuration is complete, the RSM Client machine should be able to access the Project

Dir-ectory on the Manager machine and the Manager machine should be able to access the Working Directory on the remote Compute Server machine. The OS Copy operation will be used automatically

(29)

If two RSM services are on the same machine, no configuration is necessary for OS Copy to function between those two services. For example, in an RSM layout where the RSM Manager and Compute Server are on the same machine, the Client is running on a separate machine, the RSM Manager can access the Working Directory, as long as the permissions are set to allow it. In this case, the only other configuration necessary is to ensure that the RSM Client can access the Manager’s network shared

Project Directory on the remote machine.

The steps for configuring directories for the OS Copy operation, discussed in the following sections, are different between Linux and Windows.

Note

For the sake of general applicability, the configuration instructions in the following sections assume an RSM layout in which each service runs on a separate machine. In a typical envir-onment, however, ANSYS suggests that the Manager and Compute Server be on the same machine.

Related Topics:

2.4.1.1. Windows-to-Windows File Transfer 2.4.1.2. Linux-to-Linux File Transfer

2.4.1.3. Windows-to-Linux File Transfer 2.4.1.4. Verifying OS Copy File Transfers

2.4.1.1. Windows-to-Windows File Transfer

System Administrator permissions are required to configure directories for Windows-to-Windows OS Copy file transfers.

For Windows-to-Windows file transfers, RSM uses predefined share names to locate and identify the target directories. You must perform the following setup tasks for each of the target directories:

• Share the target directory out to the remote machine.

• Provide full read-write permissions for the shared directory.

Perform these steps for each of the target directories:

1. In Windows Explorer, right-click on the target directory.

This is the directory you want to make visible for the OS Copy operations: either the Manager

Project Directory or the Compute Server Working Directory.

2. Select the Sharing tab and click Share.

3. Click the Advanced Sharing button.

4. In the Advanced Settings dialog, click Share this Folder and enter the correct name for the share, as shown below.

• For the Project Directory on the Manager machine, enter RSM_Mgr.

For example, the directory C:\Projects\ProjectFiles may have a share named

\\winmachine06\RSM_Mgr.

(30)

• For the Working Directory on the Compute Server machine, enter RSM_CS.

For example, the directory D:\RSMWorkDir may have a share named \\winma-chine2\RSM_CS.

5. Ensure that full read-write permissions are defined for the target directory.

6. This naming requirement applies only to the network share for the target directory; the directory itself can have a different name.

Note

Once target directory is shared, you can access it by typing the share path into Windows Explorer.

7. Perform these steps for the other target directory.

2.4.1.2. Linux-to-Linux File Transfer

Root permissions are required to configure directories for Linux-to-Linux OS Copy file transfers.

For Linux-to-Linux file transfers, RSM uses mount points to locate and identify the target directories. You must configure each of the target directories by performing the following setup tasks:

1. Ensure that the target directory belongs to a file system that is mounted, so that the target directory is visible to the machine on which the source directory is located. Use the full path for the target directory.

2. Provide full read-write privileges for the target directory.

2.4.1.3. Windows-to-Linux File Transfer

Root permissions on the Linux machine are required to configure directories for Windows-to-Linux OS Copy file transfers.

For Windows-to-Linux transfers (using Samba or a similar Linux utility), entries in the Samba configuration file map the actual physical location of the Linux target directories to the predefined Windows share names that RSM uses to locate and identify the target directories. The following example shows how to configure a Samba share on Linux for the target directories RSM requires for the OS Copy operation. If you are unable to create the share, contact your IT System Administrator for assistance with this step.

Edit the smb.conf Samba configuration file to include definitions for each of the Linux target direct-ories. The example below shows Samba’s default values for the Linux target directdirect-ories.

[RSM_Mgr] path = /home/staff/RSM/ProjectDirectory browseable = yes writable = yes create mode = 0664 directory mode = 0775 guest ok = no [RSM_CS]

(31)

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 directories. The path for the

Project Directory should match the Project Directory path defined in the Solve Manager Properties

dialog. The path for the Working Directory should match the Working Directory path defined in the

Compute Server Properties dialog.

After making your changes to smb.conf, restart the Samba server by running the following command:

/etc/init.d/smb restart

Note

The locations of files and method of restarting the Samba service may vary for different Linux versions.

Verify that the Samba shares are accessible by your Windows machine, indicating that they have been properly set up. Check this by using Windows Explorer and navigating to the locations shown below (using your specific machine name in place of linuxmachinename):

• \\linuxmachinename\RSM_Mgr for the Project Directory on the Manager machine

• \\linuxmachinename\RSM_CS for the Working Directory on the Compute Server machine

Additional Windows-to-Linux Configuration When Using Alternate Accounts

A permissions issue can occur when an alternate account is used to run jobs on the Linux side. To resolve this issue, make sure that Samba (or a similar Linux utility) is correctly configured.

The following code sample is from the Samba configuration file,smb.conf, showing a configuration for file sharing between three accounts:

• A Windows account mapped to a Linux account

• An alternate account

• An account that runs as the RSM service

[RSM_CS] path = /lsf/wbtest browseable = yes writable = yes create mode = 0666 directory mode = 0777 guest ok = no create mode:

The Samba default is 664, which corresponds to rw-rw-r--. If the alternate account is not in the same group as the owner of the file, the job cannot write to the file and an error occurs for files that are both inputs and outputs.

(32)

To provide full read-write access for all the accounts, set create mode to 666, as shown above in the code sample. This sets the permissions for files that are copied from Windows to Linux to

rw-rw-rw, allowing all accounts to both read from and write to the file. directory mode:

The Samba default is 775. If the copy from Windows to the Samba share results in the creation of direct-ories, a value of 775 prevents the job running under the alternate account from creating files in the newly copied subdirectories.

To allow the job to create files in the new subdirectories, set directory mode to 777.

After making your changes to smb.conf, restart the Samba server as shown above.

Note

The locations of files and method of restarting the Samba service may vary for different Linux versions.

2.4.1.4. Verifying OS Copy File Transfers

After configuring a target directory for sharing, you can run a test server operation. Information about the method used for file transfer is written to the job log in the RSM Job Log view and can be used to verify whether RSM files are being transferred via the OS Copy operation:

In the job log, the messages “Manager network share is available” and “Compute Server network share is available” indicate that all necessary directories are visible and OS Copy is being used.

2.4.2. Eliminating File Transfers by Utilizing a Common Network Share

Even though Workbench projects are typically run locally, small projects or larger models utilizing ex-ceptional networks and file systems that exist today can allow Workbench projects to be saved and opened from a network share. When using a shared Workbench storage location, this shared folder can be used to minimize file transfers. In particular, this can be used to remove the necessity of transferring files to and from the Client machine and the remote machine(s); ideally, this storage would be directly attached to the Compute Server(s).

RSM places marker files in the RSM Client, Manager, and Compute Server directories to uniquely identify the job.

• If the Manager finds the RSM Client’s marker in the project storage area (by recursively searching subfolders), it will use that folder rather than copying the files to a separate folder.

• Similarly, if the Compute Server finds the Manager’s marker (by recursively searching subfolders), it will also use that location rather than copying files unnecessarily.

Remember that while this leverages drivers at the operating system level which are optimized for network file manipulation, files are still located on remote hard drives. As such, there will still be significant

network traffic, e.g. when viewing results and opening and saving projects. Each customer will have to determine the RSM configuration that best utilizes network resources.

The Client must be able access the Client Directory under the RSM Manager Project Directory. The Manager must have access to its sub-folders, including the RSM Client Directory and the shared

(33)

Compute Server Working Directory. One or both of these directories will be under the shared Manager

Project Directory in this setup.

Example: You can set up RSM to use file shares in order to remove unnecessary file transfers. For example,

you might have a Linux share \usr\user_name\MyProjectFiles\, and have that same folder shared via Samba or a similar method and mounted on the Windows Client machine as Z:\MyPro-jectFiles\. If you save your Workbench projects to this network location, you can set the Manager and Compute Server properties as follows in order to remove all file transfers and use the network share directly as the working directory:

• Manager

– For a Linux-based Manager, set the Project Directory Location property to

\user\user_name\MyProjectFiles\.

– For a Windows-based Manager, set the Project Directory Location property to Z:\MyProject-Files\.

• Compute Server

– For a Linux-based Compute Server, set the Working Directory Location property to

\user\user_name\MyProjectFiles\.

– For a Windows-based Compute Server, set the Working Directory Location property to Z:\MyProjectFiles\.

ANSYS Remote Solve Manager User's Guide