Roy Stogner <[email protected]> wrote on 09/28/2011 05:02:21 PM:
>
> On Wed, 28 Sep 2011, David Andrs wrote:
>
> > We ran into an issue with our framework here at INL when forming
> full jacobian matrix as a preconditioner with AMR. What we hit
> > in our problem was the different size of the dense matrix (local
> jacobian contributions) and the dof indices array. I traced the
> > problem down to the level of DofMap::constrain_element_matrix. I
> found out that this method can change the dof indices array
> > (actually the method that changes the dof indices array is
> DofMap::build_constraint_matrix.) and that triggered an assert in
> > libMesh (attached is a modified ex19 that exhibits this behavior).
> This only happens when there are constrains involved. I quess
> > that no one bumped into this since people usually call this
> constrain method just once, but we call it multiple times and trying
> > to reuse those arrays.
>
> I've run into this before; my workaround was to copy the array before
> calling the constrain method.
>
> > So my question: Is this known behavior? And is this used somewhere
> else in libMesh, like we call that constrain_element_matrix
> > and we use this modified array for something later on?
>
> It's known behavior (in fact we've now got DofMap::constrain_nothing()
> whose sole purpose is this behavior), and IIRC I've talked to users
> with app code depending on this behavior, but I don't think it was
> originally *desired* behavior for its own sake; it's just that
> build_constraint_matrix() needs to expand that vector out recursively,
> so that method itself "reuses" the modified array.
>
> Whether that recursive use counts as "somewhere else" is a matter of
> perspective, but I think Ben made a fine design choice here: if
> build_constraint matrix did avoid modifying its input argument then it
> would have to keep both the old and new vector, and whenever the
> constraint recursion went N levels deep we'd have N different vectors
> floating around.
>
> Whereas even for our user codes where the original unexpanded vector
> does get needed again afterwards, we can get away with only one extra
> vector copy and one extra line of code to make the copy.
>
> On the other hand, I'm sure nobody's benchmarked both alternatives (or
> the alternatives where build_constraint_matrix uses std::set, or the
> alternative where a non-recursive "user-level" build_constraint_matrix
> method makes a vector copy and calls a recursive "library-level"
> method...), and I doubt it makes a noticeable performance difference.
>
> The gripping hand is that at this point I wouldn't want to change the
> old method in any case (see: "app code may depend on this behavior").
> I don't think it's worth adding a new method either, unless there's
> some flaw I'm overlooking in my workaround?
> ---
> Roy
Thanks, Roy, for the explanation. I wanted to ask before I take any action
on the fix. The workaround you suggested above was one of the solutions we
came up with.
--
David
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
