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

[Felix Albrecht]

Hi all,

I was also wondering on how to replace boundaryId() when I read todays 
mails. I did some research and found that the matter had been asked by 
Benedikt Oswald in 2010 but could not find any appropriate answer 
(neither on the list, nor in the FlySpray nor in the documentation). I 
can only say that I use this method quite a lot and that I would not be 
too happy to see it go without a proper replacement at hand. This said 
(only to give you an idea of a users perspective) perhaps another 
discussion (on the next developer meeting?) is due?

Best,

Felix

On 18.04.2012 14:56, Martin Nolte wrote:
> 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
>


-- 
-----------------------------------------------------------
  Felix Albrecht

  Institut fuer Numerische und Angewandte
  Mathematik, FB Mathematik und Informatik
  Universitaet Muenster, Room 120.012
  Orleans-Ring 10
  D-48149 Muenster

  Tel.: +49 251 83 35130
  Fax:  +49 251 83 32729
  Mail: felix.albrecht at uni-muenster.de
  WWW:  www.uni-muenster.de/math/u/felix.albrecht/
-----------------------------------------------------------