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

[Domonkos B. <dom...@ik...>]

Hi,

I'm just trying to add some thoughts to this thread, too :)

> > 1. I think a (not very complicated) lauch script generator could be
> very useful. I mean first 
> >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, 
> >etc.) and additional enable/disable or select type customization
> parameters. The unprocessed 
> >parameters can be passed to the binary program by the launch script. 
> 
> 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 ?
> 

That's fine.

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

Yes. All right. Then one should query the hosts from MPI and initialize
Paracomp with that information.

> 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.

Indeed, but I think the whole related SVA calls could be unified into a
unified "platform". What I like would be the following (with your former
parameterization):

run-sample-sva <app-exe-name> <host1> <host2> ...
run-sample-shell <app-exe-name> <host1> <host2> ...
(separate "unified" scripts)

or

run-sample --sva <app-exe-name> <host1> <host2> ...
run-sample --shell <app-exe-name> <host1> <host2> ...
(one huge unified script)

The main points are that not only the application source should be
portable but the execution environment should be unified. Summarizing,
when one writes a new application using paracomp then (s)he would only
have to write the application in a protable way and would not have to
bother with setting up the launch scripts for one or more enviroments.

(If this unique platform would be usable enought, the side effect will
be that the future programs will have unique parameterization. So one
will not have to get through the manual to get the launch syntax of an
application.)

> 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 
> >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.

Do it does not (see the attachment). I had remembered so, but is does
not.

Balazs