From jgrimm2 at us.ibm.com  Fri Oct  1 19:08:50 2004
From: jgrimm2 at us.ibm.com (Jon Grimm)
Date: Fri, 01 Oct 2004 14:08:50 -0500
Subject: Is pooma supported on gcc-3.4?
Message-ID: <415DAB42.4070808@us.ibm.com>

I downloaded pooma-2.4.0 (from downloads) and older 2.3.0 (available over on gcc testing).  Neither seem to work with gcc-3.4. 

Minimally, I see a __GLIBCPP__ check in the pooma sources that would cause it not to compile as that macro was renamed in gcc-3.4 timeframe (however, your CVS sources seem to have fixed via some autoconf checks).  

In general, just curious on whether pooma is normally considered supported for gcc-3.4, or is it limited to particular versions/architectures of GCC only?

P.S.
I was walking through your back threads at http://www.codesourcery.com/archives/pooma-dev/threads.html
and noticed that Zope errors out on about the third hit to 'Next Page' 	(
(e.g. http://www.codesourcery.com/archives/pooma-dev/thrd4.html)

-- 
Jon Grimm <jgrimm2 at us.ibm.com>
Lotus Notes: Jon Grimm/Austin/IBM at IBMUS


From rguenth at tat.physik.uni-tuebingen.de  Sat Oct  2 18:30:06 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sat, 02 Oct 2004 20:30:06 +0200
Subject: [pooma-dev] Is pooma supported on gcc-3.4?
In-Reply-To: <415DAB42.4070808@us.ibm.com>
References: <415DAB42.4070808@us.ibm.com>
Message-ID: <415EF3AE.5070605@tat.physik.uni-tuebingen.de>

Jon Grimm wrote:
> I downloaded pooma-2.4.0 (from downloads) and older 2.3.0 (available 
> over on gcc testing).  Neither seem to work with gcc-3.4.
> Minimally, I see a __GLIBCPP__ check in the pooma sources that would 
> cause it not to compile as that macro was renamed in gcc-3.4 timeframe 
> (however, your CVS sources seem to have fixed via some autoconf checks). 
> In general, just curious on whether pooma is normally considered 
> supported for gcc-3.4, or is it limited to particular 
> versions/architectures of GCC only?

For gcc 3.4 you will need the CVS version that fixes several ISO 
conformance bugs.  We were about to releasing an updated Pooma some 
weeks ago, but there's no progress - Jeffrey, what's the status on the 
2.4.1 release?

Richard.


From candel at itp.phys.ethz.ch  Sat Oct  9 16:54:39 2004
From: candel at itp.phys.ethz.ch (Arno Candel)
Date: Sat, 09 Oct 2004 18:54:39 +0200
Subject: parallel particle bctest3 crash
In-Reply-To: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de>
Message-ID: <416817CF.5060706@itp.phys.ethz.ch>

Hi,

I am using r2 CVS with Linux 32-bit Intel g++ 3.4.1 as well as Linux 
64-bit Opteron g++ 3.3.4 together with cheetah 1.1.4 & CVS and LAM 7.0.4.

I encounter crashes of r2/src/Particles/tests/bctest3 when running with 
more than 10 contexts:



candel at gate12:~/r2/src/Particles/tests/GPCEO$ mpirun -np 10 ./bctest3 -mpi
PASSED ... KillBC with expression

candel at gate12:~/r2/src/Particles/tests/GPCEO$ mpirun -np 11 ./bctest3 -mpi
MPI_Recv: process in local group is dead (rank 8, comm 2)
Rank (8, MPI_COMM_WORLD): Call stack within LAM:
Rank (8, MPI_COMM_WORLD):  - MPI_Recv()
Rank (8, MPI_COMM_WORLD):  - main()
MPI_Recv: invalid rank: Invalid argument (rank 9, comm 4)
Rank (9, MPI_COMM_WORLD): Call stack within LAM:
Rank (9, MPI_COMM_WORLD):  - MPI_Recv()
Rank (9, MPI_COMM_WORLD):  - main()
CHEETAH-ON-MPI ERROR: Unrecognized get response tag -32766!
-----------------------------------------------------------------------------
One of the processes started by mpirun has exited with a nonzero exit
code.  This typically indicates that the process finished in error.
If your process did not finish in error, be sure to include a "return
0" or "exit(0)" in your C code before exiting the application.

PID 26355 failed on node n0 (127.0.0.1) due to signal 8.
-----------------------------------------------------------------------------
MPI_Recv: invalid rank: Invalid argument (rank 7, comm 4)
Rank (7, MPI_COMM_WORLD): Call stack within LAM:
Rank (7, MPI_COMM_WORLD):  - MPI_Recv()
Rank (7, MPI_COMM_WORLD):  - main()
CHEETAH-ON-MPI ERROR: Unrecognized get response tag -32766!


The problem seems to stem from the sync() call, some PatchFunction might 
have a problem.

Thanks for your help,
Arno Candel


From rguenth at tat.physik.uni-tuebingen.de  Sat Oct  9 22:13:49 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sun, 10 Oct 2004 00:13:49 +0200
Subject: [pooma-dev] parallel particle bctest3 crash
In-Reply-To: <416817CF.5060706@itp.phys.ethz.ch>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de> <416817CF.5060706@itp.phys.ethz.ch>
Message-ID: <4168629D.5030801@tat.physik.uni-tuebingen.de>

Arno Candel wrote:
> Hi,
> 
> I am using r2 CVS with Linux 32-bit Intel g++ 3.4.1 as well as Linux 
> 64-bit Opteron g++ 3.3.4 together with cheetah 1.1.4 & CVS and LAM 7.0.4.
> 
> I encounter crashes of r2/src/Particles/tests/bctest3 when running with 
> more than 10 contexts:

This is no wonder:

   if (Pooma::context() == 0)
     P.create(10,0,false);
   P.sync(P.a1);

i.e. we create 10 particles - distributing over 11 contexts isn't going 
to work.  We don't handle contexts with zero particles gracefully.  I 
think there are similar problems with #patches < #contexts.  But I'd 
qualify these cases as user error.

Hope this helps,
Richard.


From candel at itp.phys.ethz.ch  Sat Oct  9 22:29:11 2004
From: candel at itp.phys.ethz.ch (Arno Candel)
Date: Sun, 10 Oct 2004 00:29:11 +0200
Subject: [pooma-dev] parallel particle bctest3 crash
In-Reply-To: <4168629D.5030801@tat.physik.uni-tuebingen.de>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de> <416817CF.5060706@itp.phys.ethz.ch> <4168629D.5030801@tat.physik.uni-tuebingen.de>
Message-ID: <41686637.9060102@itp.phys.ethz.ch>


> This is no wonder:
>
>   if (Pooma::context() == 0)
>     P.create(10,0,false);
>   P.sync(P.a1);
>
> i.e. we create 10 particles - distributing over 11 contexts isn't 
> going to work.  We don't handle contexts with zero particles 
> gracefully.  I think there are similar problems with #patches < 
> #contexts.  But I'd qualify these cases as user error.
>
> Hope this helps,
> Richard.


Unfortunately, that's not the problem. It still doesn't work after 
creating 11 or more particles.

I've been using position-dependent distribution of particles for months 
now in my own code, often with many contexts not containing any 
particles. The problem only arises when the number of contexts is 
getting too high (mostly 8-10 being the limit). However, I have no idea 
what triggers the error...

Arno


From rguenth at tat.physik.uni-tuebingen.de  Sat Oct  9 23:04:54 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sun, 10 Oct 2004 01:04:54 +0200
Subject: [pooma-dev] parallel particle bctest3 crash
In-Reply-To: <41686637.9060102@itp.phys.ethz.ch>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de> <416817CF.5060706@itp.phys.ethz.ch> <4168629D.5030801@tat.physik.uni-tuebingen.de> <41686637.9060102@itp.phys.ethz.ch>
Message-ID: <41686E96.7000006@tat.physik.uni-tuebingen.de>

Arno Candel wrote:
> 
>> This is no wonder:
>>
>>   if (Pooma::context() == 0)
>>     P.create(10,0,false);
>>   P.sync(P.a1);
>>
>> i.e. we create 10 particles - distributing over 11 contexts isn't 
>> going to work.  We don't handle contexts with zero particles 
>> gracefully.  I think there are similar problems with #patches < 
>> #contexts.  But I'd qualify these cases as user error.
>>
>> Hope this helps,
>> Richard.
> 
> Unfortunately, that's not the problem. It still doesn't work after 
> creating 11 or more particles.

Hm ok, that was just a guess.

> I've been using position-dependent distribution of particles for months 
> now in my own code, often with many contexts not containing any 
> particles. The problem only arises when the number of contexts is 
> getting too high (mostly 8-10 being the limit). However, I have no idea 
> what triggers the error...

I don't have time at the moment to dig into this myself, maybe you can 
try to debug this yourself - usually doing printf-debugging is the only 
way to debug these parallel failures though (unless you have expensive 
tools around, which I don't have).

Richard.


From candel at itp.phys.ethz.ch  Sun Oct 10 14:06:01 2004
From: candel at itp.phys.ethz.ch (Arno Candel)
Date: Sun, 10 Oct 2004 16:06:01 +0200
Subject: [pooma-dev] [PATCH] parallel particle bctest3 crash
In-Reply-To: <41686E96.7000006@tat.physik.uni-tuebingen.de>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de> <416817CF.5060706@itp.phys.ethz.ch> <4168629D.5030801@tat.physik.uni-tuebingen.de> <41686637.9060102@itp.phys.ethz.ch> <41686E96.7000006@tat.physik.uni-tuebingen.de>
Message-ID: <416941C9.7040606@itp.phys.ethz.ch>

okay, this patch fixes the UniformLayout particle swapping, and 
particularly the bctest3 particle test.

There was a floating point exception triggered as soon as less particles 
were created than patches existed -> sizePerPatch=0.
A there was an assertion error when the particle was being sent to a 
patch that didn't even exist (npid >= patchesGlobal()).


Arno.



Index: UniformLayout.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Particles/UniformLayout.h,v
retrieving revision 1.23
diff -u -r1.23 UniformLayout.h
--- UniformLayout.h     14 Jul 2004 15:44:59 -0000      1.23
+++ UniformLayout.h     10 Oct 2004 13:51:36 -0000
@@ -311,11 +311,11 @@
 
     for (int i = 0; i < size; ++i)
     {
-      int npid = (i+offset) / sizePerPatch;
+      int npid = (i+offset) / (sizePerPatch>0?sizePerPatch:1);
 
       // check for a leftover particle
 
-      if (npid == patchesGlobal())
+      if (npid >= patchesGlobal())
        npid = (i+offset) - (sizePerPatch*patchesGlobal());
 
       // Make sure this is kosher


Richard Guenther wrote:

> Arno Candel wrote:
>
>>
>>> This is no wonder:
>>>
>>>   if (Pooma::context() == 0)
>>>     P.create(10,0,false);
>>>   P.sync(P.a1);
>>>
>>> i.e. we create 10 particles - distributing over 11 contexts isn't 
>>> going to work.  We don't handle contexts with zero particles 
>>> gracefully.  I think there are similar problems with #patches < 
>>> #contexts.  But I'd qualify these cases as user error.
>>>
>>> Hope this helps,
>>> Richard.
>>
>>
>> Unfortunately, that's not the problem. It still doesn't work after 
>> creating 11 or more particles.
>
>
> Hm ok, that was just a guess.
>
>> I've been using position-dependent distribution of particles for 
>> months now in my own code, often with many contexts not containing 
>> any particles. The problem only arises when the number of contexts is 
>> getting too high (mostly 8-10 being the limit). However, I have no 
>> idea what triggers the error...
>
>
> I don't have time at the moment to dig into this myself, maybe you can 
> try to debug this yourself - usually doing printf-debugging is the 
> only way to debug these parallel failures though (unless you have 
> expensive tools around, which I don't have).
>
> Richard.



From rguenth at tat.physik.uni-tuebingen.de  Sun Oct 10 14:18:59 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sun, 10 Oct 2004 16:18:59 +0200
Subject: [pooma-dev] [PATCH] parallel particle bctest3 crash
In-Reply-To: <416941C9.7040606@itp.phys.ethz.ch>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de> <416817CF.5060706@itp.phys.ethz.ch> <4168629D.5030801@tat.physik.uni-tuebingen.de> <41686637.9060102@itp.phys.ethz.ch> <41686E96.7000006@tat.physik.uni-tuebingen.de> <416941C9.7040606@itp.phys.ethz.ch>
Message-ID: <416944D3.9090308@tat.physik.uni-tuebingen.de>

Arno Candel wrote:
> okay, this patch fixes the UniformLayout particle swapping, and 
> particularly the bctest3 particle test.
> 
> There was a floating point exception triggered as soon as less particles 
> were created than patches existed -> sizePerPatch=0.
> A there was an assertion error when the particle was being sent to a 
> patch that didn't even exist (npid >= patchesGlobal()).

Yes, that looks ok.  SpatialLayout doesn't seem to need a similar fix. 
Jeffrey, may I approve (and apply) such patches from Arno?

Thanks for tracking this down and fixing it,
Richard.

> 
> Arno.
> 
> 
> 
> Index: UniformLayout.h
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Particles/UniformLayout.h,v
> retrieving revision 1.23
> diff -u -r1.23 UniformLayout.h
> --- UniformLayout.h     14 Jul 2004 15:44:59 -0000      1.23
> +++ UniformLayout.h     10 Oct 2004 13:51:36 -0000
> @@ -311,11 +311,11 @@
> 
>     for (int i = 0; i < size; ++i)
>     {
> -      int npid = (i+offset) / sizePerPatch;
> +      int npid = (i+offset) / (sizePerPatch>0?sizePerPatch:1);
> 
>       // check for a leftover particle
> 
> -      if (npid == patchesGlobal())
> +      if (npid >= patchesGlobal())
>        npid = (i+offset) - (sizePerPatch*patchesGlobal());
> 
>       // Make sure this is kosher



From oldham at codesourcery.com  Mon Oct 11 16:34:54 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Mon, 11 Oct 2004 09:34:54 -0700
Subject: [pooma-dev] [PATCH] parallel particle bctest3 crash
In-Reply-To: <416944D3.9090308@tat.physik.uni-tuebingen.de>
References: <Pine.LNX.4.44.0409081257401.9036-100000@alwazn.tat.physik.uni-tuebingen.de> <416817CF.5060706@itp.phys.ethz.ch> <4168629D.5030801@tat.physik.uni-tuebingen.de> <41686637.9060102@itp.phys.ethz.ch> <41686E96.7000006@tat.physik.uni-tuebingen.de> <416941C9.7040606@itp.phys.ethz.ch> <416944D3.9090308@tat.physik.uni-tuebingen.de>
Message-ID: <416AB62E.7040503@codesourcery.com>

Richard Guenther wrote:

> Arno Candel wrote:
>
>> okay, this patch fixes the UniformLayout particle swapping, and 
>> particularly the bctest3 particle test.
>>
>> There was a floating point exception triggered as soon as less 
>> particles were created than patches existed -> sizePerPatch=0.
>> A there was an assertion error when the particle was being sent to a 
>> patch that didn't even exist (npid >= patchesGlobal()).
>
>
> Yes, that looks ok.  SpatialLayout doesn't seem to need a similar fix. 
> Jeffrey, may I approve (and apply) such patches from Arno?

Yes, please do so.

> Thanks for tracking this down and fixing it,
> Richard.
>
>>
>> Arno.
>>
>>
>>
>> Index: UniformLayout.h
>> ===================================================================
>> RCS file: /home/pooma/Repository/r2/src/Particles/UniformLayout.h,v
>> retrieving revision 1.23
>> diff -u -r1.23 UniformLayout.h
>> --- UniformLayout.h     14 Jul 2004 15:44:59 -0000      1.23
>> +++ UniformLayout.h     10 Oct 2004 13:51:36 -0000
>> @@ -311,11 +311,11 @@
>>
>>     for (int i = 0; i < size; ++i)
>>     {
>> -      int npid = (i+offset) / sizePerPatch;
>> +      int npid = (i+offset) / (sizePerPatch>0?sizePerPatch:1);
>>
>>       // check for a leftover particle
>>
>> -      if (npid == patchesGlobal())
>> +      if (npid >= patchesGlobal())
>>        npid = (i+offset) - (sizePerPatch*patchesGlobal());
>>
>>       // Make sure this is kosher
>
>


-- 
Jeffrey D. Oldham
oldham at codesourcery.com



From rkrylov at mail.ru  Mon Oct 18 12:55:05 2004
From: rkrylov at mail.ru (Roman Krylov)
Date: Mon, 18 Oct 2004 16:55:05 +0400
Subject: SIMD
Message-ID: <4173BD29.1020103@mail.ru>

Was the SIMD(e.g. intel sse) architecture support in pooma planned? Were 
there any efforts?


From rguenth at tat.physik.uni-tuebingen.de  Mon Oct 18 13:21:10 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Mon, 18 Oct 2004 15:21:10 +0200 (CEST)
Subject: [pooma-dev] SIMD
In-Reply-To: <4173BD29.1020103@mail.ru>
Message-ID: <Pine.LNX.4.44.0410181516250.10994-100000@alwazn.tat.physik.uni-tuebingen.de>

On Mon, 18 Oct 2004, Roman Krylov wrote:

> Was the SIMD(e.g. intel sse) architecture support in pooma planned? Were
> there any efforts?

The Compiler should be able to vectorize the expression template expanders
(it isn't due to missing inlining and aliasing optimizations).  Manually
providing SIMD support would be a tedious task - you'd need to specialize
f.i. KernelEvaluator<InlineKernelTag>::evaluate() for different
operations(!), dimensionality and of course types.

Best leave it to compiler improvements.  I'll hope gcc 4.1 with
patches will get there, no hope for Intel.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/



From mark at codesourcery.com  Wed Oct 27 01:40:13 2004
From: mark at codesourcery.com (Mark Mitchell)
Date: Tue, 26 Oct 2004 18:40:13 -0700
Subject: CodeSourcery seeking VSIPL++ developer
Message-ID: <417EFC7D.9000205@codesourcery.com>

We're actively seeking a VSIPL++ developer.  VSIPL++ has been described 
as "POOMA for signal processing" -- it's a high-performance, parallel, 
C++ API designed for use in performing signal and image processing. 
VSIPL++ development is being actively funded by the United States Air 
Force, and we are looking for an additional developer.  You'll have the 
opportunity to work on the design and implementation of a fully 
optimized VSIPL++ implementation.

See:

   http://www.codesourcery.com/jobs/listings/vsiplplusplus_developer

for more information about this position, and:

   http://www.codesourcery.com/jobs/

for more information about our other open positions.

Please send a resume to jobs at codesourcery.com if you are interested!

-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com


From rguenth at tat.physik.uni-tuebingen.de  Fri Oct 29 15:10:49 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Fri, 29 Oct 2004 17:10:49 +0200 (CEST)
Subject: PAWS, LUX, Tulip
Message-ID: <Pine.LNX.4.44.0410291707590.14164-100000@alwazn.tat.physik.uni-tuebingen.de>

Hi!

Pooma currently supports the packages mentioned in the subject, but I
can't find information on them (like license and possibilities to
download) anymore.  The only one with (some) information is
http://www.ccs.lanl.gov/ccs1/projects/Viz/pr-lux.html

Also does anyone know if PETE is still developed / officially hosted
somewhere?  Likewise for SMARTS?

Thanks for any information,

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/