[petsc-dev] DMGetNamedGlobalVector() implementation?

[Matthew Knepley]

On Sat, Jul 28, 2012 at 4:00 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Thu, Jul 19, 2012 at 2:07 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>> > I agree, but I could not find an easy way.
>>
>>   Can you find a difficult way ?
>>
>>   We chose to make the DM both a factory for creating stuff and a place
>> to stash stuff that people can pull out later, this will lead to more and
>> more of these loops. We could
>>
>> 1) do proper garbage collection always (yuck from the person who has to
>> write that perspective)
>>
>
> Due to the need for deterministic destruction in parallel, I think this
> ends up more-or-less requiring eager loop-breaking, which means we have to
> either (a) keep two-way links so that parents can have ref-count
> information updated upon composition or (b) full dependency graph traversal
> on each dereference.
>
>
>>
>> 2) have separate factories that the user manage; so basically split the
>> DM into two parts that do not reference each other. (Yuck from the user
>> perspective)
>>
>> 3) continue with all these hacks to prevent loops
>>
>
> I think loops are only needed in special cases. We haven't needed them
> until now. If we change DM to keep upward and downward links (nice for some
> cases of FMG), those would also have the same concern. We could make a
> PetscObjectComposeTwoWay() that created, and enforced two-way links. I'd
> prefer not to allow arbitrary loops.
>
>
>>
>> 4) something else?
>
>
>
What about making PetscObjectDestroyChildren() explicit?

    Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120729/ab20d979/attachment.html>