Re: [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
address@hidden