MatStash() use linked list of chunks

[Matthew Knepley]

Richard Katz <katz at ldeo.columbia.edu> writes:

> Matt,
>
> When we get together to work on the semi-Lag stuff we should make this interface clear.

  Okay. I will try at something tomorrow as a rough cut.

        Matt

> Rich
>
>
> On Dec 13, 2005, at 4:38 PM, Barry Smith wrote:
>
>>
>>   Rich,
>>
>>    Outline what you use/need in terms of an interface for that case.
>> We can gather the cases to see what commonality comes out.
>>
>>    Barry
>>
>> BTW: I was joking about the "stinking ..."
>>
>>
>> On Tue, 13 Dec 2005, Richard Katz wrote:
>>
>>> A PETSc linked-list object might also be useful in implementations of
>>> characteristics-based advection schemes such as semi-Lagrangian advection.
>>> Perhaps you could give it some sorting methods too?
>>>
>>> but then again, this is just "stinking computer science"...
>>>
>>> Rich
>>>
>>>
>>> On Dec 13, 2005, at 1:22 PM, Richard Tran Mills wrote:
>>>
>>>> I agree with Matt's take on this.  Having a linked-list to be used
>>>> throughout PETSc as appropriate could be quite useful.
>>>>
>>>> I am a fan of doubly-linked list implementations like the one described at:
>>>>
>>>>   http://www.cs.utk.edu/~plank/plank/classes/cs360/360/notes/Dllists/
>>>>
>>>> (This is part of Jim Plank's libFDR library, which also includes a nice
>>>> red-black tree implementation.)
>>>>
>>>> Jim's Dllist stuff stores "Jvals" which are a union of all intrinsic C data
>>>> types -- that way you can stash whatever you want in a node of the list.  I
>>>> don't know if an approach that general is needed in PETSc or not, but the
>>>> flexibility is nice.
>>>>
>>>> --Richard
>>>>
>>>> Matthew Knepley wrote:
>>>>
>>>>>      If we are really going to do this, shouldn't we approach it as a
>>>>> data structures problem? We need a certain structure, which here appears
>>>>> to be "vector", or maybe "list". We make a general interface, and then
>>>>> code up some implementation, like a linked list. Then we can use this
>>>>> interface/impl other places in the code, like the LU part, rather than
>>>>> rely on our old cut&paste strategy.
>>>>>      Matt
>>>
>>>
>
>
>

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness