Re: [Libmesh-devel] Optimizations

[Benjamin S. K. <be...@cf...>]

On the drive home I was thinking about a bitset...  It could be useful 
in general, not only for this case but also for things like 
elem->has_boundary_nodes()...  It is trivial to determine when a face is 
on a boundary, but not a node...

I appreciate your motivation...  If we can combine some stuff into a 
bitset and keep overall storage ~ the same that would be best.

A question:  At first thought, it would seem that an affine map is 
necessarily linear...  Is that true?  If so, are you using first order 
Lagrange shape functions for the map??

-----------------------------------------------------
My traits class is really motivated by other reasons, but even still my 
example was incomplete...  It should read like this:

template <class Traits=DefaultTraits>
class Elem<Traits>
{
   virtual bool has_affine_map()
     { return Traits::has_affine_map(false); }
};

class DefaultTraits
{
   static bool has_affine_map(const bool b) { return b; }
};


class AffineTraits
{
   static bool has_affine_map(const bool) { return true; }
};


Of course, derived elements *could* overload, but for the case of 
Cartesian meshes or some other special case you change the default 
behavior for all element types by considering only Elem<AffineTraits>, 
and incur no storage.

(Note that we need another level of abstraction, though...  John, 
thoughts about making Elem more general? :-) )

The real motivation for this is apparent when the storage gets moved 
into the Traits class.  Consider

Elem <- ElemObj<T> <- Quad4<T>

where I just introduced the discussed abstraction.  Elem is only an 
interface, it stores no data...

A Quad4<UnstructuredTraits> would basically look exacly like what we 
have now except the data is stored in a traits object internally using 
composition.  But that's boring...

The cool part would be Quad4<StructuredTraits> or 
Quad4<CartesianTraits>...  You still would store a traits object 
internally and use composition, but the amount of data stored in the 
traits goes way down...


Anyway, I really don't know anything about traits either, I am just 
making this up...  It seems like it could be really useful, though.

Thoughts?

-Ben






Roy Stogner wrote:
> On Thu, 30 Jun 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote:
> 
>> I started, but then I realized it is going to take more effort than I
>> thought and I want to make sure I do it right...
> 
> 
> I'm telling you, vectors of vectors of multiarrays are the way to go!
> ;-)
> 
>> WRT to the affine checking, this brings up an interesting issue I've been
>> thinking about in general.
>>
>> template <class Traits=DefaultTraits>
>> class Elem<Traits>
>> {
>>  virtual bool has_affine_map () { return Traits::has_affine_map; }
>> };
>>
>> ...
>>
>>
>> This could be useful for a whole bunch of reasons...  Of course,
>> DefaultTraits::has_affine_map is false,  but the build_cube method could
>> force all elements to use an affine map by replacing
>>
>> Elem::build(...)
>>
>> with
>>
>> Elem<Affine>::build(...)
>>
>> sure, there are other implications, but I thought I'd bring the idea up.
> 
> 
> Hmmm... traits template arguments are one of those C++ ideas where my
> ambition overreaches my skills.  I'm afraid I don't see the utility
> here.  For the general case, has_affine_map() is different for each
> element class, and so I don't see the point in creating a separate
> traits class for each element.
> 
> The default case of "return false" is already in Elem.h, so people
> creating new element types don't have to implement affine map tests if
> they don't want to.
> 
> The cacheable cases of "return true" and "return false" are the only
> situation that isn't dealt with effectively yet.  The question there
> is: where do we put the data without making Elem objects bigger?
> 
> I've alreay overloaded the refinement flag once - in hindsight it
> would make sense to make RefinementState a bitset instead and use two
> of the dozens of remaining empty bits for affine map cache status and
> contents.  I think I'd prefer that to a separate set of "Affine" and
> "NonAffine" classes which effectively hide data in the vptr.  An
> element which twiddles with a few of it's member data's bits seems
> more natural and faster to me than an element which recasts itself to
> a different class.
> ---
> Roy
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel