paracomp-users — Discussions related to using the API, targeted at users

[Paracomp-users] ParaComp 1.2 released!

[Shree K. <shr...@hp...>]

Hi All,

I've just release ParaComp v1.2 . Do give it a try !

Note that you will be able to use ParaComp as a compositing backend 
with Equalizer (http://equalizergraphics.com).

If you find any problems with it this release, do let me know !

 From the ChangeLog
------------

Release 1.2

         New Library Features
           - Support for 16 & 32 bit floating point values for compositing
             The tokens for these are :
                    PC_PF_RGB16F, PC_PF_RGBA16F,
                    PC_PF_RGB32F, PC_PF_RGBA32F.
             16 bit calculations are done using ILM's half library, so 
expect these to be slow.
           - Accumulation operator PC_COMP_ADD.
           - EXT_composite - an extension to use ParaComp as a 
compositing-only
             backend. This extension allows ParaComp to be used as a 
compositing
             backend for Equalizer (http://equalizergraphics.com).
           - Alterate operator, PC_COMP_ALPHA_SORT2_HP for 
alpha-blending. This
             is used for volume rendering by eVolve (volume rendering
             demo application that is part of Equalizer).
           - Added a way to control which TCP ports the library uses

         Works on new platforms
           - Mac OSX, Darwin (x86/x86_64, PPC)
           - SGI Prism (Linux on Itanium)
           - better support for 32 bit linux

         src
           - Fixed : Alpha blending bug in pure CPU code (SF Bug 1928113)
           - Fixed : MPI interaction issue (SF Bug 1827022, 1953910)
           - Improved build system, compiles with GCC 4.x
           - Cleaner & better compiles
           - Works with OFED 1.2 and above
           - Bumped up the version number to 1.2

         samples
           - Uses nVidia glh for trackball, much better than older trackball
             code
           - Easier to run multiple instances of samples on a single node
           - New sample programs
             - intermeditate/multithreaded : Multithreaded use of ParaComp

         test
           - new directory with test programs.

         doc
           - documentation of changes from API v1.1 to v1.2

------------

Cheers
-- Shree

[Paracomp-users] ParaComp Release 1.2 about to happen

[Shree K. <shr...@hp...>]

Hi All,

ParaComp version 1.2 is almost ready.  All changes needed for it are on 
the SVN trunk - except some documentation.

Chief API additions from 1.1 :

   1. 16 & 32 bit floating point datatypes
      PC_PF_RGB16, PC_PF_RGBA16, PC_PF_RGB32, PC_PF_RGBA32

   2. PC_COMP_ADD operator

   3. PC_COMP_ALPHA_SORT2_HP extension for Equalizer integration.

I've done a fair amount of testing on it. Please take some time to test 
your programs against the SVN trunk. Let me know if you find any issues.

I'm planning to release 1.2 in a couple of days...

Thanks
-- Shree

Re: [Paracomp-users] Cost of calling pcFrameResult

[Shree K. <shr...@hp...>]

Hi James,

James S Perrin wrote:
> Hi,
> 
>         I would like to know what is the cost of calling pcFrameResult() from a
> process that does *not* contribute a frame to the composited image. This
> process would be the display or master node, though it is part of the
> session how much is it involved in the compositing both in terms of
> computation and bandwidth?

In the current implementation, a process which does not contribute a 
framelet does not do any compositing. So there is virtually no 
computation cost.

The process uses only network bandwidth to get the image corresponding 
to the output region requested by it.

---

There is an additional cost to pay for pcFrameResult() (compared to 
FrameWaitOutputHP() ) too. It allocates a buffer large enough for the 
output region of the host. It then copies the "output"s to this buffer & 
returns a pointer to the buffer. So pcFrameResult() results in slightly 
higher latency & uses more memory.

HTH
-- Shree

[Paracomp-users] Cost of calling pcFrameResult

[James S P. <jam...@ma...>]

Hi,

	I would like to know what is the cost of calling pcFrameResult() from a 
process that does *not* contribute a frame to the composited image. This 
process would be the display or master node, though it is part of the 
session how much is it involved in the compositing both in terms of 
computation and bandwidth?

Regards
James
-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

[Paracomp-users] Do you feel the need to extend the alpha blending operator ?

[Shree K. <shr...@hp...>]

Quick Poll : do you guys feel that the paracomp alpha blending operator 
is too restrictive in what it provides ? Have you felt the need to 
extend it ?

I'm asking this in the context of integration with equalizer. They are 
using a different equation to do the volume rendering.

The current paracomp interface provides the equivalent of 
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). This assumes that colors 
are premultiplied by alpha. This also results in final alpha values 
which are incorrect.

For equalizer, they need glBlendFuncSeparateEXT(GL_ONE, GL_SRC_ALPHA, 
GL_ZERO, GL_SRC_ALPHA).

Thanks for your time
-- Shree

Re: [Paracomp-users] Paracomp crash when compiled in release mode

[James S P. <jam...@ma...>]

Hi Shree,

	Yes it works fine. Thanks.

James

Shree Kumar wrote:
> On Fri, 2008-04-11 at 15:22 +0000, James S Perrin wrote:
>> Hi Shree,
>>
>>         Same as you gcc 4.1.2 and glibc 2.5.
>>
> 
> Good news. I've fixed this just now :-)
> 
> http://paracomp.svn.sourceforge.net/viewvc/paracomp?view=rev&revision=60
> 
> James, do let me know if it works for you.
> 
> Cheers
> -- Shree
> 
>> Shree Kumar wrote:
>>> Hi James,
>>>
>>> I ran into the same problem which you faced : crash when paracomp is
>>> compiled in release mode.
>>>
>>> My system : an x86_64 machine running Fedora Core 8(x86_64). GCC version
>>> 4.1.2
>>>
>>> Basically, any program using the library crashes, _if_ paracomp was
>>> compiled in release mode. If paracomp is compiled in debug mode
>>> "release=0" things move just fine.
>>>
>>> I investigated this a bit, and found that a dlclose() in
>>> loadCompositePlugin() (pcimpl.cpp) is causing the crash.
>>>
>>> ----------------------------------------------------------
>>>  using namespace paracomp;
>>> @@ -236,7 +242,7 @@
>>>         // if the init function returns non-zero, then it cannot be used
>>>         if(((*initFunc)())!=0)
>>>         {
>>> -               dlclose(libHandle);
>>> +             //dlclose(libHandle); // commenting this out gets rid of
>>> the crash
>>>                 return false;
>>>         }
>>> ----------------------------------------------------------
>>>
>>> Seems to be a compiler related issue, since I don't see this on our RHEL
>>> 5 based system (running GCC 3.4.6).
>>>
>>> James, do you remember what compiler version you saw the issue on ?
>>>
>>> For now, I don't have a solution. Commenting out gets rid of the
>>> problem. This will result in a small memory leak, but should be good to
>>> keep people going.
>>>
>>> Just something I thought everybody must know before we find a solution
>>> to the problem.
>>>
>>> Regards
>>> -- Shree
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save $100.
>>> Use priority code J8TL2D2.
>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>> _______________________________________________
>>> Paracomp-users mailing list
>>> Par...@li...
>>> https://lists.sourceforge.net/lists/listinfo/paracomp-users
>> --
>> ------------------------------------------------------------------------
>>    James S. Perrin
>>    Visualization
>>
>>    Research Computing Services
>>    The University of Manchester
>>    Kilburn Building, Oxford Road
>>    Manchester, M13 9PL
>>
>>    t: +44 (0) 161 275 6945
>>    e: jam...@ma...
>>    w: www.manchester.ac.uk/researchcomputing
>> ------------------------------------------------------------------------
>>   "The test of intellect is the refusal to belabour the obvious"
>>   - Alfred Bester
>> ------------------------------------------------------------------------
> 

-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-users] Paracomp crash when compiled in release mode

