Using Remote Simulation on a UNIX or Linux Client

Use the following information to enable and run remote ADS simulations using a UNIX or Linux client. Before starting the client process, you must first set up a server (host) computer on which to run remote simulations.

In this chapter, the term server has the same meaning as host or remote computer, and the term client has the same meaning as local computer.

Note
These procedures are different for the Momentum Electromagnetic simulator. For Momentum remote simulation, refer to "Performing Remote Simulations" in the Momentum documentation.

Remote simulation with a UNIX or Linux client works among the following system pairs:

Setting up Your Simulation Server

Setting up a UNIX or Linux Server

To prepare a UNIX or Linux server (remote computer), perform the following steps:

  1. Log in to the remote computer.
  2. Set the HPEESOF_DIR, PATH, and DISPLAY environment variables as you normally would when running ADS.
    Note
    DISPLAY must be set if you are running ADS Ptolemy simulations with TkPlots in them. This allows the server to display the TkPlots on the client machine.
  3. Set the TCP communication port (socket address) in the server using one of the following methods. This provides the socket address to the hpremote script. If you are unfamiliar with setting socket addresses, see details about these methods in Defining the EMX Daemon Remote Address.
    • Edit the file $HPEESOF_DIR/config/hpeesof.cfg to set the socket address. Add the following line:
      EEDAEMON_SOCKET = xxxx
      where xxxx is the socket address, such as 1537.
    • Edit the file /etc/services to set the socket address. Add the following line:
      eedaemon xxxx/tcp eedaemon
      where xxxx is the socket address, such as 1537.
    • Do not define a socket address, which allows the EMX daemon started by the hpremote script to use the default socket address of 1537. This method may be unreliable.
      Note
      Momentum requires an additional line in the hpeesof.cfg file, which is:
      MOMENTUM_SIM_PATH=<remote_computer_name>
      Refer to the Momentum manual in Simulation > Performing Remote Simulations.
  4. Run the following script on the server:
    hpremote -d /tmp/remote_sim.log
    The -d option is for debugging purposes. It allows you to see the screen messages and save them in the remote_sim.log file for later verification. This file will be stored in the /tmp directory.
    If you get an error message, see Simulator Server Error and Remote Simulation Error.
    To view the last part of the file, use the following command:
    tail -f /tmp/remote_sim.log
  5. You can verify that the hpremote daemon is running by checking the process:
    ps -ef | grep hpeesofemx
    Note
    If another user has already launched the hpremote, then it must not be launched a second time. Subsequent remote users (you in this situation) can connect to this daemon as well. Make sure that the HPEESOF_DIR is set correctly for your simulation.

Setting up a PC Server

To prepare your PC server (remote computer) perform the following steps:

  1. Set the TCP communication port (socket address) in the PC server using one of the following methods. This provides the socket address to the hpremote script. If you are unfamiliar with setting socket addresses, see details about these methods in Defining the EMX Daemon Remote Address.
    • Edit the file $HPEESOF_DIR\config\hpeesof.cfg to set the socket address. Add the following line:
      EEDAEMON_SOCKET = xxxx
      where xxxx is the socket address, such as 1537.
    • Create a new hpeesof.cfg file in the folder C:\users\default\hpeesof\config. Add the line shown in the example above to it.
    • Do not assign a socket address to EEDAEMON_SOCKET. This allows the EMX daemon started by the hpremote script to use the default socket address of 1537. This method may be unreliable.
      Note
      Momentum requires an additional line in the hpeesof.cfg file, which is:
      MOMENTUM_SIM_PATH=<remote_computer_name>
      Refer to the Momentum manual in Simulation > Performing Remote Simulations.
  2. Start the Remote Simulation daemon with the command:
    <HPEESOF_DIR>\bin\hpremote -d remote_sim.log
    from an MS-DOS command prompt or from the Windows > Start > Run menu.
    The -d option is for debugging purposes. It allows you to see the screen messages and save them in remote_sim.log file for later verification. This file will be stored in $HPEESOF_DIR\bin.
    Note
    Do not terminate the MS-DOS window that pops up. Doing so will immediately terminate the daemon as well.

