On Tue, Mar 11, 2008 at 6:01 PM, Benjamin Kirk <benjamin.kirk@...> wrote:
> >>> Just eliminating that unnecessary, incomplete copy reduced the memory usage
> >>> to 980MB, which I consider a huge savings. So needless to say we will not
> >>> copy the dof objects when they do not contain complete information.
> >> Wow! I'd consider that a big savings too.
> > I'll third that.
> > I had some ideas for reducing DoF indexing memory usage way back when,
> > but some of my best ones either would break when we introduce
> > anisotropic refinement or would already have been broken by our
> > straightforward DofMap
> I've got one more easy fix which helps a lot... Combine the _n_vars and
> _n_comp char vectors, using _n_comp[s] to hold the number of variables in
> system s. Then _n_comp[s] ... _n_comp[s][NV] is the actual number of
> components for each variable. Not only does it remove another pointer but
> the memory allocation/deallocation goes down as well. Of course, I should
> rename the variable to something more clear... I have implemented it but
> want to do some more testing. (for the previous example I get back another
> > On multiphysics problems we have DofObjects store indices
> > independently for every different variable, even though variables with
> > the same FEType will currently have the exact same indexing. Some of
> > Ben's problems must be using 5 times as much DofObject space as
> > necessary.
> Actually, worse than that. All my dofs live at the nodes, so all those
> element dof objects are pure waste.
> I was thinking about something like BlockedDofObject which accepts N
> identical variables and implements the indexing accordingly at great
> savings, or NullDofObject which can't hold any dofs. These would all derive
> from the same base class, of course.
> The real problem, though, is that the mesh would be templated on the type of
> element/node to use...
> template <typename DT=DofObject>
> class Elem : public DT
> ould be nice, however a default template argument still requires a code
> change, e.g.
> Elem *elem becomes
> Elem<> *elem
> maybe a typedef could do something with no external code change?
> (someone stop me before I go template crazy...)
Well, if the DofObject is changed to have an AutoPtr to its
implementation (pimpl idiom), we can still inherit directly from it.
Then all the current interface calls become forwarding calls to the
implementation. There's obviously a lot of details there in how you
construct DofObjects with the different implementations.