dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

There is some partial support for portions of boundaries. The DOLFIN
XML format accepts specification of boundary IDs for vertices, and
each vertex has a list of boundary IDs listing the boundaries to which
the vertex belongs.

There are two alternatives, and I think we should support both:

1. Creating the full boundary using

       Boundary boundary(mesh);

   When iterating over a boundary created this way, it should be
   possible to check for each mesh entity which boundary it belongs
   to. The boundary ID can then be passed as an extra argument to

       const BoundaryCondition::BoundaryValue operator() (const Point& p)

   during assembly.

2. Creating a piece of a boundary by specifying the boundary ID:

       Boundary boundary(mesh, id)

   Perhaps one could also be allowed to pass an argument that can be
   called during the creation of the boundary to ask which entities
   belong on the boundary. This might solve Garth's problem.   

By the way, we use the name "node" for vertices, but we should
probably use "vertex". Then "node" is free to use for finite element
nodes (degrees for freedom) which can be associated with vertices,
edges, faces etc.

/Anders

On Thu, Jul 07, 2005 at 06:25:56PM +0200, jhoffman@xxxxxxxxxxx wrote:
> Yes, I agree. This is what I meant, the ability to create portions of the
> boundary, possibly by providing some rule of how to choose this portion;
> simple bounds for the coordinates, being close to a defined curve/surface
> (up to a tolerance), etc.
> 
> /Johan
> 
> > While we're at it, it makes sense also to be able to select portions
> > of the boundary -- for example in calculating drag on a box.  Perhaps
> > this should be considered along with boundary conditions.
> >
> >
> > On Jul 7, 2005, at 10:18 AM, jhoffman@xxxxxxxxxxx wrote:
> >
> >> Maybe it would be a good idea to be able to create several Boundary
> >> objects.? As it is now, the default is to create one Boundary (in
> >> InitBoundary) which is the total Boundary. Instead maybe one would
> >> like to
> >> be able to create different Boundary objects for different boundary
> >> conditions. The iteration would then be over the different Boundary
> >> objects individually.
> >>
> >> /Johan
> >>
> >>
> >>> On Thu, Jul 07, 2005 at 04:30:35PM +0200, Karin Kraft wrote:
> >>>
> >>>> Hello!
> >>>>
> >>>> We have made some progress. We have made a simple implementation
> >>>> of the
> >>>> general boundary conditions. As a start we have assumed homogeneous
> >>>> dirichlet with a constant penalty factor and this works reasonably
> >>>> well.
> >>>>
> >>>
> >>> Excellent!
> >>>
> >>>
> >>>> Some issues we have discovered:
> >>>> 1. We need to compute the local edge numbers. At the moment we do
> >>>> this
> >>>> by comparing to all the edges in the cell like so:
> >>>>
> >>>>   // Iterate over all edges in the boundary
> >>>>   for (EdgeIterator edge(boundary); !edge.end(); ++edge)
> >>>>   {
> >>>>       ...
> >>>>       for(int i = 0; i < cell.noEdges(); i++)
> >>>>       {
> >>>>       if(cell.edgeID(i) == edge->id())
> >>>>       {
> >>>>           segment = i;
> >>>>       }
> >>>>       }
> >>>>
> >>>>
> >>>> However, this is inefficient. Perhaps the mesh should be extended to
> >>>> store this information?
> >>>>
> >>>
> >>> Matt Knepley is working on a new parallel mesh component for FEniCS
> >>> and the plan is that we will wrap this in DOLFIN (same as with PETSc)
> >>> once it is ready, so maybe we should not invest too much time in
> >>> extending the mesh data structures with new data.
> >>>
> >>> I suggest that we use your temporary implementation (looping over
> >>> edges locally to find the local edge number), but create it as a
> >>> function in Cell (put it close to the functions for computing edge
> >>> and
> >>> face alignments). Something like
> >>>
> >>>     uint Cell::edgeNumber(const Edge& edge) const;
> >>>
> >>> We will also need
> >>>
> >>>     uint Cell::faceNumber(const Face& edge) const;
> >>>
> >>> By putting this as a member function in Cell, you can use the local
> >>> data structures directly instead of iterators (the array ce) which
> >>> should be a little faster.
> >>>
> >>>
> >>>> 2. Our eval looks something like this and we want to avoid the
> >>>> conditional evaluation. Any ideas?
> >>>>
> >>>>  void eval(real block[], const AffineMap& map, uint boundary) const
> >>>>   {
> >>>>     // Compute geometry tensors
> >>>>     real G0_ = map.scale*1e6;
> >>>>
> >>>>     // Compute element tensor
> >>>>
> >>>>     if( boundary == 0 ) {
> >>>>     block[0] = 0.0;
> >>>>     block[1] = 0.0;
> >>>>     block[2] = 0.0;
> >>>>
> >>>>     block[3] = 0.0;
> >>>>     block[4] = 3.333333333333318e-01*G0_;
> >>>>     block[5] = 3.333333333333318e-01*G0_;
> >>>>
> >>>>     block[6] = 0.0;
> >>>>     block[7] = 3.333333333333318e-01*G0_;
> >>>>     block[8] = 3.333333333333318e-01*G0_;
> >>>>     }
> >>>>
> >>>> Regards,
> >>>> Karin and Johan
> >>>>
> >>>
> >>> I managed to avoid conditionals when building the dofmap()
> >>> function by
> >>> creating arrays. Maybe there is some solution where the segment
> >>> (boundary) argument is used to index an array to get the values, but
> >>> it doesn't look like that would be easy to do here.
> >>>
> >>> One solution would be to create three different eval functions
> >>> (eval_segment_0, eval_segment_1. eval_segment_2) and then have an
> >>> array of function pointers to these functions and use the argument
> >>> segment (boundary) to index into this array, get the correct function
> >>> and then call it. I'm not sure how this compares to having a
> >>> switch or
> >>> a series of if statements inside eval.
> >>>
> >>> It bugs me that we first have to search for the edge number, and then
> >>> when we have the number go through a switch statement. Are we doing
> >>> something wrong? Maybe there is a shortcut that avoids both the
> >>> searching and the switch?
> >>>
> >>> /Anders
> >>>
> >>> _______________________________________________
> >>> DOLFIN-dev mailing list
> >>> DOLFIN-dev@xxxxxxxxxx
> >>> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >>>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> DOLFIN-dev mailing list
> >> DOLFIN-dev@xxxxxxxxxx
> >> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >>
> >
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >
> 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/