Re: [Paracomp-users] Making samples single node friendly

[Kumar, S. (STSD) <shr...@hp...>]

Hi Balazs,

> I also think that making Paracomp independent from HP SVA is necessary
to aim at wider=20
> audience. I have two remarks.=20

Right.

> 1. I think a (not very complicated) lauch script generator could be
very useful. I mean first=20
>focusing on the following:
> - passwordless ssh/rsh
> - sva/slurm
> - mpi (mpi+slurm)
> The input could be the name of the binary program, the type of the
launch script (ssh, sva,=20
>etc.) and additional enable/disable or select type customization
parameters. The unprocessed=20
>parameters can be passed to the binary program by the launch script.=20

I like the idea of the program binary being a parameter.  All the
samples in the intermediate directory handle the command line arguments
in the same way, and this is a good idea.

The script could look like --
  run-sample <app-exe-name> <host1> <host2> <host3> ...

Sample invocations --
  Run two instances on the local node
  # run-sample ./multiple-framelets localhost:0 localhost:1
  Run two instances on the local node - one each on X screens :0 and :1
  # run-sample ./multiple-framelets localhost:0:0 localhost:1:1
  Run two instances on two nodes
  # run-sample ./multiple-framelets thisnode othernode
  Run four instances on two nodes, with each node having two X screens
  # run-sample ./multiple-framelets thisnode:0 thisnode:1 othernode:0
othernode:1

Choosing between ssh/rsh could be done by an environment variable ?

For mpi apps, we probably don't need a wrapper since mpirun provides all
that is needed.

Note that the SVA scripts allocate a job and start X servers.  The
generic script can't do this, but that shouldn't be a problem.

By the same logic, now that I think of it, we could unify all the SVA
launch scripts themselves! We could replace three launch scripts (one
for each sample), with a single one with the binary as a parameter.

> 2. As I know in project Equalizer (http://www.equalizergraphics.com/
), this readback and "is the partial output >visible" problem is solved
somehow. However, I don't know how the performance of their solution can
be compared=20
>to the performance of the Paracomp.

Does the composited result show up properly if the render windows
overlap ? If so, then I need to look at this sometime.

Regards
-- Shree