|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| ParaView is designed to work well in client/server mode. In this way, users can have the full advantage of using a shared remote high-performance rendering cluster without leaving their offices. This document is designed to help get you started with build and setting up your own ParaView server. It also serves as a collection point for the "tribal knowledge" acquired to make parallel rendering and other aspects of parallel and client/server processing most efficient.
| | This page has been moved to the ParaView Wiki: http://www.paraview.org/Wiki/Setting_up_a_ParaView_Server |
| | |
| == Compiling ==
| |
| | |
| Ideally, we would like to provide precompiled binaries of ParaView for all of our users to make installing it more convenient. Unfortunately, the large variety hardware, operating systems, and MPI implementations makes this task impossible. Thus, if you wish to use ParaView on a parallel server, you will have to compile ParaView from source.
| |
| | |
| After [http://www.paraview.org/New/download.html downloading] ParaView, follow the [[ParaView:Build And Install|Building and Installation instructions]]. When following these instructions, be sure to compile in MPI support by setting the PARAVIEW_USE_MPI CMake flag to ON and setting the appropriate paths to the MPI include directory and libraries.
| |
| | |
| One problem many people face when compiling with MPI is that their MPI implementation provides multiple libraries, many of which are required when compiling ParaView. If there are only two such libraries, you can add them separately in the MPI_LIBRARY and MPI_EXTRA_LIBRARY CMake variables. If you need to link in more than two libraries, you can specify multiple libraries in the MPI_LIBRARY variable by separating them with semicolons (<tt>;</tt>). You can apply the same trick to the MPI_INCLUDE_PATH to specify several include directories.
| |
| | |
| Another problem sometimes encountered is the lack of graphics libraries. There are many circumstances where you would want to compile the ParaView server on a parallel computer with no graphics hardware and thus no OpenGL implementation. In this case, most people use the [http://mesa3d.org Mesa 3D Graphics Library], which is a portable, software-only implementation of the OpenGL API. A cluster built using a Linux operating system probably already has a version of Mesa installed, but otherwise you can always download the source code from http://mesa3d.org.
| |
| | |
| === OSMesa support ===
| |
| | |
| One of the most difficult problems people face when installing a ParaView server is establishing [[#X Connections|XConnections]]. This whole problem can be circumvented by using the OSMesa library. However, Mesa is strictly a CPU rendering library so, '''use the OSMesa solution if and only if your server hardware does not have rendering hardware'''. If your cluster does not have graphics hardware, then compile ParaView with OSMesa support and use the --use-offscreen-rendering flag when launching the server.
| |
| | |
| The first step to compiling OSMesa support is to make sure that you are compiling with the [http://mesa3d.org Mesa 3D Graphics Library]. It is difficult to tell an installation of Mesa from any other OpenGL implementation (although the existance of an osmesa.h header and a libOSMesa library is a good clue). If you are not sure, you can always download your own copy from http://mesa3d.org.
| |
| | |
| Now set the CMake variable OPENGL_INCLUDE_DIR to point to the Mesa include directory (the one containing the GL subdirectory), and set the OPENGL_gl_LIBRARY and OPENGL_glu_LIBRARY to the libGL and libGLU library files, respectively. Next, change the VTK_OPENGL_HAS_OSMESA variable to ON. After you configure again you will see a new CMake variable called OSMESA_LIBRARY. Set this to the libOSMesa library file. After you configure and generate your makefiles, you should be ready to build with OSMesa support.
| |
| | |
| Once again, once you build with OSMesa support, it will not take effect unless you launch the server with the --use-offscreen-rendering flag.
| |
| | |
| Please be aware that OSMesa support is not the same thing as mangled Mesa (although they are often used for the same thing). Mangled Mesa is harder to set up and we (at Sandia National Laboratories) have not found it to be useful. Mangled Mesa provides a mechanism to use either hardware acceleration or CPU-only rendering. Some organizations use this to provide a single build for multiple servers, some with and some without hardware rendering. We find it easier to simply provide a separate build for each server.
| |
| | |
| == Running the Server ==
| |
| | |
| The ParaView client is a serial application and is always run with the <tt>paraview</tt> command. The server is a parallel MPI program that must be launched as a parallel job. Different implementations of MPI may have different ways to launch parallel programs, but the most common way is to use the <tt>mpirun</tt> command. Ask your system administrator if you are not sure how to launch your MPI programs. This document will assume you are using <tt>mpirun</tt>.
| |
| | |
| The ParaView server is almost always enabled with the <tt>pvserver</tt> command. Thus, the most simple configuration would have it launched as something like the following.
| |
| | |
| mpirun -np 4 ./pvserver
| |
| | |
| An integral part of configuring the ParaView server is setting up the client for [[starting the server]]. However, when initially configuring your server, it is best to do it in stages to better identify problems as they occur. Thus, as you are first trying to set up your server, set up your client for [[starting the server#manual startup|manual startup]]. That way, you can launch the server with <tt>mpirun</tt> at the command prompt. You will be able to immediatly see any output on the stdout and stderr streams and retry when something goes wrong.
| |
| | |
| Note that ParaView is designed to work well when the server and client are run remotely from each other. The idea is that the client can be run locally on the user's desktop/laptop
| |
| | |
| === pvserver vs. pvrenderserver and pvdataserver ===
| |
| | |
| There are two modes in which you can launch the ParaView server. In the first mode, all data processing and rendering are handled in the same parallel job. This server is launched with the <tt>pvserver</tt> command. In the second mode, data processing is handled in one parallel job and the rendering is handled in another parallel job launched with the <tt>pvdataserver</tt> and <tt>pvrenderserver</tt> programs, respectively.
| |
| | |
| The point of having a separate data server and render server is the ability to use two different parallel computers, one with high performance CPUs and the other with GPU hardware. However, the server functionality split in two necessitates repartitioning and transfering the data from one to the other. This overhead is seldom much smaller than the cost of just performing both data processing and rendering in the same job.
| |
| | |
| Thus, we recommend on almost all instances simply using the single <tt>pvserver</tt>. This document does not describe how to launch data server / render server jobs. Even if you really feel like this mode is right for you, it is best to first to configure your server in single server mode. From there, establishing the data server / render server should be easier.
| |
| | |
| === Connecting Through a Firewall ===
| |
| | |
| === X Connections ===
| |
| | |
| One of the most common problems people have with setting up the ParaView server is allowing the server processes to open windows on the graphics card on each process's node. When ParaView needs to do parallel rendering, each process will create a window that it will use to render. This window is necessary because you need the X window before you can create an OpenGL context on the graphics hardware.
| |
| | |
| There is a way around this. If you are using the Mesa as your OpenGL implementation, then you can also use the supplemental OSMesa library to create an OpenGL context without an X window. However, Mesa is strictly a CPU rendering library so, '''use the OSMesa solution if and only if your server hardware does not have rendering hardware'''. If your cluster does not have graphics hardware, then compile ParaView with [[#OSMesa support|OSMesa support]] and use the --use-offscreen-rendering flag when launching the server.
| |
| | |
| Assuming that your cluster does have graphics hardware, you will need to establish the following three things.
| |
| | |
| # Have xdm run on each cluster node at startup. Although xdm is almost always run at startup on workstation installations, it is not as commonplace to be run on cluster nodes. Talk to your system administrators for help in setting this up.
| |
| # Disable all security on the X server. That is, allow any process to open a window on the x server without having to log in. Again, talk to your system administrators for help.
| |
| # Make sure each process is run with the <tt>DISPLAY</tt> environment variable set to <tt>localhost:0</tt> (or just <tt>:0</tt>).
| |
| | |
| To enable the last condition, it is often helpful to use the <tt>env</tt> program in the <tt>mpirun</tt> call. So you would have something like
| |
| | |
| mpirun -np 4 /bin/env DISPLAY=localhost:0 ./pvserver
| |
| | |
| An easy way to test your setup is to use the <tt>glxgears</tt> program. Unlike pvserver, it will quickly tell you (or, rather, fail to start) if it cannot connect to the local server.
| |
| | |
| mpirun -np 4 /bin/env DISPLAY=localhost:0 /usr/X11R6/bin/glxgears
| |
| | |
| == Pitfalls ==
| |
| | |
| Here we capture the most common problems people run into with setting up client/server.
| |
| | |
| === Specifying multiple MPI include directories ===
| |
| | |
| You can add multiple directories to the MPI_INCLUDE_PATH CMake variable by separating them with semicolons (<tt>;</tt>). See the [[#Compiling]] section for more details.
| |
| | |
| === Specifying multiple MPI libraries ===
| |
| | |
| You can use both the MPI_LIBRARY and MPI_EXTRA_LIBRARY CMake variables for specifying MPI libraries. You can also add multiple libraries to MPI_LIBRARY by separating the files with semicolons (<tt>;</tt>). See the [[#Compiling]] section for more details.
| |
| | |
| === Mangled Mesa ===
| |
| | |
| Do not bother to use Mangled Mesa. Compiling a version of Mesa is typically more trouble than it is worth and is incompatible with the [[#OSMesa support|OSMesa support]] instructions given on this page.
| |
| | |
| === ParaView does not scale ===
| |
| | |
| Many a user have reported to the mailing list that ParaView failed as they tried to scale up the data size on their server. First, let me assure you that ParaView’s parallel visualization and rendering are efficient and scalable. We (at Sandia National Laboratories) have been able to use ParaView to visualize 6 billion cell grids and have clocked rendering speeds of over 8 billion polygons per second.
| |
| | |
| When a user reports that ParaView is not scaling to large data sets, it is almost always because the server is misconfigured for parallel rendering. The problem is often misinterpreted as a scaling problem because ParaView will use serial rendering for small data and parallel rendering for large data. So when the server is misconfigured and cannot perform parallel rendering, it sometimes misbehaves when the data gets big enough to use parallel rendering.
| |
| | |
| Parallel rendering is build right into ParaView. There is nothing special you have to compile to set this up. However, to perform parallel rendering (or any rendering, for that matter), the ParaView server needs to have an OpenGL context. This is usually done through [[#X Connections|X Connections]]. However, most parallel programs have no need to open an X window, so most clusters are not configured to allow X connections. For help on how to configure your cluster, see the [[#X Connections]] section.
| |
| | |
| Before reporting scalability problems with ParaView, please verify that parallel rendering is working correctly. You can do that with the following procedure.
| |
| | |
| # Open the Settings dialog box (Edit -> Settings) and go to the Server tab.
| |
| # Make sure the checkbox next to Remote Render Threshold is checked, and move the associated slider all the way to the left (0 MBytes).
| |
| # Make sure the checkbox next to Subsample Rate is checked and move the slider to the right (4 Pixels or more).
| |
| # Create or load any data (the cone source works fine) and rotate the data with the mouse. While rotating, the image should look pixelated (blocky). When you let go of the mouse, the full resolution picture is restored.
| |
| | |
| The Remote Render Threshold option tells ParaView to always use parallel rendering. The Subsample Rate tells ParaView to render smaller images during interaction to make the GUI more responsive. This latter feature is very noticeable when the subsample rate is high and only used during parallel rendering. So if you are not seeing the subsample effect (or if something went clearly wrong before that), then your parallel rendering is not working.
| |
| | |
| == Acknowledgements ==
| |
| | |
| Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United States Department of Energy's National Nuclear Security Administration under contract DE-AC04-94AL85000.
| |
