[Dune] [Dune-Commit] dune-grid r7996 - trunk/dune/grid/common

[Oliver Sander]

Hi Martin, hi all,
here's my view on the method, which lead to the introduction of
boundarySegmentIndex.  I know that my view is not shared by
everyone.

To me, boundaryId sticks out like a sore thumb:
a) AFAIR it was never publicly discussed, instead it just
    appeared some day
b) It is not documented what it does.  To this day I do not
    know what it is actually supposed to do.
c) Consequently, each grid implements something else.
    YaspGrid and SGrid return the number of the domain boundary.
    OneDGrid and UGGrid return the boundarySegmentIndex,
    I don't really know what AlbertaGrid and ALUGrid do.
d) Apparently you can set boundaryIds of some grids by some
    DGF magic.  This is very inconsistent with the design
    principles of the Dune grid interface.  One fundamental idea
    of the interface is that geometry is separated from data,
    and data is attached to the grid entities by means of suitable
    indices.  To me, integer numbers that denote boundary conditions
    in somebody's personal numbering system are quite evidently
    data, and should not be stored in the grid.

IIRC we discussed all this and settled on the boundarySegmentIndex
approach.  Then we found that there are problems with this in parallel
settings.  I volunteered to come up with a solution but never did.
This was so because I never found the time, but also because I never
really do parallel computing myself.

Now what do we do?  I still consider the boundaryId approach very much
inferior to boundarySegmentIndex, but of course I can't push that
solution unless it works in parallel, too.  I am a bit surprised
that so many people use boundaryId given that I have personally
never had to use one of these methods, even though some of my problems
have quite complicated boundary conditions.

My short-term proposal is to keep things as they are now.  boundaryId
is a feature that is not well-designed enough to be a real part of
the grid interface, but is used by enough people as to preclude
getting rid of it now.  At the next developer meeting the interested
parties can then sit down with a few beers and find a solution that
makes everybody happy.

cheers,
Oliver


Am 18.04.2012 14:56, schrieb Martin Nolte:
> Hi Oli,
>
> actually I was a little surprised when you marked the boundaryId
> deprecated without a fully implemented alternative (actually, I
> undeprecated it locally a few seconds later). I thought the agreement
> was to mark the boundaryId deprecated once the alternative is fully
> implemented.
>
> Anyway, in my opinion the solution is suboptimal, because it will remove
> the method from the next release unless experimental grid extensions are
> switched on without a working replacement. And, as Christian pointed
> out, the boundaryId is not an experimental grid extension which can only
> be accessed through the implementation of the grid objects but is part
> of the current interface.
>
> (a) wait until the replacement is fully implemented (i.e., undeprecate
> the method again),
> (b) fully implement the replacement _before_ the next release,
> (c) write a utility class (specialized over the grids) that provides the
> boundaryId (and that is not going to be removed at all).
>
> Approach (c) reflects the fact that the boundaryId will probably never
> be removed from AlbertaGrid and ALUGrid, so there might as well be some
> structure to obtain it.
>
> Personally, I would favor (a), because I do think the
> boundarySegmentIndex stuff still needs further discussion and the
> problems in parallel will probably not be resolved before the next
> developer meeting (which is going to be after the release?). In my
> opinion, we should not remove features from the interface without a
> proper (read: implemented and tested) alternative.
>
> Best,
>
> Martin
>
>
> On 04/18/2012 01:57 PM, Oliver Sander wrote:
>> Hi Christian,
>> don't yell at Robert, this was actually my idea. Rationale: We agreed
>> to have this feature removed. However so far there is no good alternative
>> that works in parallel. This is my personal fault: at the last meeting
>> I volunteered to come up with an alternative, but I never did.
>> Robert was annoyed by the warnings, but I wanted to keep them in.
>> As a compromise we settled on what Robert just committed. I don't
>> think many people use the experimental features (and if they do they
>> do it on their own risk). Hence most people will still see the warning.
>>
>> best,
>> Oliver
>>
>> Am 18.04.2012 13:44, schrieb Christian Engwer:
>>> Hi Robert,
>>>
>>>> Log:
>>>> allow normal use of boundaryId when experimental extensions are
>>>> enabled.
>>>
>>> Could you please explain why this is the intended behavior? As far as
>>> I recall we decided to remove the boundaryId, meaning that it is not
>>> an experimental feature, but will be removed. I still think people
>>> would like to be warned about this future removal, even if they use
>>> experimental features. If you disagree, I'd consider a change in the
>>> semantics of DUNE_DEPRECATE the appropriate fix, because other
>>> deprecation warnings are still on, although experimental extensions
>>> are activated.
>>>
>>> Christian
>>>
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>