I think the technique Burlen described takes advantages of the interactive queues.<br><br>Here is another type of situation that uses the batch queue instead- user opens paraview on their workstation, submits a job to the cluster, then waits for the pvserver job to start and reverse connect to the client.<br>
<br>You mentioned generating MOAB job scripts on the fly through a pv xml input dialog. All you would need to do would be add some extra code to your job script template. The extra code would generate a portfwd config file with a port chosen by the user. The user would have to pick a port number other than 11111, a random port that hopefully is not in use. When the start server button is clicked on the client it could run a custom command that ssh's to a login node, starts portfwd with the custom config file, and submits the MOAB script. Now the user just waits to pvserver to connect back to the login node which is forwarded straight to the workstation. If the compute node can't connect to the login node by name (`hostname`) you can use /sbin/ifconfig to figure out the exact IP.<br>
<br>I can't think of an elegant way to kill portfwd when the session is over, but you can probably come up with something. Sorry I can't offer any specific details. You might want to read this wiki page too, it describes such a system in use:<br>
<br><a href="https://visualization.hpc.mil/wiki/ParaView_Client-Server_on_Crays">https://visualization.hpc.mil/wiki/ParaView_Client-Server_on_Crays</a><br><br>Goodluck!<br><br>Pat<br><br><div class="gmail_quote">On Thu, Feb 4, 2010 at 3:05 PM, burlen <span dir="ltr"><<a href="mailto:burlen.loring@gmail.com">burlen.loring@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I have used ssh for this on such systems. As long as the batch system gives you exclusive use of the set of compute nodes(usually the case), you shouldn't have to worry about ports being used by others because the tunnel is through your ssh connection. It's not automated though. Here is how I do it:<br>
<br>
I use two terminals on my workstation, in the following denoted by t1$ and t2$, say fe is the front end on your cluster. In the first terminal:<br>
<br>
t1$ ssh fe<br>
t1$ qsub -I -V -l select=XX -l walltime=XX:XX:XX<br>
<br>
<br>
XX is replaced by your values. The job starts and you're automatically ssh'd into some compute node, which we'll say has hostname NODE. In the second terminal:<br>
<br>
t2$ ssh fe<br>
t2$ ~C<enter><br>
-L ZZZZZ:NODE:YYYYY<br>
<br>
<br>
The ~C bit is an escape sequence that sets up the port forward. ZZZZZ is a port number on your workstation. YYYYY is a port number on the server that is not blocked by the clusters internal firewall (see your sys admin). Now back to terminal one, and your waiting compute node:<br>
<br>
t1$ module load PV3-modulefile<br>
t1$ mpiexec pvserver --server-port=YYYYY<br>
<br>
<br>
The module is what sets up the ld library path and paths for your ParaView server install (see your sys admin). now paraview is running on the cluster. You start the ParaView client locally and connect over port ZZZZZ on localhost.<br>
<br>
<br>
That's what I do, if you come up with some automated script though that would be killer.<br><font color="#888888">
Burlen</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
Bart Janssens wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 04 February 2010 07:59:46 pm Rakesh Hammond wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I am no expert on this type of stuff, but I can see how this would work<br>
- the question is if you have multiple users connecting at the same<br>
time, obviously you can't forward everything into 11111 for example.<br>
<br>
<br>
</blockquote>
<br>
Hi Rakesh,<br>
<br>
If you use reverse connections, the compute nodes only need to be able to connect to outside machines (i.e. the workstations). Turning on NAT on a gateway machine, i.e. the frontend, should be sufficient for that, and no port forwarding is needed. This works on a standard Rocks setup, which enables the frontend as gateway by default.<br>
<br>
Cheers,<br>
<br>
Bart<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
</div></div></blockquote></div><br>