[Shree K. <shr...@hp...>]

On Fri, 2008-04-11 at 15:22 +0000, James S Perrin wrote:
> Hi Shree,
> 
>         Same as you gcc 4.1.2 and glibc 2.5.
> 

Good news. I've fixed this just now :-)

http://paracomp.svn.sourceforge.net/viewvc/paracomp?view=rev&revision=60

James, do let me know if it works for you.

Cheers
-- Shree

> Shree Kumar wrote:
> > Hi James,
> >
> > I ran into the same problem which you faced : crash when paracomp is
> > compiled in release mode.
> >
> > My system : an x86_64 machine running Fedora Core 8(x86_64). GCC version
> > 4.1.2
> >
> > Basically, any program using the library crashes, _if_ paracomp was
> > compiled in release mode. If paracomp is compiled in debug mode
> > "release=0" things move just fine.
> >
> > I investigated this a bit, and found that a dlclose() in
> > loadCompositePlugin() (pcimpl.cpp) is causing the crash.
> >
> > ----------------------------------------------------------
> >  using namespace paracomp;
> > @@ -236,7 +242,7 @@
> >         // if the init function returns non-zero, then it cannot be used
> >         if(((*initFunc)())!=0)
> >         {
> > -               dlclose(libHandle);
> > +             //dlclose(libHandle); // commenting this out gets rid of
> > the crash
> >                 return false;
> >         }
> > ----------------------------------------------------------
> >
> > Seems to be a compiler related issue, since I don't see this on our RHEL
> > 5 based system (running GCC 3.4.6).
> >
> > James, do you remember what compiler version you saw the issue on ?
> >
> > For now, I don't have a solution. Commenting out gets rid of the
> > problem. This will result in a small memory leak, but should be good to
> > keep people going.
> >
> > Just something I thought everybody must know before we find a solution
> > to the problem.
> >
> > Regards
> > -- Shree
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > Paracomp-users mailing list
> > Par...@li...
> > https://lists.sourceforge.net/lists/listinfo/paracomp-users
> 
> --
> ------------------------------------------------------------------------
>    James S. Perrin
>    Visualization
> 
>    Research Computing Services
>    The University of Manchester
>    Kilburn Building, Oxford Road
>    Manchester, M13 9PL
> 
>    t: +44 (0) 161 275 6945
>    e: jam...@ma...
>    w: www.manchester.ac.uk/researchcomputing
> ------------------------------------------------------------------------
>   "The test of intellect is the refusal to belabour the obvious"
>   - Alfred Bester
> ------------------------------------------------------------------------

