Working with Remote Servers

The client-server model employed in Simcenter STAR-CCM+ allows you to start a server on a different machine to the client workspace.

This approach is particularly useful if you wish to set up and monitor a simulation from your workstation but let another machine compute the solution. Starting remote servers requires you to have remote shell access to the remote server machine without password prompting (for example, passwordless ssh). The starccm+ command must be available on each of the remote machines.

By default Simcenter STAR-CCM+ uses ssh as the remote shell program used to launch remote servers. You can use alternative remote shells such as rsh, PuTTY, or a custom shell command that you provide. For a custom shell command, the remote shell specified must conform to the syntax: 

“remote shell command” <HOST> -l <USER>

where HOST is the remote machine to which the remote shell will connect and the username is specified using the -l syntax.

Before Simcenter STAR-CCM+ is launched, you must ensure that the remote shell program can connect to the server without requiring further action by you (such as entering a password or username).

Windows systems do not provide native server-side support for remote shell access. However, you start remote servers from a client running on a Windows machine if an appropriate command, such as PuTTY, is available for Simcenter STAR-CCM+ to use. Before Simcenter STAR-CCM+ is launched, you must ensure that the remote shell program on Windows will connect to the server without requiring further action by you.

Separate sections cover the specifics of starting the server remotely in:

  • Serial with the workspace
  • Serial with the command line
  • Parallel with the workspace
  • Parallel with the command line

You can also log in to the remote machine directly, launch a server from the command line, and then connect to that server from your own machine using the host and port information that the server prints on startup.

Clients may be launched from the command line that connect to specified remote servers.

Dealing With a Protocol Failure

On some Unix based systems there is a limit to the number of open remote shell sessions. If this limit is exceeded, the system may report a protocol failure when starting a remote server or a parallel server. This problem is usually the result of defunct rsh processes and you should first ensure all such processes are killed.

If the problem persists the administrator should ensure the limit on the number of remote processes is not set too low. On Linux systems the file /etc/inetd.conf can be modified to allow more rsh processes per minute. For example, 

shell stream tcp nowait root /etc/tcpd2 in.rshd

to 

shell stream tcp nowait.200 root /etc/tcpd2 in.rshd