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)
>>> 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...
>> 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.
> 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