Specifying Remote hosts

setting up Parallel Processing for Design Exploration

specifying Remote hosts

The settings of the multiple processors involved in Parallel Processing are common to all tools (Batch runs, Optimization, …).

These settings are accessible through the Tools > Advanced menu:

Figure 7: Parallel processing settings from the Tools menu

Note

You can also access these settings through the Tools > Preferences > Simulation menu.

The relevant options in the default state are as follows:

Figure 8: Default Remote Hosts Settings

In this form no remote hosts are specified and you are in Local mode. Batch runs and Design Exploration will use the single local processor. If you click on the Remote radio button the display changes as follows:

Figure 9: The First Stage of Specifying Remote Hosts

The Add button is now active and if you click on it an item is added to the list.

Figure 10: Click on Add

To specify the remote host properly, you must fill in the following fields:

Hostname Hostname	The IP address or the host name of the processor.
Used Used	This is a check box. If checked this processor may be used.
Directory for executable directory for executable	This is the location of the executable that will control the batch run or Design Exploration. Note Normally you do not need to change this if you work under UNIX or Linux, you should read the following section if you work under Windows.

If an STDSIMManager was started on a remote host with a bound port different from the default 40001, you have to indicate this fact in the remote host settings. To do so, append a colon and the defined port number without any white space at the end of the IP address of the host name. For example, to indicate that port 39999 was attached to STDSIMManager started on the remote host whose IP address is 169.254.204.207:

Under Windows: It is essential to expand any AME environment variables for a remote host when it differs from the local host setting. Figure 11: Example of Host Settings

Note that:

• an entry may occur more than once, and this should be the case for a multiprocessor machine (if you want to use N processors of a machine, you should add its entry N times),

• the local host main processor does not need to be added. It will always be there, but

• if the local host is a multiprocessor machine, you would normally add it with an entry for each extra processor.

When this is done, you are ready for your first test. Launch a Batch run or Design Exploration. If all is well you will get something like the following.

Figure 12: Successful Multiprocessor batch run under UNIX

In this case image9 has two processors. Hence it has more work than the other two.

Figure 13: Successful Multiprocessor Design Exploration

In this case image44 has two processors. Hence it has more work than the other one.

However, if there is a problem with any of the remote hosts the whole batch run or Design Exploration may fail and the error messages are not always friendly. If you do get problems the best approach is to work on one remote host at a time. This is done by disabling all but one of the remote hosts as in the following screenshot:

Figure 14: For debugging disable all but one of the hosts

Get this one working and then move on to the next. The key features to check are:

• The folder you are working in is accessible under the same name under all hosts.

• The entries under Host Settings are correct.

Remember:

You can always go back to using the single local processor by checking Local.
It is a good idea to have a maximal set of processors but to selectively disable some according to availability.

Note that these "Remote" settings:

• are defined once and for all (they are saved as preferences in the appropriate Simcenter Amesim files),

• can be disabled simply by selecting the Local radio button,

• your laptop does not necessarily need to be in the list of hosts.

Note

If you aim to perform a single run on a remote host, simply select one host in the list by checking corresponding "used" box.

If you aim to perform a batch run on remote hosts, select as many hosts as you want in the list and check their "used" box.

In the case where the corresponding host would not be accessible (wrong ip/hostname or remote service not set) a message in the log window will be printed indicating which host cannot be reached:

Pathological cases

pathological cases

If you have N hosts: host1, host2, ..., hostN, it is possible to make any one of them the local host. In this situation it may happen that certain combinations do not work fully, but others do. Thus, it might work correctly if host4 is the local host, but fail if you set host2 as the local host. There are various possible reasons for this:

• almost but not quite compatible operating systems;

• the environment or the installation is not quite right on some remote hosts.

Even for an experienced system administrator it can take a lot of effort to track down the problem, so either disable the hosts that refuse to cooperate or stay with the local host that is acceptable to all the remote hosts!