Re: [Libmesh-devel] Random DofObject/DofMap idea

[Roy S. <roy...@ic...>]

On Sun, 25 Feb 2007, Derek Gaston wrote:

> This is mostly a subsystem change, but you have to consider that if
> you want to bring outside FE developers in to help.... the more of
> these things you do the harder it is for someone to get in there and
> change things.

That's a worry, yes.  The biggest drawback of my idea is that it would
require a new Enum of DofObject types, a new method like
Elem::dof_object_type(node_num), and so it would give people one more
thing to worry about when adding new geometric elements.  Granted,
we're not planning on adding more geometric elements any time soon,
but we'll have to add a few eventually if we ever want to support p>2
on tets and prisms or even p>1 on pyramids.

But I really think there's a lot of room to work within DofObject and
DofMap.  I've already made two big feature additions (AMR on
non-Lagrange elements, and p refinement) and one slight optimization
(storing dof index ranges as first,count rather than as whole lists),
and neither required any changes to the API or any DoF related changes
to other code.  I don't think this change would affect any code
outside of the dof_map and dof_object files either.  It's an
incredibly well-isolated subsystem, especially considering how low
level it is.

> Keeping subsystems logically similar to how someone
> new to the code would think about it is advantageous in the long run.
> (but of course the whole dofobject thing is fairly complicated now
> anyway, so a little added complication might not hurt ;-)

Bah; someone new to the code shouldn't be futzing around in the most
low level systems anyway.  I probably only got away with it because
Ben wasn't watching the CVS logs closely enough.  ;-)

The complication should all be hidden, too.  The DofObject and DofMap
APIs wouldn't have to change, just the underlying implementation.

> Anyway, what you are proposing isn't going that far... I'm just trying
> to illustrate some of the pitfalls of "over optimization".

Oh, I understand being wary about it.

> Essentially, if you were to take memory optimization to the max....
> you would end up with Sierra... and I think _none_ of us wants that!

You know these mailing list messages get archived and Google indexed
where managers can read them, right?  ;-)

> For me, the most worthwhile optimization endeavor is parallel mesh.

Agreed.  Tweaking DofObject would probably save dozens of megabytes on
medium sized problems, but parallelizing the mesh would save gigabytes
on large problems.  That's another endeavor I wish I had the time (and
the MPI skills) for.  Ben was sounding more motivated about it the
last time he was in Austin, though; perhaps once he's got his defense
out of the way we can goad him into action.
---
Roy