From: John P. <pet...@cf...> - 2005-08-23 15:09:15
|
I wanted to get this topic started up again. I remember there were at least two suggestions on how to go about it, and Ben you mentioned starting it a while back but running into complications. Can you mention any more about those complications? At the risk of repeating an existing idea or muddling the discussion further, Dave and I have been thinking of something like a map<string, CachedData*> The string keys can be generated in a logical way, e.g. "QUAD4_LAGRANGE_SIDE0" Or whatever names are more appropriate. This seems to be a smaller issue than the question of what to cache and where (i.e. what type of class CachedData is). -John |
From: Roy S. <roy...@ic...> - 2005-08-23 15:20:59
|
On Tue, 23 Aug 2005, John Peterson wrote: > At the risk of repeating an existing idea or muddling the discussion > further, Dave and I have been thinking of something like a map<string, > CachedData*> The string keys can be generated in a logical way, e.g. > > "QUAD4_LAGRANGE_SIDE0" I'd make the map a static member of each FE class and leave the FE type out of the key... or at least that's what I'd do in an inheritance-based class tree. Is it possible to overload static members based on template argument? > Or whatever names are more appropriate. This seems to be a smaller > issue than the question of what to cache and where (i.e. what type > of class CachedData is). Depends on what we can cache. For most elements, that's phi, dphidxi, d2phidxi2, and higher dimension counterparts - am I missing anything? For a few elements (Clough, IIRC Hierarchic) we can't really cache dphidxi and d2phidxi2, but we can use the same amount of space to cache data which would make calculating dphidxi and d2phidxi2 faster. --- Roy |
From: John P. <pet...@cf...> - 2005-08-23 15:29:47
|
Roy Stogner writes: > On Tue, 23 Aug 2005, John Peterson wrote: > > > At the risk of repeating an existing idea or muddling the discussion > > further, Dave and I have been thinking of something like a map<string, > > CachedData*> The string keys can be generated in a logical way, e.g. > > > > "QUAD4_LAGRANGE_SIDE0" > > I'd make the map a static member of each FE class and leave the FE > type out of the key... or at least that's what I'd do in an > inheritance-based class tree. Is it possible to overload static > members based on template argument? I don't think you can have virtual (i.e. overloaded) static functions? It doesn't make sense cause static is tied to a single object... > > Or whatever names are more appropriate. This seems to be a smaller > > issue than the question of what to cache and where (i.e. what type > > of class CachedData is). > > Depends on what we can cache. For most elements, that's phi, dphidxi, > d2phidxi2, and higher dimension counterparts - am I missing anything? > For a few elements (Clough, IIRC Hierarchic) we can't really cache > dphidxi and d2phidxi2, but we can use the same amount of space to > cache data which would make calculating dphidxi and d2phidxi2 faster. Since we can cache different things for different types of elements, maybe polymorphism of the "CachedData" class is in order... class FECachedData {}; class LagrangeCachedData : public FECachedData {}; class CloughCachedData : public FECachedData {}; The mother FE class contains a pointer to an FECachedData which is appropriate to its type. Then phi, dphidxi, d2phidxi2 are all accessed through this pointer. FE::reinit in turn calls FECachedData::reinit() which knows what to recalculate. -John |
From: John P. <pet...@cf...> - 2005-08-24 17:48:15
|
Roy Stogner writes: > On Tue, 23 Aug 2005, John Peterson wrote: > > > At the risk of repeating an existing idea or muddling the discussion > > further, Dave and I have been thinking of something like a map<string, > > CachedData*> The string keys can be generated in a logical way, e.g. > > > > "QUAD4_LAGRANGE_SIDE0" > > I'd make the map a static member of each FE class and leave the FE > type out of the key... or at least that's what I'd do in an > inheritance-based class tree. Is it possible to overload static > members based on template argument? I also realized that the shape function data must be cached on a per quadrature rule basis as well. There is nothing to stop the user from reattaching a different quadrature rule during the lifetime of the FE object. So now our string is going to look like QUAD4_QGAUSS3_SIDE0 plus whatever else is important.... -John |