[pooma-dev] fields on unstructured meshes

[Jeffrey Oldham]

On Wed, Apr 24, 2002 at 01:25:13PM -0400, Toon Knapen wrote:
> 
> 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.
> 
> 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 ?

I personally have not thought about unstructured Fields.  Perhaps a
one-dimensional index scheme to number regions even for a
multi-dimensional might work.

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

As you point out, dimensions are template parameters.  Since the
dimension is known at compile-time, only member functions related to
these parameters need be present in the executable.  Also, this
decision need not be made at run-time.  For example, it could be known
that only two-dimensional read operators are needed.

One can avoid this restriction by writing a set of functions, each
creating containers of a particular dimension.  All other functions
will have templates to handle arbitrary dimensions.  At run-time, a
comamnd-line option can determine which function will be invoked.  Of
course, space requirements would be larger than if the dimension was
known at compile time.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com