[dune-pdelab] [dune-pdelab-commit] [Commit] dune-pdelab - 043f015: [LocalFunctionSpace] Export subspace depth for LFSIndexCache

[Steffen Müthing]

Am 05.09.2013 um 20:19 schrieb Christian Engwer:

> Hi Steffen,
> 
>>    [LocalFunctionSpace] Export subspace depth for LFSIndexCache
>> 
>>    Due to the recent changes to the way subspaces work, the LFSIndexCache
>>    needs to know how the length of the path from the subspace to the root
>>    of the underlying tree because it needs to remove that portion of the
>>    treeindex before invoking the orderings for the subtree (those expect
>>    to get a shorter DOFIndex than what we have right now, as we have cut
>>    off the upper part of the tree in the subspace).
>> 
>>    This patch adds a new method subSpaceLength(), which returns 0 for
>>    regular LocalFunctionSpaces and a positive value for the root
>>    LocalFunctionSpace of the LocalFunctionSpace tree generated from a
>>    GridFunctionSubSpace.
> 
> I'm not quite sure that this does what we want?! Shouldn't we reuse
> the ordering of the root-node? If we strip parts of the DOFIndex and
> then use only a reordering on this subtree, how will I access a global
> vector or matrix?
> 
> I guess I just didn't understand the implications correctly, but it
> seems to me, that this patch will introduce the same problem I
> experienced with the DOFIndex at the level of the reordered index?!

No, not really. It is just a consequence of having the SubSpaceLFS generate
complete indices (up to the original root) now. The code used to work like this:

- Generate DOFIndices that are only filled to the root of the subspace
- Throw the standard (visitor-based) batch conversion at those DOFIndices
  (which works by iterating down the tree and stripping away the parts of the
   tree index above the current level and then reassembling the index on the way
   back up. The code uses a special kind of "ViewIterator" for this purpose). This
   worked correctly in the old case because the DOFIndices started out in the correct,
   cut-off state.
- Complete the DOFIndices up to the root of the original tree and then statically
  walk up the tree (which we can do because we have the path at compile time) and
  complete the mapping.

The new code now already starts out with DOFIndices that contain the complete tree index
up to the original root, so in order to make the batch-conversion visitor work correctly,
we need to provide that visitor with "pre-shortened" tree indices. That's what the new code
does, and the amount by which it needs to shorten those tree indices is just the length of
the path to the subspace (which incidentally is not always the same as the length to the
corresponding ordering in the Ordering tree).

At least for me, the batch interface now does the right thing and hands out the ContainerIndices
I would expect.

Steffen

> 
> Ciao
> Christian
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20130905/bb5965f4/attachment.sig>