Alright. First, I'll make the change of type for sbd_id to unsigned int in Elem.h and all other relevant files. I will include a patch of this once I have tested that it works with my code.
And my next step would be to see if I can do something with MeshData. Since no one is using this, from what I gather, I will see if this object can be made useful again. Ben, if std::vector<blah> is not the way to go, then the idea behind propagating MeshData's structure would also fall prey to all the same issues as having a generic container in Elem. But this is how the interface is already defined for MeshData ! The would it be elegant to do something like what Roy suggested. Give a pointer to an abstract base class with serialization functions for different mesh formats and attribute computation by user based on child attributes during coarsenings ? I am just trying to figure out what would be more natural and to avoid pitfalls that Derek pointed out. Anyway, thanks for the ideas guys ! I shall mail again later with a patch and hopefully more ideas... On Tue, Feb 10, 2009 at 2:29 PM, Kirk, Benjamin (JSC-EG) <[email protected]> wrote: >>> >>> 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 > ------------------------------------------------------------------------------ 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