The Server (remote) PC is now ready to run ADS simulations started on a client.

Setting up a UNIX or Linux Client

It is recommended that you first edit the client's hpeesof.cfg file, located in the $HPEESOF_DIR/config directory to include:

EEDAEMON_SOCKET = 1537

Again, while this socket is generally not used, you should make sure 1537 does not appear in the /etc/services file. Also, even though 1537 is the default socket setting within ADS, best practices involve explicitly adding this line in the hpeesof.cfg file. (See Defining the EMX Daemon Remote Address for details.)

A client machine should now be ready to run remote simulation. Do the following:

  1. Start ADS.
  2. Open or create a project.
  3. Open or create a design.
  4. From the Schematic window, choose Simulate > Simulation Setup.
  5. In the dialog box that appears, type in the Host name (or Host's IP address) in the Remote Simulation Host field.
  6. Click on Simulate.

If Remote Simulation succeeds, the Status window will open and show the progression of the simulation.

Whether you need any other setup on the client depends on user preferences and if an OPEN_SIMULATOR error message occurs, see Simulator Server Error.

Using Multiple Servers

Multiple servers may be available on your system. Multiple servers are particularly useful when you intend to compare circuit simulation results as quickly as possible. Once multiple servers are set up, they can be accessed by typing in each name at a client computer, or by generating a listing on a client.

This listing appears when you click the down arrow next to the Remote Simulation Host field. Normally this is a list of one, defaulting to local and no others. However, you may write a list of hosts into the de_sim.cfg file on a client computer. Edit the de_sim.cfg file, located in your $HPEESOF_DIR/config directory, or C:\users\default\hpeesof\config (on PC) or $HOME/hpeesof/config (on UNIX/Linux) directory, to include the following line:

SIMULATION_HOST_LIST=[hostname1] [hostname2]...

where each [hostname] must be separated by a single space. After making this edit, start ADS. From the Schematic window, choose Simulate > Simulation Setup. In the dialog box that appears, click the down arrow just to the right of the Remote Simulation Host field, highlight the host you want, and click the Simulate button.

Automating EMX Daemon Startup

You may want to automate the startup of the EMX daemon each time the workstation boots. This can be done through a resource configuration (RC) script such as the following.

Example of RC Script

The following is an example entry to start hpremote setup:

HPEESOF_DIR=<your installation directory path>
PATH=$HPEESOF/bin:$PATH
if [ -f $HPEESOF_DIR/bin/hpremote ]; then
    hpremote -d /tmp/remote_sim.log & fi

Simulator Server Error

For either a PC or UNIX/Linux server, if you get the following error message when running Remote Simulation on the client:

(send_server_command) OPEN_SIMULATOR
server error

The EMX daemon may not be running on the Server. Check the Server:

Remote Simulation Error

For remote simulations using a UNIX or Linux server, if you receive an error message such as the following when running the hpremote script:

[1] + Stopped (tty output) -hpeesofemx-d remote.log &

this might be an indication that you are running from a shell that does not write messages to tty for a background process (tty gets the terminal name).

In this situation, use the following command in the hpremote script:

hpeesofemx 2>&1 &

Note that this message also appears if you are using remote simulation with Momentum.

Ending Remote Operation

To end a remote operation:

  1. On the local machine, exit ADS.
  2. Terminate the hpeesofemx daemon that is running on the remote server. In Windows, go to the Task Manager and End the Process.
    In UNIX and Linux, to find the process enter the command:
    ps -ef | grep hpeesofemx
    then kill the process using:
    kill -9 <process ID>
    The next time ADS is launched, it will default to simulate locally.

Remote Simulation Restrictions

Please note that the following restriction applies to remote simulation:

In the Momentum simulator, if a substrate computation is required, you must set the $HPEESOF_DIR/momentum/lib/substrates directory and the files under it accessible for reading and writing. However, if you do not do this, the program will warn you.

Defining the EMX Daemon Remote Address

Remote simulation requires fixed socket addresses for the client(s) and server(s) computers. By default, the EMX daemon started by the hpremote script uses a socket address of 1537. However, relying on this default setting may or may not result in a successful remote simulation. Agilent Technologies recommends explicitly setting the socket address using one of the two options below:

Important
Before setting a socket address, ensure that the number is not used in the /etc/services file nor the Windows Services. NIS (Network Information Services) is not supported for setting the EMX daemon socket address, and the address you use must not be used in NIS. To check NIS, use the following command where xxxx is the address:
ypcat services | grep xxxx

Using LSF Remote Simulation

This section describes how to use LSF to perform remote simulations on one or more remote simulation servers.

LSF (Load Sharing Facility) from Platform Computing enables remote simulations with dynamic host selection. ADS integrates this facility to enable automatic remote host selection. Simple swept simulations can also be configured to use many machines available on the network. We call this feature parallel simulation. A simple sweep can be set up to run on a set of machines. LSF is used to select the best machine set. Individual sweep points are run on each machine and results combined into a single dataset on the local machine.

For a machine to participate as a fastest host or in a parallel simulation it must have both LSF and ADS installed. ADS also needs configuration changes to tell it what hosts are available. The feature is configured using the status server configuration file hpeesofsess.cfg.

Note
Momentum Electromagnetic simulator and schematics with layout components do not support LSF remote simulation.

LSF Requirements

Supported Operating Systems for Use as a Server (Host):

Supported Operating Systems for Use as a Client (Local Computer):

Supported LSF Software:

Where to get LSF software:

http://www.platform.com

Where to get LSF documentation:

http://www.platform.com/services/support/docs_home.asp
(requires password)

Note
LSF is used largely to determine suitable hosts for remote simulations. Many of the LSF features, like queuing and priorities, are unused in this release.

Security

Security is minimal. It is assumed that ADS and LSF are being used in a trusted environment. It is possible to accidentally use a different user's UNIX or Linux account when simulating.

Recommendations For Use

Setting Up LSF and ADS

Use the steps in the following sections to set up LSF and ADS.

Preliminary Setup

The following preliminary steps should be taken:

  1. Follow the LSF instructions to set up LSF at your site. Note that LSF servers must be running on every system that you want to use as a possible simulation host. LSF clients must also be running on every system on which ADS will be running. If LSF is not running, ADS will not be able to perform LSF-managed simulations.
  2. Install ADS on every UNIX or Linux system that you want to use as a possible LSF remote simulation host, and install ADS into the same location on each host (or use a symlink at the same location to point to where you actually installed ADS). Alternatively, you can install ADS on one or more centralized servers, and have each UNIX or Linux system access ADS via NFS and symlinks.
    All systems must be able to access ADS using the same directory path. Use symlinks, if necessary, to meet this requirement.

Setting Up Scripts on Each LSF Remote Host

Scripts on each LSF remote simulation host must be configured (if ADS is installed on centralized servers, the following need only be done on each centralized server). Do the following for each remote simulation host:

  1. First, determine a location for a temporary work directory. The default is /tmp. You can use /tmp or /var/tmp, or some other convenient directory. However, you must have enough disk space at this location to hold the data for each LSF-managed intermediate simulation. Be sure this is a local disk with at least 100 MB of free disk space. If you plan on performing large simulations, you'll need more disk space (the more, the better).
    While you do not have to use the same directory location on each LSF remote simulation host. However, using the same directory location (using symlinks if necessary) will greatly simplify configuration in the following steps.
  2. Copy the file, "$HPEESOF_DIR/sess/remote-sim-server", to "$HPEESOF_DIR/custom/config/remote-sim-server" (this destination file should not already exist). Example: 
    cd $HPEESOF_DIR/sess
cp remote-sim-server ../custom/config/remote-sim-server
  3. The newly copied file, "$HPEESOF_DIR/custom/config/remote-sim-server", is a plain shell script. Edit this file and appropriately change the settings of the "HPEESOF_DIR" environment variable to match the correct HPEESOF_DIR value for the current host.
    You must explicitly set the value for HPEESOF_DIR. You cannot rely upon the HPEESOF_DIR environment variable being properly set when this script is run due to the way in which ADS executes this script.
    (If the HPEESOF_DIR variable is set, it will have the value of HPEESOF_DIR for the system on which the ADS graphical user interface is running. This may not be the correct value for HPEESOF_DIR on the remote simulation host, which is the host on which this script will be run.)
    In this script, the default value for HPEESOF_DIR is "/dev/null", which is clearly incorrect; this value was chosen to emphasize the fact that this script must be edited.
    Note that this script allows different platforms (Linux and Solaris) to have different values for HPEESOF_DIR; make sure that you edit the correct occurrence of HPEESOF_DIR for the current platform.
    You must also change the first line of the newly copied file from "#! /bin/sh" to "#! /usr/bin/sh".
  4. Make sure that the newly copied file has execute permission, for example:
    chmod 555 $HPEESOF_DIR/custom/config/remote-sim-server

Editing ADS Configuration Files

Next, on each LSF remote simulation host, one or more ADS configuration files must be edited (if ADS is installed on centralized servers, the following need only be done on each centralized server).

The configuration can be controlled on a system-wide or per-user basis. System-wide configurations affect all users on a system, but are simple to configure; only one file needs to be edited. Per-user configurations affect only a single user, and take precedence over any system-wide configurations; however, you'll have to configure a file for each user. You'll have to decide which is best for you. However, most users will be satisfied with a system-wide configuration.

  1. To set a system-wide configuration, edit (create) the following file, and use steps 2 through 4 to set values in it:

    $HPEESOF_DIR/custom/config/hpeesofsess.cfg

    To set the configuration for a single user, edit (create) the following file, instead, and use steps 2 through 4 to set values in it:

    $HOME/hpeesof/config/hpeesofsess.cfg

  2. By default, LSF-controlled simulations will use all available LSF hosts for remote simulations, and every available host will be used for each simulation. For some sites, there may be issues with this:
    • This assumes that ADS is installed/available on all LSF hosts. Some sites may have ADS installed/available on only a subset of LSF hosts.
      To restrict simulations to a subset of LSF hosts, you must create a list of hosts to which LSF simulations may be submitted. See step 4 in this section, below, for instructions on how to set the LSF_HOSTFILE variable.
    • Some sites may want to limit the number of hosts that a single simulation can use.
      To limit the number of LSF hosts that a single LSF simulation will use, you must set the variable LSF_MAX_HOSTS. Example:
      LSF_MAX_HOSTS = 17
      This will impose a limit of 17 hosts when performing a single LSF simulation. Note that this limit applies to each user's simulation. For example, if two users have a limit of 17, and both perform LSF-controlled simulations, the maximum number of systems used is 34, and not 17.
      If you need to limit both the hosts and the number of hosts, both methods can be used simultaneously.
  3. You must tell ADS the location of the "remote-sim-server" script (from the section on scripts, above) on the remote systems. You do this by setting the variable REMOTE_SIM_SERVER.
    Example: If you installed ADS on the remote systems such that HPEESOF_DIR=/ADS2008, you would add this line to the configuration file (without leading spaces):

    REMOTE_SIM_SERVER = /ADS2008/custom/config/remote-sim-server

    Do not use any environment variables when setting this variable; you must use the actual, absolute path name. In other words, do not use a line such as:

    REMOTE_SIM_SERVER = $HPEESOF_DIR/custom/config/remote-sim-server

    This will not work, and will only cause problems.

  4. If you did not choose /tmp as the temporary work directory (for all systems) in step 1 in the section on scripts, above, you will have to tell ADS about this. If all systems will be using /tmp, you can skip this step.
    You can specify a different temporary work directory for each remote simulation host, or you can specify that the same directory path is to be used on each host. If you want to specify the same temporary work directory path for all remote simulation hosts, you do so by placing a line like the following into the hpeesofsess.cfg file:

    LSF_TMPDIR = /my/tmp/dir

    Replace /my/tmp/dir with the desired name of the temporary work directory. By setting LSF_TMPDIR, you are specifying that this directory path is to be used as the default temporary work directory on all remote simulation hosts.
    If all systems will be using the same path specified by LSF_TMPDIR, you can skip the rest of this step.
    If you need to restrict LSF simulations to a subset of LSF hosts, or if you want to specify different temporary work directory names for some or all of the remote simulation hosts, you must create a file that lists each remote simulation host and the corresponding temporary work directory (if different from the default). However, if you create this file, note that only the systems listed in this file will be used by LSF-controlled simulations.
    This file is specified using the variable LSF_HOSTFILE. Example:

    LSF_HOSTFILE = /my/path/to/some/hostfile

    This file can have any name, and it consists of text lines of the form:

    <system_name> [<temporary_directory_name>]

    Where:

    <system_name> is the name of a remote simulation host, including domain name. In other words, the name must be a fully qualified domain name (FQDN).
    Note that all systems must be within your local domain (the same domain as the system from which ADS is run). You cannot specify systems that are not within your local domain. If you do, ADS may not work properly.
    <temporary_directory_name> is the optional name of the temporary directory to use on the remote simulation host. If this directory is not specified, the value of LSF_TMPDIR will be used, or, if LSF_TMPDIR is not set, /tmp will be used.

    Example (assuming that your domain name is "qptzx.com"):

    system1.qptzx.com              /tmp
system2.qptzx.com              /disk2/tmp
system3.qptzx.com
system4.qptzx.com              /some/disk/foo

    Note that system3 does not have an explicit temporary directory; since one is not specified, the value of LSF_TMPDIR will be used or, if LSF_TMPDIR is not set, /tmp will be used. As only four systems are specified here, the maximum number of LSF-controlled simulations is four (even though there may be more LSF-managed hosts available).
    As mentioned above, only the systems listed in this file will be used for LSF-controlled simulations, and so you must insure that all systems that you want to use are listed here.
    Also, make sure that all temporary working directories are writable.
    The following is an example of an lsf_hosts.cfg file:

    #this is my LSF control file
#Date:8/12/2003
#sirpoh will use /tmp
server.yourcompany.com  /tmp
#no directory specification => jane will use \* => /tmp/parallel.}}
jane.server.yourcompany.com
#joe will use /users/poh/tmp
joe.server.yourcompany.com /users/poh/tmp
#generic temporary directory #specification on a host line
* /tmp/parallel

Configuring Each ADS User

Each user running ADS must be configured. Basically, each user must use a different port number for LSF-controlled simulations; this port number must be manually chosen and manually checked to ensure that the port number is not being used by another user.

Once the port number is chosen, for each user (from a shell prompt) do the following:

mkdir -p $HOME/hpeesof/config echo "EEDAEMON_SOCKET=12345" >> $HOME/hpeesof/config/hpeesof.cfg

where you replace 12345 with the chosen port number.

Verifying the User's $PATH

Before running ADS, the path to the LSF programs must be in each user's $PATH. To verify that LSF is in $PATH, you can run the lshosts command as a test, for example:

lshosts

Here, lshosts should print a list of available LSF-managed hosts.

 

Privacy Statement  | Terms of Use  | Legal | Contact Us  | © Agilent 2000-2008 

Contents
Additional Resources