[Dune-devel] [Dune-Bugs] [#1707] Replace class BoundarySegment by std::function

[Carsten Gräser]

Hi,

Am 17.08.2015 um 15:12 schrieb Dune:
> THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
> 
> The following task has a new comment added:
> 
> FS#1707 - Replace class BoundarySegment by std::function
> User who did this - Oliver Sander (sander)
> 
> ----------
> Martin,
> thanks for your opinion.  It is not hijacking, you are rather giving a
> detailed explanation why my original wish is not a good idea.  I will
> therefore close this issue as 'won't implement'.  Feel free to open a
> new issue, but with the dev meeting close maybe we should simply talk
> there in person.
> ----------

we should discuss the whole boundary issue on the meeting. The current
situation regarding the treatment of boundary parametrizations and data
has been preliminary for a very long time. As far as I remember we decided
in 2009 on the current approach with all its beauty:

* BoundarySegment with dynamic polymorphism
* What about ownership?
* How to distribution parametrizations?
* segment index via grid
* insertion index via factory
* segment index != insertion index in general
* renumbering up to the user (if he's lucky and can access the factory)
* Every once in a while we have to answer the question
  how to attach boundary data / replace boundary IDs, because
  this is currently far from obvious.

Furthermore we seem to be reluctant to improve the situation:
(Just cooked up "quotes" from my vague memory on several discussions;
no offense to anyone intended!)

"YOU wanted to get rid boundary ID's, so that's the price you have to pay" 
"No problem for me, I can access my ID's via EXPERIMENTAL_GIRD_EXTENSIONS"
"No problem for me, I only use grids where insertion index=segment index"
"No problem for me, I only use parametrizations in serial"

Finally every try to improve one aspect is rejected due to the
valid concern that we should first solve the distribution issue.
We even had the major rewrite taking this issue into account in mind
when we decided the current situation in 2009. Maybe 3.0 is a good
moment for this.

Best,
Carsten


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20150817/df492196/attachment.sig>