[dune-fem] Design of boundary classification, e.g. fem-poisson in school code

[Andreas Dedner]

Hi.
I agree that this is not optimal - we should think of an option to extract
boundary id information from the macro grid file and store it somehow.
Perhaps a Singleton object BoundaryIdProvider or
perhaps a method on the GridPart::boundaryId(intersection)
would do. I don't think using global coordinates is a viable solution....
Best
Andreas

On 14.01.2014 15:37, Claus-Justus Heine wrote:
> Hi,
>
> now that the boundaryId() method has been removed from the dune-grid
> interface (... unless BLAH_EXPERIMENTAL ...) one in principle has only
> the geometry itself to decide whether a given boundary facet belongs
> to a specific part of the boundary. If I then think of the layout of
> the example implementation of fem-poisson in the school-code, for
> example, then we have (simplified) the following way to construct the
> final algorithm
>
> problem -> model -> fem-scheme -> algorithm
>
> If now the model has no other chance than to look at the geometry to
> assign suitable boundary conditions, then the model must have some
> knowledge about the computational domain. This seems to be somewhat
> inconvenient: when changing the macro triangulation (e.g. make it
> twice as large or whatever) then one also has to adjust the model. At
> least to me this seems to suggest that the definition of the
> computational domain should be part of the model. Defining the macro
> triangulation in the parameter file does not seem to fit this layout.
>
> Cheers,
>
> Claus
>
>
>
>
>
>
> _______________________________________________
> dune-fem mailing list
> dune-fem at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-fem


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-fem/attachments/20140116/f958e919/attachment.htm>