************************************* *** Frequently Asked Questions *** *** Tracking/Steering Library *** ************************************* 1. What is the Steering Library ? The Steering Library provides tools for a host machine to communicate with the PARAGON machines, collect data from compute processes running on the PARAGON, and alter specified parameters to provide an interactive capability. The communication is done in a non-interrupt fashion i.e. the compute processes only respond and participate to the extent they so wish. A client (or several clients) can connect to the server any number of times without disturbing the server. 2. What mechanism does the Steering Library use ? The Library uses Remote Procedure Calls (RPC) to communicate between the host and the server. The specific transport protocol used is TCP. There are actually two transport protocols available "UDP" and "TCP". Although UDP is faster than TCP, it has a limitation on the maximum datasize. UDP is designed to be connectionless and unreliable. For example, UDP will not guarantee that packets are delivered in the order in which they were sent. Duplicate packets may also be generated in the communication process. Hence we have chosen the TCP protocol. See "man tcp" and "man udp" to get more information. See "man RPC" to get more information about Remote Procedure Calls. Communication within the Paragon is user chosen to be either nx_ or mpi_ message passing calls. The RPC daemon on the server side also uses threads. 2.a What do the terms client, server, host, steer, track etc mean ? Client : This is basically a front end (generally a graphics workstation). Currently, several of the example programs use OpenGL calls and hence should be a workstation running UNIX (or linux) with the OpenGL library (or MESA). This in turn uses X-Windows and Motif widgets. Server : The server is an Intel Paragon with either nx_ or mpi_ message passing calls. Tracking : When data is transferred from server to the host, then it is referred to as tracking. Steering : When the client is allowed to make changes to variables on the compute process, it is referred to as steering. This means that the client can send new values for prescribed variables. Basically a compute process uses a mix of data which is to be steered as well as tracked. The terminology used in this library as well as throughout the function calls is Variables : Data which can only be tracked is referred to as Variables Parameters : Data which can be steered as well as tracked are referred to as Parameters. 2.b What are the pre-requisites to using this library. This library assumes knowledge of C, nx_ (or mpi_) message passing calls on the PARAGON and some familiarity with networking concepts. 3. What s/w tools are needed to run this library ? This library needs unix and the RPC library provided by most unix machines. The RPC library in turn makes use of the XDR library for byte ordering. Before running the library please check for the following daemons on the server (PARAGON) end. - portmapper Try sending a command like "rpcinfo -p " In case rpcinfo fails please contact your system administrator for further details. This library will NOT work in case rpcinfo fails Typical cause for the failure of rpcinfo command is a firewall i.e. host does not have access to the server directly. 4. "Portmapper is present on the server, but still the library fails" The function of the port mapper is to determine a unique port number on which the client can send and the server can listen. The typical way this is done is that the server registers itself with the port mapper with a program number and version number. (In this library, these are the #defines PROG_NO and PROG_VER in the graphics.h file). The client also knows this PROG_NO and PROG_VER. It contacts the portma- pper on the server with this information. The port mapper then responds with a unique port number which is then used by the client to send and listen. In some cases a user may need to bypass the portmapper. This usually happens in cases where the setup is not correct. In these instances, the portmapper on the host can be bypassed and the user can supply the port number. Please refer to the description of the G_InitGraphicsNode on the client side of the library to find out exactly how this is done. One easy way to do this is to supply the port number as reported by the compute process. If this sounds complicated don't worry about it. This is needed only if "Portmapper is present on the server, but still the library fails" 5. "But how does a user know the port number directly?" We are trying to simplify the process. However as of now, if the user needs to supply a port number, then the port number can be found using the rpcinfo command. In the output of the rpcinfo command check for the entry which has the same entry for the PROG_NO and PROG_VER. The corresponding entry in the port number is the requisite value. An easier way to do this would be to just look at the port number which the server process outputs. Use this as the port number. If G3D is used to remotely execute the process, then the port number is directly taken from the standard output. 6.Where can I obtain this library ? ftp to ftp.math.sc.edu cd ~sharpley/outgoing ftp the file name "SteerLib.June10.tar.Z" 7.How do I install the Library ? In order to extract the files run the commands uncompress SteerLib.June10.tar.Z tar xovf SteerLib.June10.tar This will give rise to 2 directories client and server. client : This contains the client side of the library and the test programs. Some of the test programs will run only on SGI machines (as it uses GL). The README files in the examples subdirectories contain further information and details about how to run the programs. server : These files will have to be ftp'd to the parallel machine and run from that machine. This directory contains the server side of the library and test programs. This library and test program uses the Paragon nx_ message passing calls. 8. Are there any example programs? Yes the tar file contains example programs on both the server side as well as the client side. The example programs are pi : The standard Intel example to computes the value pi using the card dealer method. sine : Each compute processor computes a portion of the sine curve. This is a modification of the example provided by Intel with dgl (distributed graphics library). generic : An example program illustrating all the concepts. US3D with G3D controller: The tracking and steering library was used to couple the graphical user interface G3D with the application code US3D in order to do interactive simulations. Server- US3D is a groundwater and contaminant transport simulator. The sample instrumentation illustrates tracking of pressure and concentration variables, monitoring of iteration variables in the solver routine on each processor, and so called `time travel' by retrieving checkpointed files. Steering is demonstrated by interactively introducing contaminant concentrations to determine the effects of leakage. Client- The G3D graphical user interface is a multipurpose graphics tool for post-processing vector and scalar data, and, using integrated graphics utilities, to generate grids, PDE coefficients and other model parameters, initial and (time-varying) boundary conditions to provide input data for simulations. 9. What sort of documentation and support is available for the library ? Apart from the README files in the tar file, the doc directory will contain the following documents client.tex : Detailed explanation of function calls on the client side in latex format. server_nx.tex : Detailed explanation of function calls on the server side (using nx_ message passing) in latex format. server._mpi.tex : Detailed explanation of function calls on the server side (using mpi_ message passing) in latex format. NOTE : In order to compile the above latex files, the stylefile unixman.sty is needed. This is included in the doc directory. --------------------------------------------------------------- For further information contact: Dr. Robert Sharpley sharpley@math.sc.edu Alpana Kaulgud alpana@math.sc.edu Home Page http://www.math.sc.edu/~sharpley/pics.html ---------------------------------------------------------------