>> >> But the benefit is that the user is free to implement derived >> DofObject types which store whatever, implement additiona >> packing/unpacking as required, then use >> UnstructuredMeshImpl<FatDofObject, SkinnyDofObject> or whatever... >> >> Thoughts? > > Seems like a lot of complication to save what, a couple dozen bytes > per element? Don't forget we're also going to end up needing to > recompile Elem<SkinnyDofObject>, Node<FatDofObject>, > Pyramid5<SkinnyDofObject> ... At that point, if you're using > templates, are there going to be any .C files left in the library?
The savings with 0 variables will be minor, but as you add variables the current DofObject allocates storage to keep track of how many components each variable has on the object, and that means for 20 variables with lagrange elements you are storing a 20-length vector just to keep track of no variables for Elements... Really, though, I had been thinking of this for another reason, and saw Vijay's need as another possible use. Consider the aforementioned case, where I have 20 variables of the same type. Our current DofObject is very wasteful for this case, indeed as is all of DofMap. At a minimum a BlockDofObject or something seems useful, but how to do that without templates??? > We could make Elem derive from ElemDofObject and Node derive from > NodeDofObject, and typedef those to the current implementation. That > wouldn't require quite such sweeping changes, although it would still > require a configure/recompile for any user who wanted to create > something like a "first order lagrange only" version of libMesh. (you'd get second order too...) ...and that is how you do it without templates. I like the idea of EmptyDofObject, DofObject, and BlockDofObject, where NodeDofObject and ElemDofObject are both typedef'ed to DofObject, but redefineable at configure time. I still maintain that the library *cannot* implement std::vector<Whatever> inside the DofObject without user cooperation (at least in the case of parallel redistribution, restart, etc...) But as for addressing only the subdomain id type, the typdedef is certainly the way to go. -Ben ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
