On 6/2/10 3:42 PM, Roy Stogner wrote:
>
> On Wed, 2 Jun 2010, Boyce Griffith wrote:
>
>>>> On 6/1/10 7:19 PM, Roy Stogner wrote:
>>>>>
>>>>> On Tue, 1 Jun 2010, Boyce Griffith wrote:
>>>>>
>>>>>> I guess there must be some other necessary DOFs in the default
>>>>>> send_list?
>>>>>
>>>>> Not for enforce_constraints_exactly(), there shouldn't...
>>
>> And indeed there don't appear to be. I was initializing the vector of
>> constraint dependencies incorrectly.
>
> Could you go into more detail? You posted most of the code that you
> used to fill that vector, and I didn't find whatever the problem was
> with it, so now I'm curious.

The code snippet I sent yesterday was collecting the dependencies for 
the off-processor DOFs rather than the local DOFs --- DOH!

         // We only need the dependencies of our own constrained dofs.
         if (constrained_dof < first_local_dof ||
             constrained_dof >= end_local_dof)
         {
             const DofConstraintRow& constraint_row = i->second;
             for (DofConstraintRow::const_iterator j =
                      constraint_row.begin();
                  j != constraint_row.end(); ++j)
             {
                 const unsigned int constraint_dependency = j->first;
                 if (constraint_dependency < first_local_dof ||
                     constraint_dependency >= end_local_dof)
                 {
                    constraint_dof_list.push_back(constraint_dependency);
                 }
             }
         }

The comment is right but the first if statement is wrong.

>> Sorry to have wasted your time hunting for a non-existent bug.
>
> Eh, you'll probably make up for it by running into a real bug soon
> enough. ;-) See my earlier warning to Andrea re: AMR on periodic
> boundaries.
>
>> By the way, it looks like for enforce_constraints_exactly() to work
>> correctly for GHOSTED vectors, it needs to be proceeded by a call to
>> localize(). Is that correct?
>
> Off the top of my head, I don't think so. The target vector does need
> to have ghost values up to date, but that should to be accomplishable
> with just a close(). Let me know if that's insufficient!

OK, then I have mis-understood what close() does --- I think I thought 
it was equivalent to VecAssemblyBegin() + VecAssemblyEnd(), but looking 
at the code it obviously also updates any ghost values.

-- Boyce

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to