[Paracomp-users] ParaComp compiles/runs on...

[Shree K. <shr...@hp...>]

Hi Everybody,

The project page http://paracomp.sourceforge.net/ lacks one important
piece of information -- which platforms the library has been
compiled/tested on. I am trying to make such a list so that users can
get a good idea of which platforms already work.

The primary development of the library is happening on HP XC(current
version based on RHEL 4 update 5(x86_64)). 

Apart from that, I've compiled & used the library on my office desktop,
which is FC8 (x86_64). I've also compiled & used the library on my 32
bit laptop running FC7.

If you have compiled & used the library with other compilers/platforms,
please let me know. I'd want to add that to the list.

Thanks in advance
-- Shree

[Paracomp-users] Updates to ParaComp page

[Shree K. <shr...@hp...>]

Folks,

I've updated the ParaComp page at SourceForge :

http://paracomp.sourceforge.net/

The changes are in the "Who is using the library" section --
  1. Added referrence to University of Manchester's work on AVS/Express
  2. Included list of all projects done by Technical University of
Budapest.

Please go over the site. Let me know if you don't like something OR want
something changed.

Thanks
-- Shree

Re: [Paracomp-users] Paracomp crash when compiled in release mode

[James S P. <jam...@ma...>]

Hi Shree,

	Same as you gcc 4.1.2 and glibc 2.5.

Regards
James

Shree Kumar wrote:
> Hi James,
> 
> I ran into the same problem which you faced : crash when paracomp is
> compiled in release mode.
> 
> My system : an x86_64 machine running Fedora Core 8(x86_64). GCC version
> 4.1.2
> 
> Basically, any program using the library crashes, _if_ paracomp was
> compiled in release mode. If paracomp is compiled in debug mode
> "release=0" things move just fine.
> 
> I investigated this a bit, and found that a dlclose() in
> loadCompositePlugin() (pcimpl.cpp) is causing the crash.
> 
> ----------------------------------------------------------
>  using namespace paracomp;
> @@ -236,7 +242,7 @@
>         // if the init function returns non-zero, then it cannot be used
>         if(((*initFunc)())!=0)
>         {
> -               dlclose(libHandle);
> +             //dlclose(libHandle); // commenting this out gets rid of
> the crash
>                 return false;
>         }
> ----------------------------------------------------------
> 
> Seems to be a compiler related issue, since I don't see this on our RHEL
> 5 based system (running GCC 3.4.6). 
> 
> James, do you remember what compiler version you saw the issue on ?
> 
> For now, I don't have a solution. Commenting out gets rid of the
> problem. This will result in a small memory leak, but should be good to
> keep people going.
> 
> Just something I thought everybody must know before we find a solution
> to the problem.
> 
> Regards
> -- Shree
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Paracomp-users mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-users

