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

Martin Nolte nolte at mathematik.uni-freiburg.de
Wed Apr 18 14:56:27 CEST 2012


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

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany




More information about the Dune mailing list