[dune-functions] [Dune-functions-commit] [Commit] dune-functions - e7abafb: Add protocol for Aachen meeting

[Carsten Gräser]

Hi Christian,

Am 26.03.2014 16:30, schrieb Christian Engwer:
> Hi Carsten,
> 
>> this is a little surprising to me since we already discussed this
>> and decided differently. Unfortunately removing the 'is consecutive'
>> guarantee makes the whole multi index concept useless. Without this
>> guarantee the multi index is just some unique id equally usefull
>> than a hash.
> 
> we realized that the whole multi-index is even with the zero-starting
> useless. The main reason for not writing consecutive is that Steffen
> doesn't consider the GeometryTypeIndex to be consecutive. A) because
> we can have GeometryTypes with 0 DOFs and B) because the
> GeometryTypeIndex contains entries where no GeometryType is assigned
> to.
I know. That's the target of my suggestion: Add a method to ask
if there are any multi indices starting with a given prefix.

However I'd prefer to stay with consecutive indices by compressing
the used GeometryTypeIndices.

>> If you (in contrast to what we discussed) really need non-consecutive
>> indices it would be nice if you could give a short explanation and
>> come up with some replacement. Otherwise the only thing you can
>> do based on the interface is looping over all dofs and put them into
>> some (unordered)map<MultiIndex,SomeUsefullIndex>.
> 
> No Carsten. You can do all the things we are doing now, iff the exact
> semantics are defined. Currently we store the GeometryTypeIndex, which
Of course, but these semantics are not part of the interface but
an implementation detail. But the interface itself without using these
implementation details does only specify an arbitrary id.

> is non-consectutive, but this is not the issue. The issue is that
> permutations of multi-index entries usually swap two digits, but in
> the case of entities they swap the pair or GeometryTypeIndex and
> EntityIndex with the other entry. This is not the thing you expect
> when talking about multi-indices, but it is what you expect when
I'm afraid I don't understand what you mean by permutations here.

> talking about about where to block your information. In this case it
> doesn't mater if you use the GeoetryTypeIndex, or some compressed
> version. You need to know about the exact semantics and if you know
> this possible non-consecutive indices are not a real problem. An other
> example is, at least in our current design, if you have a
> multi-physics problem. Then the locak tree contains all spaces for all
> sub-domains, but only the correct sub-tree is in a bound state. This
> is necessary in order to keep the C++ types fixed. In this situation
> you again have non-consecutive indices, because some of the entries in
> your tree don't contain any DOFs.
Currently we did not include this in the interface. We always bind the
whole tree. As Oliver suggested it might be a good idea to not consider
this in our general interface but an interface 'extension'.

I'd represent this by pluging together multiple bases on different
grids in some MultiBasis<Basis1, Basis2, ...> that does not satisfy
our interface. If all bases  have the same MultiIndex type one could
get a global consecutive multi index by prepending the number of the
basis to each per-basis multi index. Then one could perhaps even use
the same concept (still to be specified) for backends mapping
multi-indics to container-indices.


> I hope this explains a little bit what the issues in our opinion are.
Thank's a lot for your explanations. I still hope we can find a simple
and easy to understand concept.

Best,
Carsten