RE: [pooma-dev] fields on unstructured meshes

[James Crotinger]

>-----Original Message-----
>From: Toon Knapen [mailto:address@hidden]
>Sent: Wednesday, April 24, 2002 11:25 AM
>To: address@hidden
>Subject: [pooma-dev] fields on unstructured meshes
>
>
>The documentation of pooma 2.3 indicates that one of the next releases will
>contain unstructured meshes. I guess it's not yet for 2.4 since I can't
>find
>them in the CVS.

That was the plan when the Pooma team was still at Los Alamos. Obviously the docs were not given a thorough review when 2.3 was released. When 2.4 was started, I think there was still some hope that unstructured might be a follow-on project - probably 2.5. As the lab cut funding for 2.4 in the middle of the project, that is very unlikely.

>But I don't see how the Field concept will be extended to unstructured
>meshes.  A field currently supports Array-like indexing (e.g. 2 indices for
>2-dimensional meshes). But on unstructured meshes, the elements need be
>numbered using some numbering scheme that is not purely based on the
>position
>of the element. But what happens with the Array-like indexing in this case
>?

There would be no tensor product indexing. This was definitely a research-area that we had not explored in much depth. But we did believe that there was value to data-parallel abstractions with unstructured.

>I'm also curious why you decided to use the dimension (of the problem) as a
>template parameter . As a consequence, you need different executables to
>simulate input-files describing a 2D and a 3D problem. But I guess the
>decision is based on the performance that can be gained by fixing the
>dimension ?

This is required for the compile-time optimizations to work. Indexing has to know the dimensionality in order for expressions like

   A(I,J) = B(I,J+1) - B(I-1,J);

to effectively turn into a set of nested loops each containing

   a(i,j) = b(i,j+1) - b(i-1,j); // Fortran notation
 
This has to happen at compile time in order for the _expression_ templates to yield the kind of efficiency that one would get using hand-coded loops.

This does lead to code bloat in certain applications, but it is basically unavoidable if you're going to use _expression_ templates.

        Jim