-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

[Paracomp-users] Paracomp crash when compiled in release mode

[Shree K. <shr...@hp...>]

Hi James,

I ran into the same problem which you faced : crash when paracomp is
compiled in release mode.

My system : an x86_64 machine running Fedora Core 8(x86_64). GCC version
4.1.2

Basically, any program using the library crashes, _if_ paracomp was
compiled in release mode. If paracomp is compiled in debug mode
"release=0" things move just fine.

I investigated this a bit, and found that a dlclose() in
loadCompositePlugin() (pcimpl.cpp) is causing the crash.

----------------------------------------------------------
 using namespace paracomp;
@@ -236,7 +242,7 @@
        // if the init function returns non-zero, then it cannot be used
        if(((*initFunc)())!=0)
        {
-               dlclose(libHandle);
+             //dlclose(libHandle); // commenting this out gets rid of
the crash
                return false;
        }
----------------------------------------------------------

Seems to be a compiler related issue, since I don't see this on our RHEL
5 based system (running GCC 3.4.6). 

James, do you remember what compiler version you saw the issue on ?

For now, I don't have a solution. Commenting out gets rid of the
problem. This will result in a small memory leak, but should be good to
keep people going.

Just something I thought everybody must know before we find a solution
to the problem.

Regards
-- Shree

[Paracomp-users] Updates to the project website

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

Folks,

I've made some much needed changes to the paracomp webpage at http://paracomp.sourceforge.net/

It would be great if you could take a few minutes to review the updated page.

Corrections/additions/suggestions for improvement are welcome.

Thanks
-- Shree

[Paracomp-users] Fixed interoperability issue with HP-MPI

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

I just fixed an issue while using paracomp with HP-MPI (not sure whether
the same problem happens with other MPI implementations).=20

Bug report
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1827022&grou=
p_i
d=3D202475&atid=3D981731

Balazs, you had some problems with MPI and I had suggested a workaround
earlier.  Now that's no longer needed - so now you can initialize MPI
first, and then Paracomp.

Regards
-- Shree

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

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

Hi Balazs,

> Indeed, but I think the whole related SVA calls could be unified into
a unified "platform".=20
> [snip]
> 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)

<host1> <host2> ... options probably don't apply to SVA, since SVA
allocates nodes on the fly. For a small cluster, it is not unreasonable
for the user to know which nodes are free. The equivalent for SVA could
be <I_want_to_use_N_GPUS_somehow> :-)

However, this is a good goal to keep. An even simplified syntax could be
:

run-sample <app-exe-name> <host1> <host2>
OR
run-sample <app-exe-name> <on_N_GPUs_somehow>

and the script determines the environment and does the right thing :-)

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

Don't you think this would be a large undertaking ? I intended to create
a small script framework _only_ for sample apps. Real world apps
probably want to use their own mechanisms, since they could have other
dependencies!

>> Does the composited result show up properly if the render windows=20
>> 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.

Thanks for this information. There are ways to show the user what's
going on.  One thing we could do is : we could render on FBOs and copy
the color buffer to the framebuffer (possibly with scaling). This would
result in a performance hit. But more importantly, it complicates the
sample code, so I am a bit reluctant to do this.

Regards
-- Shree

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

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

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

[Balazs D. <bal...@us...>]

Hi,

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

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. 

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.

Balazs

[Paracomp-users] Making samples single node friendly

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

The samples which we currently suffer from two deficiencies :
1. They all expect to be run on a cluster
2. Launch scripts are available only for HP SVA

These make it difficult for people who don't have access to SVA to try
out the library.

So I want to modify some of the samples so that they can be run on a
single node.=20

I don't want to touch the beginner samples since they are intended to be
as simple as possible.  The advanced samples (currently only multitile)
can't be run meaningfully on a single node. That leaves the intermediate
samples.

Here's what I am thinking of doing :
1. Modify the "boundingbox" and "multiple-framelets" samples so that
they can run on a single node
2. Multiple instances running on the same node will mean multiple
windows onscreen.  When the windows overlap, then framebuffer readback
will give wrong results on the windows which are occluded. So, there
will be a way to ask the slaves to use pbuffers. This has the
disadvantage that the user can't see the images on the slaves, but that
should be OK.
3. Scripts to run the samples on both single nodes and multiple nodes.
Scripts will depend on passwordless ssh/rsh.

Comments?

-- Shree