On Tue, 3 Mar 2009, Andrea Hawkins wrote:
> So, in using this fine feature I believe I have found a bug.
I think so too. But before we get into the technical details, I think
it's a good idea to step back, look at the big picture, and focus on
svn blame says Ben did it.
(yes, after I've had too many incidents of commiting insufficiently
tested code, my first reaction upon finding a bug is rushing to svn to
see whether or not it was one of mine...)
> When calling variable_first and variable_last they both return a value
> stored in a vector _var_first_local_df. In looking at these routines, it
> appears that _var_first_local_df should be a vector of length # of vars,
> containing only the first dof for each.
n_vars + 1 - we leave the total number of dofs in there too, to make
variable_last(n_vars) more straightforward. That's probably what that
second push_back was trying to do; it just should have gone outside of
> In looking where it gets defined in dof_map.C, in
> DofMap::distribute_local_dofs_var_major, there is a push back at the
> beginning of the loop and at the end, which appears to account for the extra
That would do it. Thanks!
Double-check that the following patch fixes the problem? If so I'll
--- src/base/dof_map.C (revision 3287)
+++ src/base/dof_map.C (working copy)
@@ -900,9 +900,11 @@
next_free_dof += elem->n_comp(sys_num,var);
} // end loop on elements
} // end loop on variables
+ // Cache the last local dof number too
// Make sure we didn't miss any nodes